[Discussion] A super-early-entry-point (or loader-plugin)

[LogicFan]

trafficstars

I've read through serval related discussions about this, including https://github.com/FabricMC/fabric-loader/pull/192 https://github.com/FabricMC/fabric-loader/issues/445 https://github.com/FabricMC/fabric-loader/issues/175 https://github.com/FabricMC/fabric-loader/issues/223

Since this one has been discussed for a long time but never made it real, I would like to have a more formal approach for this. There will be 3 steps,

1. List all specifications (i.e. requirements) for this feature.
2. Explore how to accomplish these specifications.
3. Start the PR.

This issue is intended to discuss the specification for this feature so that everyone is happy about this before proceeding to the next steps.

============================ Here is the specification,

1. It will be loaded by fabric-loader
2. It will run before any mixin bootstrap or aw bootstrap.
3. It should not be able to access the game (i.e. Minecraft) or its dependency. If it does, the fabric loader should crash.
4. It should be able to add additional jars into the classpath.
5. It should be able to add additional mod (i.e. ModContainer) to the fabric loader. The added mod should respect the mod dependency resolving, which handles by the fabric loader.
6. It should be able to add additional mixin config or aw file to fabric loader.

Please have a comment on this if you think some specification is undesirable or want to add more specification.

[liach]

12346 are all easy as heck. 5 is the real nightmare, as the current system of loading isn't quite extensible to new discoveries, especially that the mod source priority system would definitely get a big revamp.

[LogicFan]

5 is the real nightmare, as the current system of loading isn't quite extensible to new discoveries,

I think the new mod discovery system (refactored by Player) can potentially support multi-pass resolving already. Here could be a new resolving process.

1. initial discovery by the loader, split into plugin-mod (i.e mod with super-early-entry-point) and non-plugin-mod (mod without super-early-entry-point).
2. resolve all plugin-mod, and run them based on resolving results.
3. if any new plugin-mod is added by step 2, do another pass of resolving and run them based on the resolving result. Repeat until no new plugin-mod is added.
4. when there is no new plugin-mod, resolve all mods, and run them based on resolving results.

However, since I am still looking at the loader code and doing the experiment, idk if this method could introduce any potential problem. Any suggestion?

[liach]

Sure, this topological approach looks good.

I think the mod discovery mechanism should be more like language adapter: the mod discoverers can be defined like language adapters, and only the discoverers are resolved at first until there is no discoverer pending a run (discoverers can find new mod jsons that provide discoverers).

With this model, we can probably split custom mod provision from the super-early entry, which, I assume, would be safer? The classloading of these discoverers can follow the model of language adapters given their very similar roles and models.

[thecatcore]

Being able to also remove specific ModContainers would be awesome I think.