Folder based profiles

[tippfehlr]

The Problem

Having to switch between profiles doesn’t go well with different mod folders. Also, upgrading all profiles at once can only be achieved when ferium knows what profile is supposed to be active in another mod folder. (#277)

Your Solution(s)

A solution would be to operate on the current folder. That way it is clear to the user on which folder ferium is operating and switching folders is not a hassle at all. While not an issue for me, a downside to this is that the user has to navigate to the mod folder.

Another option would be to have an extra stage in profile selection, where a working profile is selected, but profiles in other folders stay active. Here it would be beneficial to print the folder and profile at the beginning of commands.

[theRookieCoder]

Having to switch between profiles doesn’t go well with different mod folders.

May I know how?

Also, upgrading all profiles at once can only be achieved when ferium knows what profile is supposed to be active in another mod folder.

Why is that so? All the profile information is stored externally so this isn't a problem.

[tippfehlr]

May I know how?

My point is that there can be multiple profiles in active use, e.g. I have a server and a client profile.
Though I admit that there is not much reason to change that because ferium still needs to know on which folder and profile to operate. My second solution seems appropriate to me here.

Why is that so? All the profile information is stored externally so this isn't a problem.

Say I have folder A with 2 profiles and folder B with 2 profiles, total 4 profiles, the current profile is A1. Now I want to upgrade all profiles, but ferium doesn’t know which profile in folder B it should upgrade (which profile was active last)

EDIT: I just read your reply here. The plan is to let GDLauncher manage the profiles and ferium manage the mods?

[T3sT3ro]

Folder based profiles have to be implemented carefully to grant benefits and avoid caching problems later. I think that the more robust way would be to depend on file system's features a little bit more than on arbitrary configuration files:

• a directory for each profile, it's name is the profile's name. This makes it virtually impossible to have 2 profiles with the same name, which is not true for the current implementation. Currently profiles are distinguished by their index in an ordered list int the config file.
• ferium-profile.json inside each profile's directory that holds a list of mods
• a current-profile symlink to selected profile in the main ferium configuration directory.
• mods would be stored as both a concrete jar file in a <feriumConfigDir>/mod-cache and as symlinks to the mod-cache in the <feriumConfigDir>/profiles/mods directory.
• Each mod in the mod-cache would be named after the SHA256 (or SHA512 to be future proof) hash of itself which would imply no redundant copies of the same mod would be stored, be it from a CF or Modrinth. By comparing their hashes it could also be easy to detect integrity errors and avoid unnecessary downloads (or redownload) if mod sites also somehow share the SHA256 hash (example case: mod author pushed an override to a version but didn't change semver — SHA helps to detect a difference).
• with how mod are stored, user could replace .minecraft/mods directory with a symlink to a <feriumConfigDir>/profiles/<profileX>/mods. This requires some testing if it's working, but if so, then that would reduce the workload the user has to do to actually upgrade mods, as the changes would be automatically reflected for the instance. This is the case when ferium output dir for profile is not set to the instance's mods/ directory (my case).

With this way the whole ferium configuration system file structure would look as follows:

.
├── current-modpack -> modpacks/Fabulously Optimized-4.9.3.mrpack
├── current-profile -> profiles/profileA/
├── mod-cache
│   └── e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
├── modpacks
│   └── Fabulously Optimized-4.9.3.mrpack
└── profiles
    ├── profileA
    │   ├── ferium-profile.json
    │   └── mods
    │       └── SomeMod-v1.0.jar -> ../../../mod-cache/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    └── profileB
        ├── ferium-profile.json
        ├── mods
        │   ├── SomeMod-v1.0.jar -> ../../../mod-cache/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
        │   └── UserMod-v5.2.jar -> ../user-mods/UserMod-v5.2.jar
        └── user-mods
            └── UserMod-v5.2.jar

In this concept, current profile and modpack are referenced by symlink at the top directory (current-profile/modpack), mod-cache serves a purpose of a global mod storage optimized for size, and each file in cache is named after a SHA256 hash of a jar file (thus reducing duplication). User mods are stored alongside profiles and profiles/<profilename>/mods is a directory holding only symlinks to real mods. This way, mounting a profile and changing active profile instance would be as simple as changing a symlink to appropriate mods/ directory in the profile (for example link .minecraft/mods to .ferium/profiles/profileA/mods). This relates to #109 and #219 (just delete/create symlink to enable/disable). #142 and #90 would benefit from this change. #321 would benefit, because import and export would be trivial.

And the biggest benefit, imo, would be the centralization of the files. I'm not a fan of having many different directories with mods all over my system. This would enforce the structure and would make it simpler to browse — everything is in one place. And if someone wants to get rid of all the mods and ferium all together, it's as simple as purging a directory.

This would also extend to other project types, for example plugins/, shaders/, resourcepacks/ etc.

I have also noticed, that the symlink to active profile would prevent from accidental active profile switches if someone was to manually tinker with the config.json. Currently active profile is stored as an index of profiles, which means that if the order was somehow changed (e.g. someone copy-pasted a profile into their json at the beginning), then the active profile would switch as well.