RFC 9: QSL Structure

[TheGlitch76]

Rendered View

[Haven-King]

Let's say we have a tooltip component API (1.17 only), in which library would it go in?

gui, probably.

[quat1024]

Rendered markdown btw

Big fan of the two-tier structure!!

some knee-jerk reactions:

• world is kind of big, especially if each of its submodules is to be managed by the same team.
• Where does a config api fit? config_and_admin has config in the name but seems to deal more with "ingame" things. Maybe it fits in core?

[i509VCB]

I wouldn't say the commands, gamerules or permissions stuff would belong in core.

For sake of not making core huge (I want to be very selective about what makes the cut for core, config would probably be seperate).

[cittyinthecloud]

There's also the option to split commands and permissions (which are both pretty obviously commandish) and gamerules into two separate categories. Gamerules can be world specific iirc, so maybe they belong under world? (I'm reluctant here because world is already huge comparatively)

[i509VCB]

Keybindings do apply only in a world, but it doesn't feel very keybind like tbf. I guess it's the cost of consolidating under more broad categories.

[quat1024]

I wouldn't say the commands, gamerules or permissions stuff would belong in core.

Oh i absolutely agree lol, by "config api" i meant something like "loading and parsing a config file", the stuff in config_and_admin should definitely stay separate

Thats cool to keep a config api in its own module as well

[l-Luna]

why require modules to "only depend on modules from core, common, or within their own library"? it seems to me that the easiest way to make indigo easy to exclude would be to have it as a seperate module that depends on the rendering module. otherwise great

[TheGlitch76]

it seems to me that the easiest way to make indigo easy to exclude would be to have it as a seperate module that depends on the rendering module.

Yes, for mods that need to exclude Indigo I was thinking something like:

implementation qsl(...) {
    exclude module 'rendering.indigo'
}

why require modules to "only depend on modules from core, common, or within their own library"?

Consider a "minimal" mod like Sodium, which is avoiding pulling in game-changing behavior because it is used by the Minecraft Speedrunning community. (This is all hypothetical) In its buildscript, it defines:

implementation qslLibrary("rendering") {
    autoDepend() // instead of always puling in all the rendering modules, it only depends on ones that it uses
    exclude module 'indigo'
}

This works fine for Sodium, perhaps for months. Later, though, Sodium calls a single line from a rendering module that depends on, say, something from block extensions. Now, with no change to their buildscript, they are now pulling in unwanted transformations and breaking the Minecraft Speedrunning rules! Additionally, this wouldn't be immediately obvious from Sodium's quilt.mod.json, since you would only see it depending on rendering modules, not block extensions.

In short, we want to prevent unexpected behavior when you think you're depending on something explicitly.

[TheGlitch76]

world is kind of big, especially if each of its submodules is to be managed by the same team.

I agree, recommendations on splitting up the world library would be appreciated.

I don't think there's a purpose in making blocks and items their own libraries, because they would probably be co-dependent. Perhaps there could be a split between extensions (namely block, item, entity) and then everything else?

[TheGlitch76]

I believe I have covered all concerns now.

[i509VCB]

Okay so I forgot to respond, so my issue with the RFC is similar to the community team one. The issue I see with ironing the structure of QSL here with specific modules existing makes a little confusing, do new modules need an RFC, how about collapsing modules.

What I think we could do instead is require a document to be maintained regarding the structure of qsl and how to setup of modules that is maintained by the team specifically.

[TheGlitch76]

do new modules need an RFC, how about collapsing modules.

From the very first line of the Explanation:

Libraries are included along with the names of the FAPI modules that would be under its scope. The actual structure of the modules in each library is up to the team, and it is not a goal to define how they must structure their modules.

[TheGlitch76]

I am proposing a Final Comment Period for this RFC. It will begin once both i509 and LambdAurora have approved this pull request (the full membership of the QSL team at the time of writing), and last the standard ten days.

[TheGlitch76]

I've changed up the wording on where we will go involving fat jars in QSL a bit. The relevant section now reads:

Ideally, there would be no common usage "fat" jars of libraries and modules because of Loader's automatic dependency downloading. We will probably have to provide fat jars until Loader is able to support dependency downloading, and discussion about stopping providing fat jars can happen there.

[TheGlitch76]

Apologies for the delay; I was on vacation when the FCP criteria were met. The Final Comment Period has begun and will end on Tuesday, June 22nd, at 00:00 UTC