Is there any community effort on XDG compliance. I am wondering this, as I found it is really tedious to set home for each language one by one, and they are useful go everyone using nix
For example, be setting something like to move the cache directory of elixir into XDG_CACHE_HOME
If no one is doing this, I will start a repo for this!
Personally I do not like my env beeing poluted with those variables, those binaries should be wrapped. On the other hand side, MIX_HOME and HEX_HOME are not only cache, but sadly also contain potential configuration.
Though from the read of the issues I created for hex and mix 2 years ago, both should understand XDG now…
What do you mean by wrapper? An alias?
Anyway I have created a repo here, so anyone can take and add it whatever they feel fit:
No, not an alias, a wrapper.
As created by “makeWrapper” or “wrapProgram”.
Basically a script that adjusts environment and args, then appends the args that have been given on call and uses exec for a cheap start.
Though again, why do you want to add XDG compliance to mix and hex? Both programs should adhere to XDGÂą.
In general, I consider it more useful, to provide requests and PRs to upstream rather than trying to fix the problem locally. Most projects I have asked to implement XDG, actually did eventually, as they have seen how sensible that approach is and how it is better than having just another folder in $HOME.
Âą For compatibilty reasons they will look up ~/.hex/~/.mix if XDG_*_HOME is not set. So make sure XDG_*_HOME is set in your shell, and mix as well as hex should properly use it.
The reason I am adding is because I found .mix and .hex in my home directory, which is properly related with I forgotten to set XDG_*_HOME in my shell previously. Thank you for reminding me that!
Btw what is the benefit offered by a wrapper, aside from reducing environment variables? I guess most env variable will be removed on building derivation(sandbox), and it shouldn’t be an issue?
I just hate the fact that any program could make an educated guess about what software I use, by inspecting the environment.
There are already 75 environment variables set in a fresh shell, only a handfull of them are under my control, most of them are just from the system. Some others are because nixos and HM want to avoid re-sourcing their environment files.
I think it is weird that everyone wants to try to move “hidden” folders away from $HOME, but at the same time doesn’t care for poluted environments.
XDG_* exists to have a handful of variables to specify the location for everything! Not to derive thousand other variables.
Your module would even add variables I’d never need, like Ruby, Postgress, Java, etc.
And I have to inspect the environment so much more often than my home folder…
You are right, the added variables wouldn’t be visible within the build, though doing nix build is not how I develop my software.
Most of the time I use just mkShell to give me the languages tooling and some libraries and then use the languages “native” tooling with imperative commands to develop the application, writing a nix expression for the software in development is rarely necessary as nixos is not a target system for the software I develop in my job.
Another point is that most of the non XDG conforming variables that toolchains give you just mix configuration, cache and data. Having those 3 mixed up makes backups hard, and currently I have my backups (nearly) not backing up known cache locations. The last one I know about I have to get rid of would be chromes cache, as that is also living in ~/.config. I just haven’t had taken the time so far to identify the exact exclude pattern.
There was a nix overlay for wrapping programs to behave according to XDG by default but it hasn’t been touched for 4 years
I think touching that again and using wrapProgram is a great idea. As much as I also prefer opening XDG issues upstream, not all upstreams are equally receptive to that - a lot of them outright reject it on principle, and others take decades to get there, and yet others have buggy implementations, or insist that their environment variable is the best one.
To some extent having local configuration to change the directories is necessary. I’d even go so far as to patch applications that reject it downstream, if I don’t stop using them.
While I agree that it is still not great to have mixed cache/config directories, at least not having those live in $HOME means my home directory isn’t cluttered when I don’t ignore hidden files (which happens occasionally, say when I need to delve into ~/.config), so I think it’s still worth it.
Most applications I know of (except chrome, and various emacs packages) that “support” XDG but ignore the cache/config/data split just dump it all in XDG_DATA_DIR, which is where I’ve taken to moving those.