Follow XDG Base Directory Specification

[unai-ndz]

Unison stores his config on $HOME/.unison $XDG_CONFIG_HOME should be used instead or if empty the default $HOME/.config/

Others variables applies for user data, cache and directories. Specification here: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

[pchiusano]

This isn't used anymore, but will keep this in mind for the future.

[haarts]

Please use the XDG standard!

[aryairani]

Hi there! Could you give a little more context? From my perspective this is a new and unfamiliar standard. Which distributions follow it? What would it even look like to use the standard? What are the consequences of not following it?

[haarts]

Gladly! The XDG spec exists to organize the jumble off hidden files and directories in a user's $HOME. It places files in locations the user expects. But perhaps this post explains the why best. The spec was first published in 2003. Hardly new anymore. :) The Arch wiki (as usual) has the best summary IMO. Debian encourages package maintainers to use XDG too.

The tmux author resisted implementing XDG support strongly. But it has since been added.

The consequence of not following it are best outlined in the post I linked. For me personally it means explicitly adding the .ucm directory to my backup script (and probably forgetting to do so).

With it I feel a program is respecting my system.

EDIT: the actual spec

[gerardbosch]

Hi! @aryairani I always put the example of backups. When you run an automated backup on your homedir, you don't want to be manually maintaining an exclusion list for every directory that contains stuff like application's cache for example. If applications follow that standard you just exclude the $XDG_CACHE_HOME (typically ${HOME}/.cache/), but allow configurations $XDG_CONFIG_HOME.

The Freedesktop.org (aka XDG) spec gives a guideline to organize such files. Most Linux distros and even Mac apps follow it.

User data for the application is something that you would probably want to backup, but I've seen a lot of applications putting in $XDG_DATA_HOME (~/.local/share/) a lot of heavy stuff that can be recreated by the application itself, instead of user data strictly.

---

I've just installed ucm via Nix following this, and I realized that the ~/.unison/ directory was created when I run ucm the first time.

Should this ticket be reopened so that UCM honors the XDG spec? +info on the spec

Also in the docs, the fact that ~/.unison is created:

Cheers!

[ceedubs]

I agree that ideally Unison would follow the XDG spec.

In this issue a few different types of files have been discussed. Unison stores files for config, the user codebase, and credentials. I'll try to break down these pieces a bit. Everywhere that I say that we should look in $XDG... I mean following the default chain in the XDG spec if the env var isn't set.

It may be useful to people interested in this issue to know about the flags that I mention below.

Config

Currently this is stored in ~/.unisonConfig.

I think that it should follow the following chain for Unison config:

• [ ] $XDG_CONFIG_HOME/unisonlanguage/config (or .config or whatever)
• [x] ~/.unisonConfig for backwards compatibility

Codebase

Currently this is stored in ~/.unison, though the -c and -C flags can be used to override the codebase path.

I think that it should follow the following chain for the codebase:

• [x] paths provided by -c and -C flags
• [ ] $XDG_DATA_HOME/unisonlanguage
• [x] ~/.unison for backwards compatibility

Credentials

I believe these already follow the spec and are stored in XDG_DATA_HOME/unisonlanguage/credentials.json. Maybe that should be .credentials.json, but that's a different issue.

[gerardbosch]

Thanks @ceedubs for detailing and breaking it down for each file. So then, should this ticket be reopened to track it?

• For credentials, yes, now that you said I see they are in XDG_DATA_HOME 👍

• Regarding config, you propose $XDG_CONFIG_HOME/unisonlanguage/config, but the last directory seems redundant, doesn't it? Typically XDG_CONFIG_HOME is ~/.config (for example in credentials it are not at $XDG_DATA_HOME/unisonlanguage/data -- see trailing data again).

• [ ] In case this gets changed, docs in the screenshot above should be updated too :)

Hope this helps!

[ceedubs]

Regarding config, you propose $XDG_CONFIG_HOME/unisonlanguage/config, but the last directory seems redundant

@gerardbosch I was thinking of config being a file, not a directory. You could potentially make $XDG_CONFIG_HOME/unisonlanguage a config file, but that makes it a pain in the future if ucm decides that it wants multiple configuration files.

[gerardbosch]

@gerardbosch I was thinking of config being a file, not a directory.

Cool! Now I see, sorry for my confusion 😅. I see the issue is open again :)

[sellout]

Two suggestions relative to @ceedubs concrete proposal:

First,

Codebase

Currently this is stored in ~/.unison, though the -c and -C flags can be used to override the codebase path.

I think that it should follow the following chain for the codebase:

• [x] paths provided by -c and -C flags

• [ ] $XDG_DATA_HOME/unisonlanguage

• [x] ~/.unison for backwards compatibility

This should be in $XDG_STATE_HOME, not $XDG_DATA_HOME. DATA is analogous to /usr/share, which is intended for “read-only architecture independent data”, while STATE is analogous to /var/lib, which is intended for “data that programs modify while they run, and that pertains to one specific host”.

This distinction allows DATA to be on a network share or synced, while STATE should not be.

And second, there is also .unisonHistory, which I believe should live in STATE as well.