[1.3] Mod settings per run config

[Juuxel]

Why?

Mod settings (loom.mods) populates Forge's MOD_CLASSES env variable, which is used to determine which mods to load and from where. Crucially, Forge ignores everything else for local mods, and loads all mods defined in loom.mods.

This is problematic when you have a secondary mod, such as a test mod or a data generator, in another source set. Those mods should be compiled separately and aren't clearly needed when running the mod from the main source set - but they need their own mod settings, so FML would be loading/trying to load their classes. This can lead to crashes since the classes can be missing or outdated.

What?

I'm planning to add a local NamedDomainObjectContainer<ModSettings> to RunConfigSettings, which would override the global loom.mods container when not empty.

It might be easiest to only support this on Forge (and maybe call it forgeMods for that reason). Fabric/Quilt populate them in the DLI config, which is not currently specific to any run config:

architectury-loom/src/main/java/net/fabricmc/loom/task/launch/GenerateDLIConfigTask.java

Lines 89 to 91 in e0efe9c

	if (!getExtension().getMods().isEmpty()) {
	launchConfig.property("fabric.classPathGroups", getClassPathGroups());
	}

Code example

loom {
  runs {
    data {
      // <data run config boilerplate>
      mods { // if non-empty, replaces the "global" mod settings container
        tinypotato {
          sourceSet sourceSets.main
          sourceSet sourceSets.data
        }
      }
    }
  }
}