Sodium

Sodium

35M Downloads

Supplementaries forcefully modifies user configuration files to create false dependencies from Sodium

jellysquid3 opened this issue ยท 16 comments

commented

For some reason, Supplementaries has decided to modify the user's configuration files (specifically fabric_loader_dependencies.json) to trick Fabric Loader into thinking that Sodium has a dependency on Indium.

I'm not sure why this is being done, but it has the consequence of preventing the user from modifying the file while the mod is installed. This causes massive breakages as users can't specify their own override to make the latest versions of Sodium compatible with Indium, while we wait on an update from upstream.

We need to work with their developers to get this code disabled so that the breakages stop happening, or add a breaks for the problematic versions until it is resolved.

commented

All past/current versions of Supplementaries have been marked as incompatible. The author needs to push an update which removes this functionality. Any newer version of Supplementaries will not match the version string, so if they bump the version, that will be enough to resolve it without our input.

commented

Also, another interesting consequence of this code is that (at one point) installing Suppelementaries would have broken the user's installation of Sodium permanently, as Fabric will suddenly begin complaining that Indium is a dependency of Sodium... This would explain so many random user reports we've had with nonsensical dependency resolver errors.

commented

@jellysquid3 I'm guessing you didn't actually talk with Supplementaries dev MehVahdJukaar. Cause if you did, you would've found out that the sodium/indium dependency forcing was removed many months ago on Sep 21, 2023. Here he tries to undo the changes he was doing to user's configurations
MehVahdJukaar/Supplementaries@9e0476e#diff-5a767df08dc7990908683da103784271bb930ab4d64bbc87183303549956c88a

So you just marked all versions of Supplementaries are incompatible despite 1.20-2.6.3 and newer not having the code. Current 1.20 Supplementaries that is perfectly fine now is marked as incompatible by Sodium. Nice.

Second, "I'm not sure why this is being done". I believe I hinted at this before.

Modders are absolutely sick of getting nonstop bug reports from Sodium because of Sodium breaking/not implementing FRAPI because users don't know that they also need Indium. It isn't Sodium that gets these reports. It's everyone else. Supplementaries dev got sick of all the reports and tried to make it so that users gets a warning screen to add Indium if Sodium is present.

After all, Sodium is basically required to have Indium in order to properly work in any large modpack. It's 100% a required dependencies. Just that Sodium refuses to mark Indium as a dependency which causes all these problems to begin with and makes modders unhappy with Sodium. So much so that in past, they tried to forcibly make Sodium say Indium is a dependency as Supplementaries did back in 1.19.4 and older.

commented

I should note that https://modrinth.com/mod/no-indium exists as a tiny JiJ-able mod specifically to notify the user about missing Indium. Gymnastics with dependency overrides or whatever was happening there is and was never necessary. Further, enough users use Sodium without Indium-requiring mods such that always requiring Indium is unnecessary. I can assure you Caffeine gets plenty of bug reports from users not installing Indium when they have Sodium and other mods. If you have a look at our current milestones, you'll see that FRAPI implementation is on the roadmap and coming sooner rather than later.

commented

So first of all apologies for the controversity, I knew adding that would have sparked some funni.

Anyways as said above that code isnt there anymore and was shortly lived.

Having said this I still stand by my stance in which I firmly believe that its not our duty to assure our mods work when others mods break them.
It should not be our duty to JIJ stuff in our mods or show warnings when the very loader we built our mods on is being compromised. We do have Fapi as a dependency afterall, that is our dependency, not Indium.

It should be Sodium responsibility to inform users that Indium is required for sodium to run properly in a modded environment (yes it is for most of users as most of them play with other mods that are very likely to use Fapi).
A warning message when some fapi call by other mods is detected would be all that is needed really.

commented

It's obviously entirely infeasible for Sodium to detect if some other mod is going to require Indium. Scanning all other mods' bytecode for FRAPI calls is a ridiculous. It would be easier if the mods using FRAPI simply declared that dependency by means of JiJ-ing no-indium. I don't make the executive decisions around here but I don't think you're going to get a resolution to this issue like this. If you don't want to warn the user about your mod requiring Indium because it uses FRAPI alongside Sodium as is the most common case, you'll have to wait for Sodium to implement FRAPI itself.

commented

The specifics of how such a dependency detection should be handled shouldnt be of our concern. While that one you say might be unfeasible i'm sure there are others like intercapting api calls or just looking at the declared deps in the mod .json.

Regardless its something that its not up to us to "fix" by adding extra banners and JIJ stuff. I know thats easy to do but doing so would normalize such behavior of breaking other peoples mod and requiring them to fix or warn users about, and that is not acceptable for me.
Imagine if more mods were to do this, it would of course be detremental to everybody

commented

The situation is simply going to have to resolve itself when the FRAPI PR is implemented then. I don't expect any other measure to be added in the mean time.

commented

I've seen users ask why Sodium doesn't depend on Indium and I have no answer for them. Sodium's lack of FRAPI support can hurt the Fabric ecosystem as evidenced here. Unfortunately Fabric itself doesn't support conditional dependencies (FabricMC/fabric-loader#464) or conditional loading (FabricMC/fabric-loader#177), and Fabric Loader should have some transparency about this type of thing (FabricMC/fabric-loader#836). It's understandable why the dependency override can make sense to users. Mod devs cannot put their own messages in the Fabric Loader window, after all.

I know Jelly is aware of this issue and this is just a misunderstanding and all will be resolved with Sodium 0.6 with Pepper's PR. Of course that requires mods support that version and the versions of Minecraft it runs on for it to effect users. So it'd just be nice for Fabric to support this situation better.

commented

I'm pretty sure nothing is being misunderstood unless you would like to point out what in particular that is.

commented

The misunderstanding being that current versions of Supplementaries override Sodium's dependencies.

commented

@TelepathicGrunt that code replacing it is still problematic! Now it is overriding user configuration in the other direction preventing them from adding their own overrides on Sodium, which is what the problem reported above is. Unless you can point at a commit undoing that change, the bad behavior is still in current versions of the mod.

commented

@TelepathicGrunt I'm guessing you didn't actually decompile the releases being published to see what they were doing.

image

Because the code is still there in the latest release (Supplementaries 1.20-2.7.32) which is causing the exact issue we described. The source code in the repository does not match the binaries.

commented

Modders are absolutely sick of getting nonstop bug reports from Sodium because of Sodium breaking/not implementing FRAPI because users don't know that they also need Indium.

Having said this I still stand by my stance in which I firmly believe that its not our duty to assure our mods work when others mods break them.

I don't care how upset with me you are. Trashing user configuration files and deliberately preventing people from using other mods correctly is completely unacceptable. We don't go out of our way to break your mods -- It's just a matter of being one person, and not having the time to implement a gigantic API surface.

Other people are free at any point to contribute back to our project to see the issues you want fixed. You are receiving my code for free, and I'm doing the work normally allocated to teams. This is an open source project. At any point you could have taken the 30 seconds out of your life to ask how we could make this easier.

Oh, wait, you did ask!

image

And we gave the obvious and trivial answer that did not require vandalizing other people's installations.

commented

The infuriating part is that I have actually been cooperative with you, and have been trying to upstream changes in other projects (#2298 and MehVahdJukaar/polytone#7 (comment)) to fix issues you are reporting. This is despite the fact that you repeatedly flame me at every opportunity, and talk constantly on your Discord server about how badly you want to break Sodium, and how much you think Sodium is a terrible mod.

commented

We've solved the issue on our side, and if Supplementaries isn't updated to stop doing this, we will simply block all versions of the mod. Your behavior towards me is unacceptable and the post-hoc rationalizing in this thread about how it's somehow "justified" because you don't like what we're doing is absurd.