Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow macOS users to use XDG_CONFIG_HOME #78

Open
jcrben opened this issue Nov 14, 2016 · 8 comments
Open

Allow macOS users to use XDG_CONFIG_HOME #78

jcrben opened this issue Nov 14, 2016 · 8 comments

Comments

@jcrben
Copy link

jcrben commented Nov 14, 2016

The code here doesn't check for XDG_CONFIG_HOME if running macOS.

So I know that XDG is technically not a thing on macOS. But it is not uncommon for people to set up a similar system, using application-specific environment variables and at some level the XDG variables to accomplish the same thing.

For example, Git saves to the XDG_CONFIG_HOME if it is set on my Macbook.

It would be rather helpful for us if you did the same. It makes it easier for me to switch from macOS to Linux, which I want to be able to do easily.

@arusahni
Copy link

Click does something similar for POSIX systems, although it doesn't try to infer the XDG_CONFIG_HOME directory. Instead it just returns a top-level ~/.appname dir for all platforms.

@rendaw
Copy link

rendaw commented Jan 25, 2017

Could you set appdirs.system to linux2 maybe? https://github.com/ActiveState/appdirs/blob/master/appdirs.py#L39

@arusahni
Copy link

That looks like it'd apply that rule even when on Windows.

@xmo-odoo
Copy link

@arusahni I expect @rendaw means doing so when it's configured as darwin if you want/need to e.g.

import appdirs
if appdirs.system == 'darwin':
    appdirs.system = 'linux2'

if you want your application to follow XDG rules even on OSX.

@DanCardin
Copy link

I honestly, it seems like it would be ideal if appdirs listened to XDG_*_HOME for all operating systems.

Even if XDG isn't specified for macos, for almost all tools I can set (expecting it to work) XDG_CONFIG_HOME, and therefore I can commit that dir to my dotfiles. Now, any library which uses appdirs forces me to go back to using symlinks and yields a worse experience.

In my mind, even if it doesn't make the most sense for someone to set it on windows, it at least gives everyone an opportunity to customize the config location, as opposed to unconditionally having it set to a specific location (but only on certain operating systems). And ultimately in the default case where it's not being set, you get the same existing behavior.

@0az
Copy link

0az commented Mar 20, 2020

I guess I can take a stab at a PR re-enabling XDG_CONFIG_HOME on Darwin next week.

E: #137 exists.

@DanCardin
Copy link

DanCardin commented Mar 23, 2020

#137 seems like it'd be a jarring breaking change, on new installations it'd always prefer ~/.config, hardcoded.

I'm imagining

def user_config_dir(appname=None, appauthor=None, version=None, roaming=False):
    path = os.getenv('XDG_CONFIG_HOME')
    if not path:
        if system == "win32":
            path = user_data_dir(appname, appauthor, None, roaming)
        elif system == 'darwin':
            path = os.path.expanduser('~/Library/Preferences/')
        else:
            path = os.path.expanduser("~/.config")

    # win32's user_data_dir already appends appname
    if appname and system != "win32":
        path = os.path.join(path, appname)

    if appname and version:
        path = os.path.join(path, version)
    return path

Given my understanding of the reasoning for the way it is right now (XDG is only a thing for linux), then this seems ideal to me:

  • for people for whom that assumption is correct, they wont have XDG_CONFIG_HOME set and they'll see no change in behavior
    ** "Free" extra functionality for windows, where it's even less likely someone opts into thus, but hey i see no reason to artificially cripple windows.
  • for people like me, I'll see the behavior i want

Probably ideally this pattern is applied to all the xdg variables, but truly config is the only one that I'd actually like to commit to a repo, and therefore the only one there's a significant incentive to fix.

Happy to submit an actual PR if there's an indication it'd get merged.

@0az
Copy link

0az commented Mar 24, 2020

Happy to submit an actual PR if there's an indication it'd get merged.
Unfortunately, we might have to wait for maintenance status to get sorted out in #79.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants