Consider using appdirs for config

[Cadair]

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 😀

@eteq

[bsipocz]

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]

Just our of curiosity, how much code would this save?

[Cadair]

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]

20 additions and 145 deletions -- me likey!

[mhvk]

I like the idea, though obviously it means that everyone's config/cache are going to move from .astropy to 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_home with pathlib.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.py is not very large, at 617 lines.

[astrofrog]

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]

4.0 would be a good time to do this if you want to move the locations.

[bsipocz]

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]

It would be nice to find a way to warn users who do have config directories about the change.

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]

With #8237 in, is this resolved?

[astrofrog]

@pllim - no, #8237 doesn't change anything in terms of where, system-wide, the config/cache directories end up.

[pllim]

Note to self: Does not quite solve the problem of disabling config altogether (#5899, #7290).

[embray]

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 ~/.astropy which 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/config be the default config directory (while maintaining support for XDG_CONFIG_HOME where explicitly set) is the most user-friendly option. However, I think there are some things we can do to better support users, so see #10738

[astropy-bot]

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]

The bot forgot to close this issue so... I'll proceed.

[pllim]

@astrofrog (a.k.a. "Helen") should look into the cron job for the bot. Maybe it's not working...