[request] reconsider using xdg paths

[donjan]

ipython/ipython#48
ipython/ipython#4457
ipython/ipython#6070
#211

Sorry to beat this apparently dead horse, but I was testing out Jupyter and just realised that the config directory was wrong. And then with growing disbelief discovered that this was once reverted and even held onto.

The "often used in documentation" issue is cleanly solved by calling it [config dir] and linking to a page containing the paths listed by OS. This is standard procedure, don't tell me nobody with documentation commit access wants to take the time to create a single additional page and run find doc/ -name "*.html" | xargs sed -i 's/\.jupyter/\<a href...\>\[config dir\]\<\/a\>/'" (obviously run the adequate link syntax on the source of however you build your doc, possible mistakes should be trivially checkable with grep).

And unless the config directory on Windows is ~/.jupyter as well (haven't checked, but assume/hope it's not), this weird "config goes here" idea could be strictly improved by hard-coding it to Desktop/jupyter-config (or Desktop\jupyter-config, if you will) to be consistent across platforms. Then you don't have to ask users about their platform (or point them to the doc page) AND don't have to tell them to navigate a terminal / unhide files (which is platform specific).

On a more serious note, going by the disussion so far there really seem to be no valid reasons to hold onto ~/.jupyter (jupyter --paths tells me config/data/runtime are separated nowadays), whereas OSX and Linux users would be thankful for the proper locations, as would those who have to deploy Jupyter in computer rooms... so here's another plea to reconsider a little bit before wontfixing this ;)

[takluyver]

Sorry to beat this apparently dead horse,

Yup, it's a dead horse. We've been through this issue plenty of times already.

The "often used in documentation" issue is cleanly solved by calling it [config dir] and linking to a page containing the paths listed by OS.

Making every piece of documentation less clear. Also, it's not just documentation, but our replies to questions on Github, mailing lists, real time chat, and so on. Writing "edit your config in ~/.jupyter" is massively more convenient both for the people who have to write that and the people who read it and follow it.

If you want to make it comply with XDG specs on your own systems, you can set JUPYTER_CONFIG_DIR=$XDG_CONFIG_HOME/jupyter.

And unless the config directory on Windows is ~/.jupyter as well...

It is. We know that's not the Windows convention.

Sorry to rebuff this, but I don't see any argument we haven't considered before.

[rgbkrk]

I'm glad you raised this up so we don't have to support xdg in nteract anymore. 🙇‍♂️

[donjan]

Glad to be of service.

Since we're commenting on closed issues, I still struggle with the reasoning here:

Making every piece of documentation less clear.

Your users, like me, are supposed to be able to program something, which makes us (slightly) less confusable than sheep. We're readily expecting things like:

• https://www.chromium.org/user-experience/user-data-directory
• http://www.paraview.org/Wiki/ParaView_Settings_Files
• https://wiki.documentfoundation.org/UserProfile
• http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Customize-Files.html
• ... many others, these are just some programs I have used today

For your target audience, the introduced "unclarity" is non-existent.

[...] but our replies to questions on Github, mailing lists, real time chat [...]

This is a narrowly constructed argument. If your observation is a non-zero gain in streamlining of the help process, I'll take your word for it. But I did support for several cross platform software packages and the "massively more convenient" in the given context is hardly believable.
Not meaning to offend: this sounds lazy.
And then that would be a really strong point in favour of the Desktop/jupyter-config suggestion (hope I got a chuckle with that, if nothing else).

Cheers!

[takluyver]

Not meaning to offend: this sounds lazy.

We made the change before and decided to go back to how it was before, so it can't really be laziness. It boils down to two competing arguments:

1. Following standard filesystem conventions is a good thing.
2. Having a consistent location across platforms is a good thing.

You (and a steady trickle of other people) clearly think that 1 is more important. The team maintaining it think that 2 is more important. Everyone involved understands both arguments, so discussions about it tend to end up with both sides reiterating their preference.

(There's also 3. changing stuff adds confusion, which weighs in favour of leaving things as they are)

[gnumoksha]

This is not the first project I see that is reluctant in order to add support to XDG Base Directory but fortunately is part of the few that remains.

Despite it, I'm thinking about this:

Only XDG_RUNTIME_DIR is set by default through pam_systemd. It is up to the user to explicitly define the other variables, using absolute paths that point to existing directories.
And I think it is safe to assume that if $XDG_CONFIG_HOME is defined then the user wants to use XDG Base Directory.

BTW, this is how one can use XDG Base Directory with iPython/Jupyter at the moment:

export IPYTHONDIR="$XDG_CONFIG_HOME/ipython"
export JUPYTER_CONFIG_DIR="$XDG_CONFIG_HOME/jupyter"

[MestreLion]

This is not the first project I see that is reluctant in order to add support to XDG Base Directory but fortunately is part of the few that remains.

I agree this reversal was a very, very unfortunate decision.

BTW, this is how one can use XDG Base Directory with iPython/Jupyter at the moment:

I strongly recommend a variation, to be safe if XDG_CONFIG_HOME is not set (it isn't in most distros):

export IPYTHONDIR=${XDG_CONFIG_HOME:-$HOME/.config}/ipython
export JUPYTER_CONFIG_DIR=${XDG_CONFIG_HOME:-$HOME/.config}/jupyter

[MestreLion]

It boils down to two competing arguments:
1. Following standard filesystem conventions is a good thing.
2. Having a consistent location across platforms is a good thing.

You (and a steady trickle of other people) clearly think that 1 is more important. The team maintaining it think that 2 is more important. Everyone involved understands both arguments, so discussions about it tend to end up with both sides reiterating their preference.

The real argument of "group 1" is not about following a standard just for the sake of it, as your phrasing implies. Its about the benefits of this particular one: uncluttered $HOME, easier to backup (and version-control), separation between settings, permanent data and cache. Those are concrete, tangible benefits, and the real reason people are asking software to follow the standard.

As for 2... what exactly is "consistent location across platforms"? Different platforms have different filesystem hierarchy already! Program data, settings, cache are in completely different locations on Windows, Linux and Mac. Even the user's home folders are in very distinct locations. Users know that and it was never a big deal. Platforms also have different env vars to match such special dirs: Windows have %APP_DATA% and the like, Linux have $XDG_*, what's the problem?

Just because all those platforms happen to share an env var named HOME it does not mean that location is suitable for tossing settings and data.