Allow for "manual" or "override" addons

[CpazR]

Maybe this already exists or is a moot point based on how the addon manager works, but after looking around the documentation, I couldn't find any details on this.

But I do think there are cases where you would want both packages managed by GodotEnv, and some packages managed manually. An example of this from my own experience are some hacky changes I made to TweenSuite to suit my project's needs. Those are changes I wouldn't try to merge back in because it's, again, very hacky and likely not fool proof outside of my use cases.

So my idea is that you'd be able to define a source as "manual". Maybe on addon install, GodotEnv can add these manual addons to the gitignore?

A few points on this idea:

• Moving modified addons outside of the addons folder creates some issues with the godot editor itself. Especially if it's a plugin like TweenSuite. So as far as I can tell, that isn't a viable solution.
• In the event a project would be using godotEnv for addon management, these overrides would be the exception rather than the norm.
• Godot Env should treat these as exceptions. Maybe require a reason field for documentations sake? At the very least give a special notice/warning while installing packages.
• This would also, presumably, prevent addon conflicts.

[jolexxa]

Maybe on addon install, GodotEnv can add these manual addons to the gitignore?

The GodotEnv readme recommends that you gitignore all the content in addons — the godotenv addons init command sets that up for you, as well. If you're using GodotEnv to manage addons, you're effectively treating addons as immutable packages that shouldn't be committed to your codebase. As long as your codebase has the addons.json file, you can always reinstall addons when that file changes from branch to branch, etc.

[CpazR]

If you're using GodotEnv to manage addons, you're effectively treating addons as immutable packages that shouldn't be committed to your codebase.

I think I inherently disagree that all addons need to be immutable or all addons need to be committed for a given project.

The more options the better imo.

But if there's no interest in allowing both, that's fine. Won't push it further.

I'm pretry sure I found a good enough workaround for my own needs.

[jolexxa]

GodotEnv's dependency graph only works correctly when addons are immutable. If you need mutable addons, the workflow is to add them to your addons directory yourself and presumably add them to version control, as well, via a gitignore exception. GodotEnv doesn't touch other directories inside addons/ that aren't from the addons.json, allowing you to manually manage any addons you wish without needing to reference them in the addons.json file at all.

You could also tell GodotEnv to symlink a local clone of your remote fork, as well. Symlink addons are the mechanism by which GodotEnv allows you to have mutable addons that could potentially be shared across multiple projects, while still treating them as immutable.

This would also, presumably, prevent addon conflicts.

I don't see how. Addon conflicts are mostly likely to arise when two different addons require different configurations of the same addon. The GodotEnv addon resolution system is designed for a flat-graph dependency model and supports symlinking local addons. Those are powerful tools and introducing mutability would increase the complexity too much and potentially introduce many more conflict scenarios.

In short, GodotEnv will also not touch other directories in the addons folder that it does not manage. This means you can already do whatever you want with your addons and still use GodotEnv to manage the immutable ones.