Repository navigation
switch to using appdirs to find config and data paths #12549
Description
See https://pypi.org/project/appdirs/
This will allow us to drop all of the custom config / data / ... path code we currently own.
This is suggested by @zooba in a talk on how to make sure your project works well on all operating systems.
Activity
WeatherGod commented on Oct 17, 2018
anntzer commented on Oct 18, 2018
For data I'd much prefer we merge #11241 and use standard packaging tools to ship and retrieve our (static) data...
For config and cache dirs, sure... except that we also have $MPLCONFIGDIR and $MATPLOTLIBRC to handle anyways, or deprecate. I think having both of them is a bit overkill as the main use I can think of is to point to a temporary matplotlibrc, so just keeping $MATPLOTLIBRC and only allowing it to point to a file(-like) (as opposed to a directory containing a matplotlibrc file) seems enough.
If we switch to appdirs but keep all the custom code to handle $MPLCONFIGDIR and $MATPLOTLIBRC, I'm not convinced we'd have gained a lot.
zooba commented on Nov 6, 2018
What you gain is better defaults, and defaults that make sense for the platform the user is currently using. That's worth a lot, as is having the overrides (for the reason you mention), so I'd expect you to have both.
anntzer commented on Nov 7, 2018
I guess what appdirs gives you for the cachedir is fine, and I am actually happy that Matplotlib follows XDG on Linux.
However I think it'd be a misfeature to put the matplotlibrc file in ApplicationData on Windows (I think that's what appdirs gives you for user_data_dir?): it's a file that's intended to be edited by the end users, but ApplicationData is a hidden directory (by default, AFAIK), so putting it there doesn't look very user-friendly.
zooba commented on Nov 7, 2018
If it's meant to be user visible, it should go in "Documents" then. Personally I dislike this, but I live inside AppData (unlike most people).
It's just as hard to get to the user profile directory as the AppData directory, and the AppData directory is specifically for these kinds of files. And AppData/Local and AppData/Roaming have different behaviours on some systems, as they are designed specifically for different types of app settings, so using them is actually the feature, rather than a misfeature. (The documents folder will also roam when configured, which gives the user better control over their settings.)
Another helpful thing is to offer a command line option/equivalent to open the file wherever it is located and/or in the user's default text editor (a big advantage of using a ".txt" or ".ini" file for configuration, rather than a "hidden" dotfile).
anntzer commented on Nov 7, 2018
No strong opinion about putting it in Documents (but I don't think it's something in the appdirs model?), I can't say I have a good idea of what the average Windows user expects. But if we move it to AppData you get to field the questions on the issue tracker about how to get there :-)
Well, C:/Users/<user>/.matplotlib is not hidden by default on Windows, so I don't understand what you mean by "as hard"?
Actually I'd rather have matplotlibrc follow $PYTHONPATH (to have it per-venv), but that's a side issue...
If it was matplotlibrc.txt then we could do something like webbrowser.open(matplotlib.matplotlibrc_fname()) (which would open the text editor, despite what the module name says) but in the absence of extension this indeed gets opened by, well, the webbrowser.
I don't particularly care about the extension, to be honest (I guess .conf would be the normal thing).
zooba commented on Nov 7, 2018
By "as hard", I mean that if you know the buttons to click to get as far as C:\Users\<user>, and you know to look there, getting to C:\Users\<user>\AppData isn't a big ask. And the quickest way to get to these is to type %APPDATA% or %LOCALAPPDATA% into the address bar (or %USERPROFILE%, but again, the profile directory is not where settings are supposed to be stored).
I also like configuration files that follow PYTHONPATH (or at least sys.prefix), but yeah, it's not the core issue here :)
For opening the file, there's also os.startfile on Windows, and this is one of the few good uses for subprocess.call(…, shell=True) (which with just a filename should be consistent across OS's - it only gets difficult when trying to pass multiple filenames).
anntzer commented on Nov 7, 2018
I don't have a Windows machine under my hand to check right now (but do use one nearly daily), but IIRC C:\Users\<user> is just opening the explorer, clicking on C:, then on Users, then on <user>, no? Which is definitely simpler than typing anything in the addressbar (OK, actually it's easier for both of us to type something in the addressbar but we're not the constituency here...).
eh?
[ins] In [1]: subprocess.call("foo.txt", shell=True) /bin/sh: foo.txt: command not foundzooba commented on Nov 7, 2018
Okay, guess shell doesn't do what I thought there. But it does on Windows (though startfile is preferable) :)
The point is less about making it easy for users to find (in which case Documents wins, as does C:\ and C:\Users\<user>\Desktop) and more about not storing files in random places against the design of the OS. Windows has designated locations to store app-specific settings files, which are often ignored out of ignorance. Now that ignorance is no longer an excuse (sorry!), you can choose to violate the design deliberately or you can change your default, it's up to you.
anntzer commented on Nov 7, 2018
I don't have anything (modulo code churn, more-than-one-way-to-do-it vs deprecation period, yada yada) against putting it in e.g. Documents/matplotlib/matplotlibrc if that's the Windows expectation.
But I guess that's waiting for ActiveState/appdirs#57 :p (if we do want to pick up a dependency on appdirs...)
github-actions commented on May 20, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
NeilGirdhar commented on May 20, 2023
It would be good to rename this issue to switch to platformdirs, which is the maintained fork of appdirs. Incidentally, it has platformdirs.user_documents_dir, which @anntzer suggested in his last comment.
github-actions commented on Oct 18, 2024
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
NeilGirdhar commented on Oct 18, 2024
Please reopen.