Welcome! Please see the About page for a little more info on how this works.

Ask a Question

proper XDG support

+4 votes
in Tools by
retagged by

XDG_CONFIG_HOME does not need to be set explicitly, and tools follow XDG spec should just write to $HOME/.config/clojure

Right now, if XDG_CONFIG_HOME is not set, it just writes to $HOME/.clojure

more context here also:
https://clojureverse.org/t/opinion-about-xdg-support-by-the-clojure-tools-deps-cli/9814/3

by
Do XDG systems always have $HOME/.config even if it is empty? If not, then what if the CLI were the first tool to run in a new user account -- it wouldn't find $HOME/.config and XDG_CONFIG_HOME wouldn't be set, so wouldn't it deduce this was not an XDG system and write to $HOME/.clojure instead of $HOME/.config/clojure? (this question would apply to all tools in such an environment, so I'm wondering what creates $HOME/.config in the first place)
by
According to arch wiki, 'only XDG_RUNTIME_DIR is set by default through pam_systemd(8). It is up to the user to explicitly define the other variables according to the specification.'


https://wiki.archlinux.org/title/XDG_Base_Directory

But in reality, if you check how apps imp XDG spec, most of them just go by following logic without check XDG_RUNTIME_DIR i think.

1. if HOME/.clojure exist, use legacy path
2. else use XFG spec, (or (getenv XDG_CONFIG_HOME)  (path HOME/.config/clojure))

XDG_CONFIG_HOME (and the other xdg vars) are unset on most distros, and there are defined defaults that should be used instead. Here's the part clj tools get confused, because it should just write to my HOME/.config/clojure instead of fall back to legacy path.
by
On an arbitrary system, before installing Clojure, $HOME/.clojure will not exist -- so you are essentially requesting Clojure CLI switch to XDG on all systems, based on that logic in your comment.

Did I misunderstand you?

1 Answer

0 votes
by

The question continues to be: how could the Clojure CLI definitively know that you wish to use XDG configuration options. If there is a definitive answer to that question, I'd be happy to use that to select this behavior. We're not going to change that to be the default.

Another option would be to have a Clojure CLI specific environment variable that you could set to do that (but you're going to have to take that action).

by
edited by
One way to determine this, used by the Freedesktop tools, is to check first if the env variable exists (XDG_CONFIG_HOME), and if not, check if the `$HOME/.config`folder exits. That's the implementation in `pyxdg`. I mention it here[1]

Regarding the alternative option of a Clojure CLI-specific environment: Although I would personally prefer XDG taking precedence over `.clojure`, I would prefer that specific option over the current situation, and I'm just going to point to Haskell#Stack as one example doing that[1]

The reason is that I, as an XDG user, have more software than just Clojure, and I don't want Clojure to determine whether or not I have to set the` XDG_CONFIG_HOME`. I think It should be backward. I decide whether I set that variable or not, I decide whether I take advantage or not of XDG, and then I install Clojure, and maybe tell it to respect XDG or not. I still would prefer not to tell that last part to Clojure, but I understand the compromises.

Notice most other examples in that Archlinux table made the full migration, where the `$HOME/.name-of-the-software` is considered Legacy and the default behavior is to follow XDG.

I think that from Clojure point of view, the new ideas would be something like:

<xdg-config-path>/clojure exists? and ~/.clojude doesn't exist? use the existing one.
<xdg-config-path>/clojure doesn't exist and ~/.clojure exists? use the existing one.
But Both exists? ... well, you decide.
But Nothing exists? ... you also decide :D.


[1] https://clojureverse.org/t/opinion-about-xdg-support-by-the-clojure-tools-deps-cli/9814/3?u=jgomo3
[2] In the table that @sg-qwt shared from the Archwiki, search for Haskell#Stack: https://wiki.archlinux.org/title/XDG_Base_Directory
by
Your last para is essentially what the Clojure CLI currently does.

I moved ~/.clojure to ~/.config/clojure and the CLI was perfectly happy to use that directory instead. As long as only one or the other exists, the CLI will already "do the right thing".

If neither exist, it will default to ~/.clojure

If both exist, I think it will default to ~/.clojure (I'd have to double-check that -- someone ran into exactly this situation on Slack recently and was making changes to the "wrong" use deps.edn and couldn't understand why it didn't take effect.
by
Just a small clarification.

In the last paragraph, when I said, "Well, you decide" and "You also decide :D," the "you" is meant to be whoever will make the design decision in case of doing something about this issue.

I'm clarifying because it could be interpreted as "the user," which is not what I meant.

I intended to leave those two options as open decision points.
by
Right, and I'm saying that "you" (the core team) has already essentially "decided" based on what the current behavior is in these situations.

Is there part of the current behavior that you think is "wrong"?
by
When no folder exists, if the system is XDG but the environment variable XDG_CONFIG_HOME is not set, the first clojure execution should create ~/.config/clojure, but it creates ~/.clojure

When ~/.config/clojure exists in an XDG system but the environment variable XDG_CONFIG_HOME is not set, clojure should use it, but uses ~/.clojure instead. This particular case is exactly the experiment you did by moving ~/.clojure to ~/.config/clojure, but I get a different result (the only detail is that I'm making sure the environment variable is not set).

I'm testing this in some droplets in digital ocean with the last ubuntu. I tried with both the linux and posix install.

Beside that, it is my opinion that if the environment is XDG, all the possible combinations should give priority to ~/.config/clojure over ~/clojure.
by
Thanks for the clarification. I re-tested and realized one of my machines has XDG_CONFIG_HOME set and the other does not, and I just hadn't noticed the difference -- and, yes, I confirmed the behavior you highlighted and that does seem wrong to me.
by
"if the system is XDG" - how do you check this?
by
I don't know if this helps, Alex, but I have the following env vars set by default on my Ubuntu system it seems:

> env|fgrep XDG
XDG_RUNTIME_DIR=/mnt/wslg/runtime-dir
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop

And, in general, I would say if XDG_CONFIG_HOME is not set but ~/.config/clojure exists and ~/.clojure does not, then the CLI script should assume XDG and use ~/.config/clojure

What happens now is confusing/error prone, because if someone creates ~/.config/clojure/deps.edn (or moves ~/.clojure to ~/.config/clojure) they would expect it to be used -- even without XDG_CONFIG_HOME -- but without that env var, the CLI creates ~/.clojure and ignores ~/.config/clojure
by
In both cases, the user has to explicitly do something - either create ~/.config/clojure or set XDG_CONFIG_HOME. Between those, setting the env var seems more obvious to me.

I don't think it's confusing now, this is documented (https://clojure.org/reference/deps_and_cli#deps_sources) and seems very clear to me:

    User - cross-project configuration (typically tools)
        Locations used in this order:
            If $CLJ_CONFIG is set, then use $CLJ_CONFIG (explicit override)
            If $XDG_CONFIG_HOME is set, then use $XDG_CONFIG_HOME/clojure (Freedesktop conventions)
            Else use $HOME/.clojure (most common)
by
Yes, it is documented. That's good. But I think this is kind of a proposition to change the current behavior. Why? Just because $XDG_CONFIG_HOME is meant to be an option for the user to overwrite the system behavior, independently of Clojure: I, as an XDG user, can change the location of the config folder by defining the environment variable XDG_CONFIG_HOME. It is about changing it more than actually setting it.

But the current documented behavior of Clojure interprets that variable like that is the only way to set the XDG config folder, which is not the case. This causes something that should be optional for an XDG user to become mandatory if the user wants Clojure to play the game.
by
I am still asking the exact same question I asked at the very top of this thread - how can the Clojure CLI know that you want to use XDG config? If there is some other answer to that question, then I'm happy to change the second if condition in that logic. I'm not changing the current behavior otherwise.
by
I gave my answer to this question but maybe it got lost in the back and forth. Here's what I think folks are asking for -- and certainly what I would prefer at this point:

    User - cross-project configuration (typically tools)
        Locations used in this order:
            If $CLJ_CONFIG is set, then use $CLJ_CONFIG (explicit override) -- no change
            If $XDG_CONFIG_HOME is set, then use $XDG_CONFIG_HOME/clojure -- no change
            If $HOME/.config/clojure exists, then use it (Freedesktop conventions) -- **new**
            Else use $HOME/.clojure (most common) -- no change

That 3rd condition could also be:

            If $HOME/.clojure does not exist but $HOME/.config/clojure exists, then use the latter (Freedesktop conventions)

If neither directory exists and no relevant env vars are set, use $HOME/.clojure as now.

If $HOME/.clojure exists and no relevant env vars are set, use $HOME/.clojure as now.

If $HOME/.clojure does not exist but $HOME/.config/clojure does (and no relevant env vars are set), use $HOME/.config/clojure (XDG style -- this is the requested change).

Hopefully that makes things clearer? (and hopefully the XDG advocates in this thread can confirm that's right/acceptable)

And to clarify the problem for XDG users right now:

If they move $HOME/.clojure to $HOME/.config/clojure but do not set the (optional) XDG_CONFIG_HOME env var, the CLI creates $HOME/.clojure afresh and ignores the XDG convention folder.
by
As I said above "If $HOME/.config/clojure exists" does not seem to tell you that it is an XDG system and still requires you to actively do a thing on your system, so does not seem to answer the original ask. So, this does not seem like a good answer. You say that moving your .clojure directory is the problem XDG users have, but I don't agree and that seems at odds with the original question, which was "XDG_CONFIG_HOME does not need to be set explicitly, and tools follow XDG spec should just write to $HOME/.config/clojure". So, looking for some better answer than this.
by
The concern of forcing users into XDG is very clear.

Every system seems to have different flavors of XDG_ variables set by default (Nix on Darwin is setting XDG_CONFIG_DIRS and XDG_DATA_DIRS).

If we're willing to rely more on the XDG naming and conventions, we could improve our coverage of the unambiguous use cases.

More concretely:

            If $CLJ_CONFIG is set, then use $CLJ_CONFIG (explicit override)
            If any $XDG_* is set, then follow XDG conventions ($XDG_CONFIG_HOME/clojure or ~/.config/clojure when unset) -- **change**
            Else use $HOME/.clojure (most common)

N.B.: XDG_* may also stand for only the 7 existing documented variables
by
The more I think and read about this specification (xdg base dirs), the more I think it is more an option of the application to choose whether to follow the specs or not, and the system has no responsibility in this regard.

So the idea of adding a flag could be the way to go.  This give the users the option to install the clojure cli wiht full support or not of XDG, and also to the package managers (think about debian Clojure package maintainer). Similar to the `--prefix` flag.

Here is the idea in a commit: easier to explain in code: https://github.com/jgomo3/brew-install/commit/bfae7f15291826c0a27e2a76d42a5275493c7da2

One important thing is that the idea is not to change the current behavior.

Note: the code is not tested, and it is not a Pull Request.  It is just to support this comment.
by
Choosing at install time is a good idea. If you're interested in working on a patch for it, would be happy to have you do so.
by
by
edited by
Yes, thank you.  I would be glad to work on the patch.

I'll follow these instructions: https://clojure.org/dev/dev
Maintained by Cognitect on behalf of the Clojure community
...