Make ThatOrThis a library?

[EZForever]

As mentioned in #1, I have a plan to make ThatOrThis a library mod, expose the ability of choosing and loading additional mods to other mods and developers. Modpack configs, GUI elements, etc. will be moved to a separate (optional) mod.

However, there are some questions to be answered before we could work on this:

1. Is this will ever be needed? If not, better leave the mod in its current form. Refactoring code is never fun to do.
2. How will the mods communicate with the library? Given that ThatOrThis runs before initializing other mods, it's impossible to "ping" each mod on the fly for their opinions.
3. How should the library deal with rule management and conflicts? What if two mods suggested exactly opposite rules?

[Madis0]

I think you should not make it a library, because

• mods that want to make this feature might as well reimplement them, why would they use your library for that
• joint effort for making one GUI mod great is better than creating several "forks" that use your library
• you could focus on making the code clean and provide some APIs to make sure other mods (e.g. menu editors) can play well
• you could add more options help to tailor the experience for different modpacks (though I don't know which, yet)

[EZForever]

The things you've pointed out are exactly the reason why I wish to make ThatOrThis a library.

mods that want to make this feature might as well reimplement them, why would they use your library for that

As described in README, ThatOrThis uses a rather "intrusive" approach to inject mods into the Fabric Loader and does not have a way to let other mods to do the same thing. Mods can re-implement the techiques (mainly the hooks on ModContainerList and DirectoryModCandidateFinder) by themselves, but they will be incompatible with each other. By having a single library-only mod to do the heavy-lifting, this compatibility issue can be migrated.

btw, I've read #18, but it's irrelevant. See my comment there.

joint effort for making one GUI mod great is better than creating several "forks" that use your library

GUI stuffs are not removed, but moved to a separate optional mod. Think this as a "reference implementation", or the relationship between Fabric Loader & Fabric API. Others may as well make their own GUIs for better suit their needs.

Also, by moving Minecraft-related code out of ThatOrThis, ThatOrThis can be made version-independent, just like Fabric Loader itself.

you could focus on making the code clean and provide some APIs to make sure other mods (e.g. menu editors) can play well

That's exactly what a library mod (or API mod, if you prefer that name) should do.

you could add more options help to tailor the experience for different modpacks (though I don't know which, yet)

See point 2 above. You can't expect a single mod, person or team to provide support for every single modpack. By having a open standard for injecting mods, modpack developers can tailor the experience by themselves.

[Madis0]

and does not have a way to let other mods to do the same thing.

Why should they do the same thing when one implementation is already present? Is there a use case outside this mod's purpose that you want to allow? (same hacks for a different goal).

Think this as a "reference implementation", or the relationship between Fabric Loader & Fabric API. Others may as well make their own GUIs for better suit their needs.

I get that, but it doesn't explain why a reference implementation would be good for this purpose, instead of being the only implementation. As an analogue, there are no (popular) forks of Mod Menu, because people contribute to that mod instead.

That's exactly what a library mod (or API mod, if you prefer that name) should do.

But it is also what a non-library mod can do. And non-library mods can provide some specific APIs (e.g. just overriding the main menu button) without providing all of them (mod management logic).

You can't expect a single mod, person or team to provide support for every single modpack. By having a open standard for injecting mods, modpack developers can tailor the experience by themselves.

That is true, but you already have plenty of options in your rule system, that might cover 95% of use cases.

[SettingDust]

A lib that only provide hooks before mod setup https://modrinth.com/mod/preloading-tricks