FabricMC
[Feature Request] New dependecy kind - `includes`
At the moment there's no standardized way to describe dependencies that are included in a mod/library, therefore I suggest adding a new dependency kind called includes, which can be very useful as metadata, just like suggests.
It's pretty easy to implement and it shouldn't break anything:
enum Kind {
/* ... */
- BREAKS("breaks", false, false);
+ BREAKS("breaks", false, false),
+ INCLUDES("includes", true, true);
/* ... */
}
Want to hear your thoughts about this, because I'm planning to make a PR that includes these changes.
Not sure what effect this is supposed to have? There is the "provides" system which can (besides other things) expose shaded mods (currently not with its own version, but that'll be rectified soon)
As I said, it's mostly useful as metadata that can be used, for example, by automated publishing tools that need information about relations of the mod with other projects. At least that's the first thing that comes to my mind.
I still don't get it? Please try to be more verbose. At least with the current capabilities of the dependencies block it makes little sense to me.
Thank you for your patience, had a busy week. I didn't want to be more specific, because an individual use case may be debated, while my main point is embedded library is a different kind of dependency, that cannot be described with existing dependency kinds (it's required from the mod's perspective, but it's even less than optional from the point of view of a player), but, being an easy thing to implement, could be useful as metadata for some tools and mods. It's similar to suggests, in my humble opinion - it doesn't make a lot of sense in terms of the fabric loader itself, and most of the players may never know that it was a thing, but it's still nice to have it.
If you want a specific use case, I'm making a tool that automatically publishes mods to GitHub, Modrinth and CurseForge, and trying to make it as zeroconf-y as possible. CurseForge has this thing called relations (Modrinth should have something similar, but I don't know if they've made that update live already or not, haven't look into it yet), which are "requiredDependency", "optionalDependency", "embeddedLibrary" and "incompatible", if I recall it correctly. Every single one of these can be described via standard fabric dependencies, except for "embeddedLibrary", which prevents me from using fabric.mod.json as a primal data source for my tool.
The Fabric system already have an include system, it allow to add mods jars at compile time to the built jars, this is used by sodium for example to bundle fabric rendering APIs without shipping the entire Fabric API, also the Fabric API use this itself in it's jars.
Sodium Example: https://github.com/CaffeineMC/sodium-fabric/blob/5d364ed5ba63f9067fcf72a078ca310bff4db3e9/build.gradle#L35 FabricAPI Example: https://github.com/FabricMC/fabric/blob/3f7d361425fdbd99261776649b0acf5bae941b47/build.gradle#L324
The current system is better because it allow 2 mods to include the same mods dependencies without conflicting with each other.
The Fabric system already have an include system, it allow to add mods jars at compile time to the built jars, this is used by sodium for example to bundle fabric rendering APIs without shipping the entire Fabric API, also the Fabric API use this itself in it's jars.
Erm... and the giant squid may reach 13 meters in length. Like, that's cool info, definitely didn't know it and didn't use it in my mods before, but what does it have to do with this issue?
The current system is better
Better than what?
You can just look in META-INF and read the included jars' fabric.mod.jsons? But that won't help you locate it on Modrinth/CF, so this feature request as described won't even help you.
@LoganDark, as I mentioned above, it's not the only use case in the entire existence, it's just my own anecdotal evidence. Also, it does already help :)
P.S. - META-INF does not exist before the actual compilation
P.S. -
META-INFdoes not exist before the actual compilation
Yeah cause you totally upload uncompiled mods to curseforge
Once again, it's not about my use cases. How would you simply and reliably obtain the same information during the mod runtime?
Once again, it's not about my use cases. How would you simply and reliably obtain the same information during the mod runtime?
Right now there's currently no bulletproof way to find out what other mods a certain mod embeds, but there is a way to find out what other loaded mods were provided by a certain other mod. Call FabricLoader.getInstance().getAllMods() to get a list of ModContainers, each container has a getOrigin() method that returns a ModOrigin, which describes where the mod in question came from. If said origin has a getKind() of Kind.NESTED, then it was JiJ'd by another mod, which you can find via modOrigin.getParentModId().
The full list of possible mods that may be loaded by a JiJ is only available at mod loading time via the ModCandidate system, there's ModCandidate.getNestedMods() which returns a collection of all the nested mods that participate in dependency resolution. There's currently no way you can access that from a mod as far as I'm aware, since it only exists before mods are loaded.