ferium
ferium copied to clipboard
gorilla-devs
Add multiple mods at once
The problem
Currently the ferium add command only allows you to define one mod at a time. But more often than not you know that you want to add at least two mods into the profile.
My solutions
Allow you to define multiple mods at once: ferium add sodium lithium phosphor
If you're wondering why it's taking so long, the problem is that it's a little complicated to add multiple mods at once if you need to adjust the override flags. I'm thinking of a system of 'upgrading', i.e. determining the latest versions of the mods given, and then adjusting the overrides. This issue is also why scanning is taking so long to implement even though most of the backend work is done (thank you so much @tuxinal !)
how would you handle errors? There are a few possible ways:
- abort when an error is encountered (but add mods before the error)
- keep adding the other mods after error
- check all mods beforehand and only add them when all mods are valid
the big package managers (apt, pacman, etc.) seem to apply option 3.
I implemented option 2 and when I misspell a mod it’s convenient that the other mods are added nonetheless and I only have to add the misspelled one again though.
Option 1 seems like a bad Idea.
I would treat already added mods like a success: The user’s intention is to add them, so the end result is correct.
Interesting question, my current plan is 2 because that's what is used when upgrading, and as you said I find it much more convenient. As for
I would treat already added mods like a success: The user’s intention is to add them, so the end result is correct.
I will be changing already added to a warning without an exit code.
I would recommend 3, as with 2 it would make your command order dependent on what gets created as output. For a sodium doesn't-exist lithium would flop on 2, only giving sodium. But if doesn't-exist comes first nothing gets installed, etc.
Error early, list the mod that had trouble. Do not write anything on a failed command. A good nicety for 3 would be to list all mods that failed to fetch all at once instead of raising on first error. But this may be tricky to implement.
A good example of why 2 is a bad idea is if you accidentally add a paragraph of text from a failed copy paste. And you get Sodium is a free and open-source rendering optimization mod ... as the mods argument. And free/a/mod may be real names for mods and get installed wrongly.
For a sodium doesn't-exist lithium would flop on 2, only giving sodium. But if doesn't-exist comes first nothing gets installed, etc.
Hmm you seems to be describing option 1??
A good example of why 2 is a bad idea is if you accidentally add a paragraph of text from a failed copy paste. And you get Sodium is a free and open-source rendering optimization mod ... as the mods argument. And free/a/mod may be real names for mods and get installed wrongly.
Huh interesting, I suppose I'll make the default 3 then with an option of selecting no. 2
Yeah sorry. I was explaining 1 but accidentally called it 2. That's on me for not rereading what i have written. :sweat:
However, my idea that 3 would likely be the best default still stands. As it makes it clear that errors do not change state, so issues like "oh i hit an error inside the tooling and now its put my modpack in a corrupt state with missing dependencies" wont happen.
An idea would be to call the argument --keep-going to turn on the second mode. It should at least avoid any accidental copy pastes and make it clear that it will keep going.
Haha no problem.
As it makes it clear that errors do not change state
I think this is a fair point since this is the approach I took for removing mods too. However we have to remember that for things like directory scanning, it's very normal and expected to have some mods that can't be added, e.g. because they couldn't be found, have 3rd party access restricted, are not compatible, etc.
I haven't decided the exact flow when adding multiple mods since there needs to be a way to troubleshoot incompatible mods, and it now occurs to me this would be impossible with option 3. I will offer both options through a CLI flag but I'll have to experiment around to determine the default.
I think implementing 2 is enough for a mod manager. Option 3 needs a totally different approach (chenking mods first) and doing it as a command line flag seems a bit unnecessary to me.
I have added preliminary support for this in 40a1043
It is functional, but it's slow and makes too many network requests for my liking (~2 for every mod)