GodotEnv
GodotEnv copied to clipboard
chickensoft-games
Support adding a new addon to the `addons.json` file via the command line
Currently, in order to install addons into your Godot project, you need to first modify the addons.json file and then run godotenv addons install to read the file and perform the installation work. But this can be prone to user error if you don't format the json file correctly and takes up a bit more time compared to the workflow of NPM in the JS world. One neat convenience feature from NPM that would be nice to have is some sort of command that takes in the URL of the addon you want to add, modifies the addons.json file to add a new addon to the list, and then internally runs install to apply the changes.
I'm not sure what kind of naming/format this command should have, but to match the NPM implementation, it could be something like:
godotenv addons install [required url] [optional subfolder] [optional branch/tag] [optional source(?)]
And perhaps the source value could just be automatically detected depending on how the URL is formatted instead of user input. When an addon is added to the json file, it will simply be appended to the end of the list. The most challenging problem will be reading/writing the json file correctly, but besides that it should be easy to construct a new addon definition based off the inputs, so I think it shouldn't be too tough to get working. Let me know if there are any other ideas that could go into this feature and if this proposal makes sense, thanks!
Hey, thanks for the thoughtful write-up. I think this can be done, but I'm not sure if it will be more useful than just editing a JSON file since you have to provide all that info and put it in quotes and get the flags correct or put the command line parameters in the correct order.
On the serialization side, we have serializable models for everything and so programmatically editing the config file is pretty easy (harder if we try to preserve comments in jsonc files, though).
I imagine it would be more helpful if we could allow users to specify an asset only by its Asset Library title (they use numeric id's, so no package_name-style id's sadly), search the asset library to get its numeric ID, and then fetch the asset details to get the download url from the asset library. Now that GodotEnv is able to download zip files, this is now a viable next-step.
Here's the Asset Library API for future reference. The end point is https://godotengine.org/asset-library/api/. Finally, here's a curl command to fetch asset details: curl https://godotengine.org/asset-library/api/asset/3654 -H "Accept: application/json".
I'm not sure if it will be more useful than just editing a JSON file since you have to provide all that info and put it in quotes and get the flags correct or put the command line parameters in the correct order.
Well theoretically all of the optional fields I put in the example are... optional haha. By default godotenv could detect the URL type to determine the source, and then leave everything else blank which will make them default values anyways. So the basic command for Github packages is only godotdev addons install URL or maybe you could even just make it godotenv install URL if it can detect what it has to install (eventually as a shortcut for either Godot version or addon?).
But the other benefit is just that it can eliminate user error; if everyone is adding addons via the command line it's guaranteed to get the JSON syntax correct which can minimize issues and confusion. It's a small thing and may not make a world of difference but imo an ease of use feature like this can actually add up to lot of saved time/hassle in large projects or years down the line :)
I imagine it would be more helpful if we could allow users to specify an asset only by its Asset Library title (they use numeric id's, so no
package_name-style id's sadly), search the asset library to get its numeric ID, and then fetch the asset details to get the download url from the asset library. Now that GodotEnv is able to download zip files, this is now a viable next-step.
This would be neat too, but not every package that I want will necessarily be in the Asset Lib, so I see it as a bonus in addition to the basic URL command. Would be cool to see though! Thanks for the info!
@RobProductions unfortunately, the reality of how addons are handled is more complex than just a URL string. At a minimum, you need a URL and a string id for the addon. The vast majority of addons coming from GitHub url's will also probably need an explicit subfolder declared (since most addons are structured this way for the Asset Library), so that's 3 pieces of essentially non-optional information.
For some URL's, like GitHub repo's, we could infer a name from the URL itself, but I wouldn't do that since it would be making too many assumptions on the user's behalf and would over-simplify what is actually a very nuanced process.
I don't feel that a CLI command which requires 3 parameters is personally that much of an improvement over just editing JSON. While JSON is cumbersome, it is also extremely simple and has a low barrier to entry for editing config files.
@jolexxa Thank you for explaining that, I think I understand now that non-github sources like local folders will not necessarily have the name info included in their folder. I was probably thinking that if GodotEnv could download the plugin and then find the plugin.cfg (which would just be sitting in the topmost level when provided a subfolder) it could read the name from that and use it as the string ID. I realize that's a bit more complicated to implement, but if done it would reduce the "required" parameters down to 2.
Something else to note is that the plugins I was thinking of making would all be authored in a single project and uploaded to Github as individual repos, which means they don't need subfolder information. I guess this isn't how most plugins are structured but it's still technically optional to provide a subfolder in these cases, so that's why I labeled it as such.
But you're right that needing the subfolder info for most plugins makes this a bit of a wash comparatively to just editing the JSON file, at least in terms of time. I would still argue that mistakes can be reduced if the user plugs this information into a command line instead of a file, even if they have to type the same amount of characters, as some people prefer to work this way. But I understand that there's a question of how much dev time should be devoted to implementing it compared to how useful it is. So do you think with these considerations you'd ever consider this feature as a secondary way of adding new plugins? If not I don't want to clutter up the issues page for too long lol so I'm totally fine with letting it go and closing the issue if needed :)
EDIT: I would also say that GodotEnv would just feel more "complete" if this was available as a pathway for adding plugins since you wouldn't need to open the JSON file in a different program or visual editor. I'll again make the comparison to NPM which probably has huge chains of optional parameters and commands but ultimately lets you edit the package environment completely through those commands without needing to touch a YAML or JSON, which is a nice thing to have imo