I was recently thinking on how to structure an amethyst project that let us work better with amethyst 3rd party packages and integrate them easily into our projects, something similar to rails initializers.
Right now you need to write a lot of boiler plate just to get your barebone app working, I know that is good to know how to write it, but for me this structure (where all the initialization is in the main.rs) is not something maintanable, at least for medium/big projects. Your main file will eventually have hundred or thousand of lines of code just to setup the systems used.
And also another problem is that some systems (well this was talked a lot in other posts too) is that there’s no convenient way to know what systems depend on others, etc.
Encourage a good practice to put the initializers in their respective file under the folder initializers that can look something like
This is just a tentative approach and I think it could better worked so we can use this in the future to integrate with the editor and let the configuration accours there, but we need an extra step for that to work and its to come with a convention that the systems can load a ron file to setup their properties (some of the core systems already do something similar).
But in the mean while we can to address this issue in a primitive way and let the amethyst-cli tool to fetch the initializers from the repo (if is present in the library repo), copy that default initializer (if is not already present in the initializer folder) and edit the mod.rs file to include that mod and call the init.
There are some issues still with this approach, maybe those 3rd party package need that you setup some core system and need to be initialized after them, so we may need an extra manifest file for the amethyst assets that could resolve this issue, we can use the same approach that cocoapods/homebrew use maybe and setup and repo where amethyst-tools read to get the amethyst 3rd party packages and so this cli will be responsible to update the cargo.toml, setup the initializers and maybe setup the ron configuration file for those initializers.
I’m not saying that we all must follow this kind of structure or force it, but what I want to say is we need to encourage, because IMHO the great success of rails/unity/etc all those tools has good practices that they promote, so it’s easy (at least for rails) to jump into a project and know more or less where to start looking to work with an existing project, unity is kinda similar but their structure isn’t too strict as rails.
I’m not aware if this was already discused (I’m not sure if I already talked somewhere about this a while ago) by the core team and if they have some work on this or at least an RFC about this.
And sorry if my proposal isn’t well elaborated or too vague.