Seperate config profiles into files

[aschoettler]

I think the modpack support is really cool. But it would also be nice to have a way to share a profile I have made with friends or public communities so other people can use the same mods. Currently the best way I know of would be to share a shell script with many ferium add-x commands, or instruct someone on how to manually edit their global config file. Alternatively it would be nice to have one of:

• 1) a way to export a profile to a config file (yaml, json, toml, or even txt), and a way to import them to create a profile
• 2) a way to generate a shareable link (something like feriumpaste.com/<uid>) similar to vanilla tweaks that either temporarily or permanently hosts the profile configuration and settings (flags for the add commands).

I think (1) would be more transparent for people to see what they are downloading while (2) could have a simpler workflow.

More generally, and perhaps only in some alternative universe, I think there could be a more modular way of thinking about how ferium can be used, where a "profile" is nothing more than a folder containing a ferium.toml file and an output subdirectory. The file would specify the minecraft version and the mod sources, instead of tracking them globally. The default output folder would be ./mods, or set with a flag to ferium upgrade. There could still be a global cache for metadata like URLs and descriptions, but this might be a way to make profiles more modular and transparent, however I understand if this part is out of the scope of the project.

[theRookieCoder]

Kyle had an idea that we could split the profile into seperate files in the config directory. Then one could easily share single profiles with people.

[theRookieCoder]

Implementing it wouldn't be too hard because we can just construct the files back into a regular config in libium

[JustSimplyKyle]

For shareable links I recommend https://0x0.st It's has a very simple api(just curl uploads!)

[theRookieCoder]

I think the shareable profiles should be a seperate feauture, make a seperate new issue if you want that

[theRookieCoder]

obj-obj/ferium is a fork that has a subcommand based way to import/export profiles. It can be used as a temporary workaround. Though keep in mind I did not write the implementation, and it won't be how it will be implemented in the official repo.

[obj-obj]

Yeah it's literally just yeeting the profile object into serde_json

[theRookieCoder]

This should also allow settings like the GitHub PAT, CurseForge API key, maximum parallel network requests, verbosity of output, download chunk size (for #284), etc to be stored in config.json instead of profile data

[BirdLogics]

I would really love to see Ferium move to a ferium.toml and potentially ferium.lock based config rather than everything going through the CLI. A global config makes a lot of sense for graphical apps like Modrinth and CurseForge, but I don't think it make a lot of sense for a primarily CLI app like Ferium.

When I use a package manager like Cargo or NPM, I only use the CLI to edit dependencies maybe 30% of the time. The flexibility of a Cargo.toml means that every single feature and option doesn't need to be added to the CLI.

Using individual config files would open the doors for new features like:

• Specifying specific versions of mods to install
• Upgrade rollbacks by restoring a lock file rather than the whole mods folder
• Support for resource packs and data packs
• Ability to automatically download Minecraft, e.g. fabric server.jar

I've used Ferium to host a couple small servers, and it works really well compared to other solutions I've found. The CLI support is really the clincher when it comes to using it to manage servers since I can use it to upgrade mods over SSH.

Another bonus advantage is that the config could easily be added to version control. I'd love to be able to put profiles in version control and commit just my ferium.toml, .config folder, and server.properties if it's a server.

[theRookieCoder]

@BirdLogics your comment really got me thinking. I created a post about my thoughts at #425.

A global config ... I don't think it makes a lot of sense for a primarily CLI app

The reason I made it like that is that ferium was really created for client players who wanted some simple automation. It really wasn't made with server users in mind. I'm not discouraging usage in that manner, I'm just explaining why it is that way.

I knew that the JSON format, while familiar to most, is pretty terrible for editing. I did consider TOML in the beginning, but chose JSON for its ubiquity. It seems I shouldn't have done that, as the project has gotten more complicated it's become harder and less friendly to edit manually.

The features you mentioned wouldn't really be affected by changing the way configs work. It would make configuring easier, but no easier to actually implement the features.

works really well compared to other solutions I've found

I recently came across mcman, you could say it's a competitor to ferium, particularly in the Minecraft server space. Have you tried it?

A solution

You can actually change the config file path. Coupling this with something like direnv would allow you to have a specific ferium config file for a directory, which would be independent of your other configs.

Now you can check in your config file to version control too. This is what I did for a modpack I tried to make (but gave up on).

[HoldYourWaffle]

I recently came across macman

That project seems to be at ParadigmMC/mcman now.

[theRookieCoder]

I recently came across macman

That project seems to be at ParadigmMC/mcman now.

Oops that was a typo.