Repository navigation
Consider using appdirs for config聽#8245
Description
Rather than re-implementing all the logic of finding the platform specific location for config files, we should just use https://github.com/ActiveState/appdirs 馃榾
Rather than re-implementing all the logic of finding the platform specific location for config files, we should just use https://github.com/ActiveState/appdirs 馃榾
Activity
bsipocz commentedon Dec 11, 2018
Which raises the question whether it's worth to the addition of another non optional dependency.
Pinging @taldcroft and @mhvk. If they are OK with the idea, I'm too.
astrofrog commentedon Dec 11, 2018
Just our of curiosity, how much code would this save?
Cadair commentedon Dec 11, 2018
Pretty much everything in
confg/paths.py. It would also use more "standard" semantics, and move the responsibility of being standards compliant to other people.it's also worth noting that appdirs is a single file, so can easily be copied into tree. I took a quick swing at this here: Cadair@ae1aa4a
pllim commentedon Dec 11, 2018
20 additions and 145 deletions-- me likey!mhvk commentedon Dec 11, 2018
I like the idea, though obviously it means that everyone's config/cache are going to move from
.astropyto new locations. A bit of a pain, even if the new locations are more logical.Note that it does seem one could make similar gains in size by replacing
_find_homewithpathlib.Path.home(), but that of course doesn't give the benefit of pushing responsibility for ensuring that this remains up to date to others, nor that configuration directories will be more standard.Aside:
appdirs.pyis not very large, at 617 lines.astrofrog commentedon Dec 11, 2018
I'd be in favor (including bundling it in astropy/extern for now)
It would be nice to find a way to warn users who do have config directories about the change.
pllim commentedon Dec 11, 2018
4.0 would be a good time to do this if you want to move the locations.
bsipocz commentedon Dec 11, 2018
I'm on board, given that we bundle it. Also, agree with @pllim that if the config dir changes, it's better do in 4.0.
Cadair commentedon Apr 15, 2019
Is it worth doing this in the 3.2 release? Or shall we just do it in 4.0 and emit a warning as and when we migrate locations?
(not really sure I know what we would do in 3.2, but I just want to check)
pllim commentedon Oct 30, 2019
With #8237 in, is this resolved?
astrofrog commentedon Oct 30, 2019
@pllim - no, #8237 doesn't change anything in terms of where, system-wide, the config/cache directories end up.
pllim commentedon Mar 30, 2020
Note to self: Does not quite solve the problem of disabling config altogether (#5899, #7290).
embray commentedon Sep 16, 2020
I was excited about this idea at first--it would be great to have a "standard" library for this sort of thing. But upon closer inspection, I think the layout used by appdirs is better suited for things like desktop applications, where (non-developer) users are less likely to be poking around directly in their config directories.
In fact, I think this would be a user-hostile change. In particular for MacOS users, and to some extent Windows users as well.
For example, MacOS users are already accustomed to, by default, finding all Astropy-related stuff in
~/.astropywhich is pretty clear, easy to document, and easy to remember. Using appdir would put the astropy config dir in:~/Library/Preferences/astropy. Opaque, confusing. Especially when on Linux it would be in~/.config/astropy--when switching between systems, or SSHing from a Mac to a Linux system this would be jarring. Even worse if mounting a shared home directory.Having
~/.astropy/configbe the default config directory (while maintaining support forXDG_CONFIG_HOMEwhere explicitly set) is the most user-friendly option. However, I think there are some things we can do to better support users, so see #10738astropy-bot commentedon Sep 24, 2020
Hi humans 馃憢 - this issue was labeled as Close? approximately 7 days ago. If you think this issue should not be closed, a maintainer should remove the Close? label - otherwise, I will close this issue in a month.
If you believe I commented on this issue incorrectly, please report this here
astrojuanlu commentedon Dec 28, 2020
The bot forgot to close this issue so... I'll proceed.
pllim commentedon Dec 28, 2020
@astrofrog (a.k.a. "Helen") should look into the cron job for the bot. Maybe it's not working...