Godot-proposals: Share code between multiple projects

[git2013vb]

Describe the project you are working on:
Client server project
Describe the problem or limitation you are having in your project:
I have to duplicate some functionality between client and server ( log management, common classes for example)
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
It will be nice if the project can use shared folder where user can put in common code (will be gdscript/c# or anything else)
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Add a configurable path option in project settings where user can decide where the shared code will be
Then the shared path will be displayed in dock together with current project folders

If this enhancement will not be used often, can it be worked around with a few lines of script?:
NA
Is there a reason why this should be core and not an add-on in the asset library?:
It will part of project structure.

[Xrayez]

See godotengine/godot#35432 (talking about global plugins). The implementation was not accepted but the feature is still desired, the rationale behind this as described in https://github.com/godotengine/godot/pull/35432#issuecomment-595776084.

[git2013vb]

No, I'm against to do it by plugin.
It will be like using a cannon to kill a fly.
A simple settings in project properties against to build a plugin and import it in a project.

So far we have already a "shared" folder
.local/share/godot/app_userdata/

where inside we have all our projects
So will be enough to add a "common" folder we can use as "container" of any code/resource that can be shared/reused among all projects.

...More simple that that :)
edit: Also if is like that I suggest we will not need any settings in projects. Just to show this "common" folder in dock with a different color, eventually.
edit2: Even better: instead using app_userdata is will be better to create a "common" under .local/share/godot folder

It have not to be exactly "common" as name . important is to reach the functionality we need: share between projects.

edit2: Even better: instead using app_userdata is will be better to create a "common" under .local/share/godot folder

It have not to be exactly "common" as name . important is to reach the functionality we need: share between projects.

[Megalomaniak]

I think this is better served by an asset manager than a plugin interface, though here's an idea: Develop and bundle a asset/resource manager as a plugin and it can also potentially solve the need for global plugins as well.

[willnationsdev]

Couldn't this be more easily solved by allowing users to arbitrarily add "include" folders for their Godot project in both ProjectSettings (on a per-project basis) and EditorSettings (on a multi-project basis)? You'd need the EditorFileSystem singleton to account for those locations and then make sure that they are all handled during project/pck export. But I think that's all that would be needed. Anything work that is done via the plugin system could be done as a separate layer on top of that (and plugin stuff like #142 won't be ready for a while whereas this could be done much sooner).

[git2013vb]

Couldn't this be more easily solved by allowing users to arbitrarily add "include" folders for their Godot project in both ProjectSettings (on a per-project basis) and EditorSettings (on a multi-project basis)? You'd need the EditorFileSystem singleton to account for those locations and then make sure that they are all handled during project/pck export. But I think that's all that would be needed. Anything work that is done via the plugin system could be done as a separate layer on top of that (and plugin stuff like #142 won't be ready for a while whereas this could be done much sooner).

As long I can use this "include" folder like any other project folder I'm happy with your solution.
For project's point of view this folder have to be like any other project's folder.

[Flavien]

I agree with @willnationsdev, the first step, which will solve 95% of use cases is to simply let people include arbitrary paths into their res:// filesystem (e.g. set res://sprites/ to point to ~/sprites on my machine).

A "nice to have" after that is allowing to reference ZIP archives, so you can bundle resource packs and share them as a ZIP file.

[Jummit]

I actively share code between projects, I have a big library of plugins and utilities. I use symbolic links to synchronize them.

OP said:

No, I'm against to do it by plugin.
It will be like using a cannon to kill a fly.

I don't exactly understand the reasoning behind that argument. I have a lot of plugins that are ~30 lines of code. The benefits of plugins are that you can enable/disable them and that they have a lot of power over the Godot interface.

[git2013vb]

The reason was in the first place to avoid copy-paste. As far I know even if you use plugins you have to copy them between projects to have them.
My current "workaround" is to make a separate library project dll (C#)
Personally I prefer dll instead having a plugin with the risk that is not the same int all my projects (I don't count git to sync, I use git as pure versioning system)
But.. If we can have a personal local repo where we can put all our plugins together tha can be used I will have no qualm:

But how it work?
I did't find any documentations.

[Jummit]

Note that even if you'd get a custom server running, you'd still be copy-pasting. Use symbolic links if you really want to avoid duplicate code.

[git2013vb]

Note that even if you'd get a custom server running, you'd still be copy-pasting. Use symbolic links if you really want to avoid duplicate code.

Can you elaborate please?

ps.: I know copy-paste is a virus :)) the lesser the better

[willnationsdev]

@git2013vb There are ways of creating "symbolic links" for files where you effectively tell the operating system to keep a reference to the same file in multiple places. ln on Linux/Mac and mklink on Windows can do it for you, given the right parameters. A "hard directory link", for example, could enable you to keep a plugin located in multiple projects' res://addons/ folder. Editing any files inside would also edit the same files in the other projects, because they all reference the same files.

Edit: A "soft link" is effectively the same thing as a shortcut where it simply points to the other file, but isn't a direct reference to it. With soft links, if you delete the original, then the shortcut/soft-link no longer works properly. Hard links will truly create another full reference to the file.

[git2013vb]

@git2013vb There are ways of creating "symbolic links" for files where you effectively tell the operating system to keep a reference to the same file in multiple places. ln on Linux/Mac and mklink on Windows can do it for you, given the right parameters. A "hard directory link", for example, could enable you to keep a plugin located in multiple projects' res://addons/ folder. Editing any files inside would also edit the same files in the other projects, because they all reference the same files.

Edit: A "soft link" is effectively the same thing as a shortcut where it simply points to the other file, but isn't a direct reference to it. With soft links, if you delete the original, then the shortcut/soft-link no longer works properly. Hard links will truly create another full reference to the file.

Thank you but I know what are ln/sl (the main problem is you cannot "port" them across different OS, for someone like myself who use linux,win - and later mac - in different pc/machine/devices is hard to keep in synk all of them) btw I was asking about what he meant about his "you'd still be copy-pasting" sentence :)

What I suggest than any solution it is the best to be made in godot in order to be portable.

[Jummit]

what he meant about his "you'd still be copy-pasting"

Downloading things from the asset library just copies the files into your project, no links and no git repo.

[git2013vb]

That is fine if you use other plugins - in a certain extend - But when you are going to make your plugin/ common classes/common scenes - or anything that you don't wish to be duplicate the problem remain.
What kind of problem? difficult to keep all synced. That was the first reason why I had to make a dll. To be DRY :)

[tx350z]

I'm very much in favor of having a way to add a directory reference outside the project folder to the FileSystem doc. It seems to be the simplest, most direct direct way to support libraries of common/shared/library objects.

It might be good to have the option of making the folders read-only so editing of shared code can only be done within a common/shared/library project. Projects that "import" or "bind" or "reference" or "what-ever-term-you-like" to the external directories should still be able to view the code (e.g. for debugging) even when read-only.