Use a subdirectory of $XDG_CONFIG_HOME instead of ~/.matplotlibrc on Linux

[mdboom]

The latest version of the XDG basedir spec seems to recommend this.

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Is this something we want to do? Will it only add to confusion for platforms that don't use this (presumably Mac OS-X)?

[fperez]

FWIW, here's what we've done on this topic:

http://ipython.org/ipython-doc/dev/config/overview.html#configuration-file-location

It is indeed a little more information to provide, since osx is now different than linux, but people felt that following the xdg standard was a good idea.

[jkseppan]

On Mac OS X, this kind of files tend to go in ~/Library/Application Support. I think that directory is strictly meant for applications, not libraries, so e.g. a hypothetical application named Pylab.app might place its files in ~/Library/Application Support/org.scipy.Pylab.

Even more strictly, application configuration should go in ~/Library/Preferences and be managed with the appropriate OS X APIs.

http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/MacOSXDirectories/MacOSXDirectories.html

A lot of common Unix programs do keep their configuration in dotfiles in the home directory, though.

[WeatherGod]

Could we have it so that if that environment variable is set, then use it. Otherwise, stick with the old location for now?

However, there might be some issues if a person already has an rc file in both locations, how do we know which one to use?

[pelson]

Sounds like a good idea. Shall we get on and implement it? Anyone keen to give it a shot?

[eheintzmann]

What is planned now about FreeDesktop.org XDG basedir specification for matplotlib?

http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://standards.freedesktop.org/basedir-spec/latest/
http://launchpadlibrarian.net/17159093/pyroom_xdg.patch

[mdboom]

+1 on doing this. This has obviously just fallen through the cracks. I think we should plan this for the next major release (I've added a milestone).

[eheintzmann]

According to XDG Base directory specification:
User data should go into $XDG_DATA_HOME (which default to ~/.local/share),
user preferences should go into $XDG_CONFIG_HOME (which default to ~/.config)
and cached data should go to $XDG_CACHE_HOME (which default to ~/.cache).
More details at :
http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders

Full specification can be found at:
http://standards.freedesktop.org/basedir-spec/latest/

The Freedesktop.org XDG base directory specification have good de facto adoption.
It has been adopted by:

• GNOME ( https://live.gnome.org/GnomeGoals/XDGConfigFolders )
• GTK+ ( https://bugzilla.gnome.org/show_bug.cgi?id=646631 )
• KDE ( http://techbase.kde.org/KDE_System_Administration/XDG_Filesystem_Hierarchy#Freedesktop.org_and_Standard_Directories )
• QT ( http://harmattan-dev.nokia.com/docs/library/html/qt4/qsettings.html#setPath )
• XFCE ( http://docs.xfce.org/xfce/xfce4-session/advanced in Files and Environment Variables )
• LXDE
• Razor-qt
• VLC ( https://trac.videolan.org/vlc/ticket/1267 )
• GStreamer ( https://bugzilla.gnome.org/show_bug.cgi?id=518597 )
• Chrome ( http://code.google.com/p/chromium/issues/detail?id=16976 )
• many more upstream applications
• Ubuntu ( http://brainstorm.ubuntu.com/idea/6557/ & http://packages.ubuntu.com/fr/source/precise/libxdg-basedir )
• Debian ( http://packages.debian.org/squeeze/libxdg-basedir1 )
• Red Hat
• Fedora
• Suse
• many more distributions

I think that matplotlib should use same locations than the vast majority of Desktop environment and applications.

There are real advantages of following this specification :

• a lot less cluttered $HOME
• Make backups a lot more safer and easier.
  Backuping your $XDG_DATA_HOME along with your files is enough
  (or just excluding $XDG_CACHE_HOME)
• A lot easier to reset a default configuration if you want/need it (and
  without any risk to loose informations). Even for the software itself
  could choose to reset $XDG_CONFIG_HOME if needed.
• Avoid some strange bugs that happens because you had a old version of
  some configuration file
• A lot more of flexibility and portability because no path are hardcoded.

[mdboom]

@eheintzmann, @fperez: Anyone willing to test this, to make sure the migration path works? I'd like to get this in for 1.3. If a ~/.matplotlib/matplotlibrc file already exists on Linux, it will continue to use that, but display a big fat warning. I think this is better than just going on to use the new location and having users scratch their heads as to why their config appears to be "missing". It's just a matter of moving it to the new location (.config/matplotlib) and it should be quiet, though.

@WeatherGod: I deliberately didn't change behavior on OS-X. We could consider ~/Library/Applications etc., but I think that should be a follow-on PR.

[pelson]

@mdboom - the warning was good. But I wonder if we can do this migration automatically? Especially given that the only files in my .matplotlib folder are automatically generated caches anyway.

[mdboom]

Most of the files in ~/.matplotlib are auto-generated caches, but the most important one, matplotlibrc is not.

With this PR, all of the cache files will automatically (and silently) start being created and used in ~/.cache/matplotlib. It is only when the human-written matplotlibrc file exists in the old location that this warning will be generated. I'm not a fan of automatically moving the config file. I, for example, have the config files I care about as symlinks into a git repository so they get version controlled and backed up. If this file were to get moved, it might escape that process, (moving a symlink is probably fine, but we can't assume everyone works the way I do) and I would only get the warning that it was moved the first time (which might be easy to miss).

[pelson]

It is only when the human-written matplotlibrc file exists in the old location that this warning will be generated.

That was not my experience (I didn't look at the code, just ran it...). I'm happy with the approach you discuss though.

[pelson]

This is the bit which causes the warning for people with a cache but not necessarily a matplotlibrc.

[mdboom]

Ah, I see. I'll fix that up.