octatonic v2 - design ideas and discussion

[Sleeves]

I've been rewriting my old mod manager (https://mods.vintagestory.at/octatonic) on and off for some time now, and I'm about ready to take its development seriously. This time I'm being much more practical about what really needs to be modular and what doesn't- my prior attempt at a rewrite split the manager into a library and a frontend, which was honestly quite unnecessary. Because I want a solid base to build on, I'd like to discuss some of my design ideas (and uncertain aspects) before hammering out a release.

Profiles

The new version will center around profile management, a feature which was implemented poorly late in its predecessor's life. Profiles are stored in your data directory (by default, $XDG_DATA_HOME/octatonic) as folders consisting of a header file (working name, please suggest a better one), a mods folder, and a config folder. Any given mod version appears once in the store directory, e.g. <data_dir>/.store/carryon/1.21.1 - the actual mod file is symlinked to whichever profiles use it, and the whole folder deleted if all references are gone (will likely be optional).

The interesting aspect here is how the current profile works. A persistent .current directory is used as a checkpoint for the actual profile you want to use. Should I load a profile titled wolfbait, the contents of wolfbait/mods and wolfbait/configs will be symlinked to the respective .current directories. Saving a profile empties its folder and symlinks the store paths of everything in .current in its place (or, in the case of configs, copied). Note that this design decouples octatonic from your game install; all you need to do is link .current/mods to VintagestoryData/Mods and .current/configs to VintagestoryData/ModConfig! Of course, that does mean it won't manage VS itself, which is something I'm on the fence about.

Prompting

Octatonic will prompt you if something needs specifying. For instance, imagine you install a mod via command and the latest version is a pre-release. You would see something like this:

info: current release is not of stable branch
[1] 1.0.5
[2] 1.0.5-pre.8
[3] show more
==> 1..3 | v <version>

This promotes quick usage without assuming what the user wants.

Dependencies

Dependency resolution will rely on the same VS-flavored semantic versioning scheme as modinfo files and will prompt (see above) when installing a hard dependency with multiple permitted versions. Ideally, I'd like to prompt the user before removing a mod if another depends on it, but I'm not sure if or when this will be added. Optional dependencies will not be managed unless they are officially included in a modinfo specification.

Example Structure

I realize describing file paths sentence-by-sentence is rather confusing, so here's a little diagram of the data folder:

- octatonic
	- .store
		- mymod
			- 1.12.9-rc.3
				- mymod.zip
			- 2.5.4
				- mymod.zip
		- trampolines
			- 0.3.2
				- trampolines.zip
	- .current
		- mods
			- mymod.zip (linked from myprofile)
			- trampolines.zip (linked from myprofile)
		- configs
			- trampolines.ini (linked from myprofile)
	- myprofile
		- mods
			- mymod.zip (linked from .store)
			- trampolines.zip (linked from .store)
		- configs
			- trampolines.ini

Limitations

The main drawback of the approach I'm taking is that I doubt windows support will be plausible. To be fair, I don't know how many people used the old windows versions, nor do I imagine most windows users would prefer this tool over the now-abundant GUI alternatives available. Still, it's a regression. I also don't think modconfig files will be tracked (i.e. indexed in the store, listed in profile headers) because the benefits appear slim at best.

Discussion

None of the previous ideas are set in stone, and only half are yet implemented. Please share any thoughts you have, lest I build the tool on a weak foundation. One point I'm particularly undecided on is what configuration format I'll use for profile definitions. Right now I'm looking at KDL, but other candidates include JSON and SCFG, and I'd love to hear about any others which may be better-suited. Also, what would your preferred workflow look like? Do you prefer an interactive or fuzzy search? Would a custom format string when listing your mods be worth the trouble?

[Sleeves]

I ended up using a similar format to ini for configuration, as I realized there's no good reason to store dependencies separately from their modinfo definitions, and thus no need for nesting. Profile definitions now look like this:

name="myprofile"

[mods]
coolmod="1.2.1"
library="0.2.6"
coolermod="3.2.0-rc.2"