Put config files in XDG directories on Linux?

[icefoxen]

This is really a personal preference, but would you consider having ~/.config/mutagen/config.toml or something along those lines as the preferred config file location? If you wish I can submit a PR for it, though I kinda suck at Go.

[phromo]

Same issue here! Mutagen is working great, just wish it wouldn't litter my home directory with it's .mutagen. Was just about to create the same issue.

See https://www.reddit.com/r/linux/comments/971m0z/im_tired_of_folders_littering_my_home_directory/ and https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html for more rationale and information.

[xenoscopic]

Hey @icefoxen and @phromo, thanks for the input. I've seen those links before actually, but unfortunately changing the default behavior at this point would break things for a lot of users.

I could potentially add an environment variable that would make Mutagen behave differently. E.g., if MUTAGEN_USE_XDG=true, then Mutagen would use XDG environment variables (e.g. XDG_DATA_HOME, XDG_CONFIG_HOME, XDG_CACHE_HOME, etc.) to locate configuration and/or store data.

How does that sound as a compromise? I realize that it litters up your ~/.bashrc a bit, but I guess that's at least a little less visible.

If Mutagen eventually has a GUI, I'm not quite sure how to make such an environment variable work there... I guess its behavior can be controlled through some other mechanism.

[icefoxen]

What I was thinking was that it would search the XDG paths for a config file first, however if it doesn't find anything it would still look at ~/.mutagen.toml or whatever. That way it can default to the desired behavior without breaking things for current users. Then, maybe someday it could stop checking the old config file location.

[xenoscopic]

@icefoxen I guess we could do that. Let me sleep on it, try to code it up, and so long as it doesn't clutter things up too much, I'm not against it.

Before shipping that change, I'd like to have a better idea about what Mutagen's configuration and data storage story is going to look like long-term. Home-directory dotfiles and dot-directories are annoying, but they're not nearly as annoying as having configuration files in 800 different locations with weird implicit behavior.

One reason I'm concerned about this is that I'm really starting to look at releasing a GUI-based build of Mutagen¹ to help make daemon management automatic (it's easier to auto-start GUI programs on most platforms than it is to start backgrounded daemon processes) and facilitate things like #68. It would probably just be a tray icon application for now, but it would still have to be built to use the GUI subsystem on Windows and as a .app bundle on macOS. But then there are questions about turning on sandboxing, using more idiomatic data storage locations, etc. I still think the configuration file is going to be stored in the user's home directory (either ~/.mutagen.toml or the proposed XDG-based path — I can't see users wanting to dive down into ~/Library/io.mutagen.configuration.plist and editing some XML), but other stuff might live in the system-provided cache and data directories.

Anyway, none of this would block the proposed change, but I feel like Mutagen should have a plan before embarking down this road.

¹ This would be in addition to the existing command line version — it wouldn't replace it.

[xenoscopic]

@icefoxen @phromo

I've been thinking about this a bit more and I do have one concern/thought: Mutagen still needs to have a well-known location on remote systems to which it can copy mutagen-agent binaries and execute them. Right now this is ~/.mutagen/agents (and more concretely it's .mutagen/agents/ with the assumption that the default working directory for remote command invocation is the user's home directory).

I can't really think of any elegant and efficient ways to work around the need for a well-known location for these binaries. Mutagen would have to do significantly more probing of remote environments at connection time and have a large amount of special logic to handle different remote setups if it wanted to try to store these binaries in XDG directories. It would be slow and fragile.

Someday Mutagen adoption may be at a point where mutagen-agent can just be invoked from a system directory, but that's a long way off, and Mutagen will almost certainly carry around its one-sided installation strategy for a few more years, if not indefinitely.

So we can still relocate configuration and data files to XDG directories, but the agent binaries will probably still need to create ~/.mutagen on remote systems.

[icefoxen]

Aha, now there is an interesting edge case! Out of curiosity, where does it currently put these binaries on Windows?

[xenoscopic]

@icefoxen It also sticks them in .mutagen/agents in the user's home (%USERPROFILE%) directory. On Windows, the .mutagen folder is marked as hidden. Using the same location is what allows Mutagen to invoke the agent in a ~platform-independent fashion.

[poliorcetics]

Using a ~/.cache/mutagen/ for generated files and ~/.config/mutagen/ everywhere, marking those directories as hidden on Windows, would probably satisfy everyone using mutagen. You could add a note that XDG_* vars are not respected for consistency concerns over several OSes while still having XDG-looking paths for those that want them. The people using mutagen are developpers/tech-aware users, they won't be thrown by a tool putting things in ~/.cache and ~/.config.