Splitting up long files (utils/core)

[ithinkandicode]

Done	Dir	File	Class Name	Notes
✅	api	log.gd	ModLoaderLog	done in #205
✅	api	mod.gd	ModLoaderMod	All helper functions used by mod devs - #208 ModLoader -> ModLoaderMod
✅	api	config.gd	ModLoaderConfig	done in #157
✅	api	deprecated.gd	ModLoaderDeprecated	done in #156
✅	internal	cli.gd	_ModLoaderCLI	#226
✅	internal	path.gd	_ModLoaderPath	#226
✅	internal	file.gd	_ModLoaderFile	Including the saving funcs from #143. Maybe JSON funcs too? - done in #226
✅	internal	dependencies.gd	_ModLoaderDependencies	done in #222
✅	internal	script_extension.gd	_ModLoaderScriptExtension	done in #225
✅	internal	godot.gd	_ModLoaderGodot	Eg. check_autoload_position() - done in #172
✅	internal/third_party	steam.gd	_ModLoaderSteam	See related chat in #148, here - done in #158

Breaking Changes & Deprecation

Ofc, if we moved the logger funcs then every currently published Brotato mod would break. But we could handle this with a deprecation notice, which can be handled with a new func and that triggers a fatal error in the editor. I've explained how this could work in more detail in #154:

• Discussion: Deprecation #154

[ithinkandicode]

Additionally, perhaps it would be a good idea to also split up mod_loader.gd? Especially the public API methods.

And just as the utility funcs could have a directory called utils, these could directories called internal and api, for internal methods and public methods respectively.

Here's a table with my notes on class names and grouping (all applies to mod_loader.gd except ModLoaderLog).

Class	Dir	Notes
ModLoaderInternal	internal	Internal methods (ie. ones that are currently prefixed with _*)
ModLoaderData	internal	Data store for the local vars from mod_loader.gd (eg. os_mods_path_override).
ModLoaderOptions	internal	ML Options (PR #145)
ModLoaderMod	api	Public methods related to installing/setting up mods (eg. ModLoaderMod.install_script_extension)
ModLoaderConfig	api	Config JSON
ModLoaderLog	api	Probably deserves its own class, separate from other utils, as it's used so often

Using ModLoaderData would fix an issue where currently, if you run a func from mod_loader_utils.gd while in ModLoader's _init(), there's no way to access local vars from mod_loader.gd -- or maybe there is, but it's not obvious how.

As mentioned before, this would be completely breaking for a lot of mods, but we can take the deprecation approach mentioned in the original post above ("Breaking Changes").

[Qubus0]

I largely agree. Those are some good splits. A few things:
We should keep away from misc and just keep one generic ModLoaderUtils.
Third party should not be lumped together, but we can put it in a separate directory /third_party_integration. ModLoaderUtilsSteamWorkshop, ModLoaderUtilsThunderstore. These names are getting very long though.
Splitting those also allows us to use the Steam singleton from GodotSteam, since it won't break if it is not available if the file is never parsed.

Splitting the ModLoader is another thing. If we use ModLoaderMod (which I would love) we might also have to use a second autoload. One more step in the setup process.

[ithinkandicode]

For the utils classes, would it be better to get rid of the Utils prefix? That would make them a bit shorter, so faster to type. Eg:

• ModLoaderCLI
• ModLoaderFile
• ModLoaderSteamWorkshop

Perhaps then we could have the utility funcs in the api directory, as they're technically all public API methods. Could save us needing to discuss/decide what constitutes an API vs. utility method. The downside would be that the api directory might feel overly cluttered with utility funcs

@Qubus0 How come ModLoaderMod would need to be another autoload?

[Qubus0]

Shorter seems fine to me.
If we want to provide access to ModLoaderMod like ModLoader like we do now, it has to be an autoload.
I did just check though, and we can just make every helper method static by just using ModLoader.*.. For example using ModLoader._saved_objects.append(packed_scene) in save_scene makes it "static"
So, a global class also works

[ithinkandicode]

I think that we should publish a release before we start work on a large refactor like this. We're going to lose a lot of commit history by moving things around, so it would be really good to have a point in time (ie., a release tag) that we can refer back to if we want to see the pre-refactor history.

Edit: Actually, we have the recent 5.0.1, so it's probably fine

[KANAjetzt]

Sorry, I'm late to the party.
What about using ModLoader and ModLoaderUtils as index files?
And just link from there to the actual Class methods?
No breaking changes and keeps the main files somewhat clean.