Allow requiring mod dependency versions

[appgurueu]

Problem

Currently, we have dependencies and optional dependencies. That's not enough.

We can't declare that we need at least a certain version of a mod: Instead we have to tell the user at load time (e.g. by throwing an error) that they need to upgrade, which is poor UX.

It would be much preferable if they were directly asked to upgrade a library if they upgrade to a new version of a mod using it right in the content dialog.

We also can't declare that we need at most a certain version of a mod, that the user mustn't upgrade a certain mod if they want our mod to function.

Solutions

Adopt version requirements as found in common package managers, e.g. based on SemVer.

Worth considering: What do we do when there are conflicting version requirements? How much effort do we want to spend on finding a satisfying configuration? (Do we want to go all SAT solver?)

Alternatives

Doing nothing is not that bad, mods can after all include arbitrary version constraints in their code (and give warning or error messages appropriately) so this is definitely not very high priority.

Additional context

See also #5187, which concerned itself just with the ability to declare incompatible mods but ultimately ended up with the same topic.

ContentDB would also need to add support for this. But I'm not very concerned with this, generally CDB is a bit ahead of Luanti in such regards (e.g. with "Supported Games").

[rubenwardy]

The fundamental problem with this is that it breaks the mod name system - suddenly mod names from different places aren't interchangeable and it breaks forks

Introducing provides may be a solution to this - a fork could provide the name of the source mod but have a different technical name and versions. Each provide could have a corresponding version

[sfan5]

We're inviting lots of complexity if we want to implement this.
On the other hand mods simply refusing to run if they detect incompatibilities sounds reasonably pragmatic.

I think a dependency-based package manager is already a quite unique feature in Luanti. As far as I've heard most games require you to individually install mods and hope they fit.
Versioned dependency management is more of a programming language thing.

What do we do when there are conflicting version requirements?

Even if the answer to that is "error out", imagine the mess when an user wants to use A - which requires C<3 - in one world and then B - which requires C>=3 - in another world.
Do we add mod "virtual environments" so he can install both versions of C? (hopefully not)

To avoid this situation we can encourage mod writers to rename their package (foobar -> foobar2) if they make far-reaching changes that totally remove chances of backwards-compatibility.

[kromka-chleba]

To avoid this situation we can encourage mod writers to rename their package (foobar -> foobar2) if they make far-reaching changes that totally remove chances of backwards-compatibility.

Possibly you could make a hash (checksum) of the package contents like Nix/Guix package managers do.
For example a full identifier of the luanti package on Guix is lw66j2bnm0v7736a5z2h6n6sp1zr40c2-minetest-5.10.0 (hash-name-version). Then the name wouldn't really matter as each package would be strictly defined by the content it provides. But then defining a range of compatible package versions would be challenging.

[sorcerykid]

Given that mods in the Luanti/Minetest ecosystem do not adhere to a single versioning system, attempting to enforce dependency requirements based on SemVer would be near impossible. I know there are plenty of mod authors that publish rolling releases, and they use the date of release as the version number. It would likely take years to achieve significant adoption of dependency versions by the community, and even then there would remain hundreds of legacy mods that don't conform to the proposed specification.