Features for better scripting CLI use

[theofficialgman]

I am working on replacing my use of minecraft-mod-manager with ferium due to multiple issues at the project. However, there are a few things that minecraft-mod-manager does really well that I would like for ferium to implement.

1. add more options to ferium list. I need to be able to obtain the filenames of the installed mods that ferium has in the current profile and only that output. The verbose output does not show this currently. The config file (~/.config/ferium/config.json) also does not have this information, so I am not really sure how ferium even knows it (I assume it must know it in order to upgrade mods). Something like ferium list --filenames and then a list of filenames each on a new line would be good.

2. (similar to the scan module referenced here: Only update mods which are in the profile #115) add autodetection for mods currently residing in the mods folder but not in the profile. for fabric mods, you can try to obtain the ID for the jar file by reading its fabric.mod.json file and grab the id from it at the top. this will not work for all mods, but it will work for many. I could add this externally through another script, but that still requires 1 to be implemented.

3. when the user changes the version of minecraft (like when they go from 1.19 to 1.19.2) and make this configuration change in the ferium profile, don't dump all the old versions of the installed mods to the .old folder. only unrecognized mods should be moved to the .old folder, not mods installed by ferium previously

4. as mentioned in another issue, the ability to specify multiple mods at once with ferium add would be very nice. this one isn't a deal breaker for me since I can just stuff it into a for loop.

[theofficialgman]

5. modrinth has beta and alpha tags for mods and modpacks in addition to the regular releases. allow for filtering these mods/modpacks from being installed (or add them if they weren't already supported)

[theRookieCoder]

1. See Track the Date and time a mod is added/last updated #138 for why this is probably impractically to implement. Ferium simply dumps files into the output directory
   I think an alternative for now is to regex the output of ferium upgrade which contains the filenames
2. The mod ID and the mods' project IDs on the different platforms might not correspond, but the mod platforms do support file hash searching which is much more practical and is what is being used in the current wip implementation
3. I don't really understand what you mean? If a file is already downloaded, ferium will keep the file and won't download it again
4. Yes definitely a very useful feature as this will also decrease the amount of api requests when multiple projects are being added
5. I just created Add support for release channels #196 for this

[theRookieCoder]

I'll close this after 3 is clarified

[theofficialgman]

clarification on 3:

I would like to give an example of using ferium:

• create a ferium profile of minecraft 1.18.2
• execute ferium add for that profile for some mods, lets use sodium as an example
• execute ferium upgrade which (as of this date) will download and place the filename sodium-fabric-mc1.18.2-0.4.1+build.15.jar from modrinth

now lets say that 1.19.2 comes out and the user would like to update their instance from 1.18.2 to 1.19.2 along with their mods.

• change the config file for this profile through ferium from 1.18.2 to 1.19.2
• execute ferium upgrade for this profile

the user would expect that the currently installed mod (sodium, filename sodium-fabric-mc1.18.2-0.4.1+build.15.jar) be replaced with the updated sodium (for 1.19.2 sodium-fabric-mc1.19-0.4.2+build.16.jar), however this is NOT the case. Ferium will move the original mod sodium-fabric-mc1.18.2-0.4.1+build.15.jar to the .old folder and then add the new mod sodium-fabric-mc1.19-0.4.2+build.16.jar to the mods folder.

this is very poor and will lead to massive file bloat as old mods get moved to the .old folder every time a user changes the minecraft version of their instance. ferium should be able to cleanly update from one version of a mod to another, without leaving these files behind. If that means you need to add the filename of the installed mods to the ~/.config/ferium/config.json file, then that addition should be made to the code.

[theRookieCoder]

Ok I get what you mean now

What you're looking for would require #115 to be implemented. We can add a setting to delete (rather than move to .old) old files of mods to this feature. Maybe even use cron to delete .old files after a certain (configurable) period of time.

[theRookieCoder]

ferium should be able to cleanly update from one version of a mod to another, without leaving these files behind. If that means you need to add the filename of the installed mods to the ~/.config/ferium/config.json file, then that addition should be made to the code.

Also I'd just like to clarify that users shouldn't expect ferium to be able to do literally everything they need. There's a certain point where the cost of refactors, features, and code maintenance outweigh the usefulness of the feature. Of course, I still strongly encourage everyone to share your feature requests, but do understand that certain features may be outside the scope of the project (e.g. #138)

[theofficialgman]

if I might ask, is there a reason that you don't want to write the mod filename or hash in the config.json after it has been downloaded?

having that present would very easily allow both 1 (compare the hash stored in config.json with the local files and print any files that match) and 3 (delete files with a hash match if they are to be upgraded) to be implemented.

[theRookieCoder]

I think (for now) it's better to think of ferium as a mod downloader rather than a mod manager. Basically ferium was designed to be, and mostly still is, independent of the files that are in the mods folder.

[theofficialgman]

you should probably change your About page and README then to reflect that, because that is not what either of them indicate.
about:

Fast and multi-source CLI program for managing Minecraft mods and modpacks from Modrinth, CurseForge, and GitHub Releases

readme:

for downloading and updating Minecraft mods

Upgrading mods/modpacks

As you said, ferium is a mod downloader only. Please reflect this in your documentation. You deny wanting basic mod management features, but state ferium is a modmanager in the documentation. Pick one or the other.

Let me be clear, I don't expect ferium to have all these features already, or for you to even implement them yourself, but I need you to understand that this is a basic feature of "upgrading" that only gets compounded the more mods a user has installed.

I am more than happy to look into the codebase and see what can be done, but I won't do that if the project isn't receptive to it.