Support $XDG_CONFIG_HOME on macOS

[tmshn]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

Follow configurations under $XDG_CONFIG_HOME on macOS too!

Current situation

Although macOS is a genuine UNIX OS and the document says

For Unix, we follow the XDG spec

you don't, on macOS.

https://github.com/sdispater/poetry/blob/ce124603e57ac8ede4addc6f96fc810a82090259/poetry/utils/appdirs.py#L128-L132

Rationale to support it

I'm using $XDG_CONFIG_HOME to manage configurations.

$ ls $XDG_CONFIG_HOME
alacritty/  configstore/  git/  iterm/      micro/  tmux/
anyenv/     fish/         hub   karabiner/  ssh/

As you see, many tools like git, fish, anyenv and karabiner-elements supports XDG by nature (some are not by nature, but can be configured).

I believe this is good strategy since it's more suitable to version-control in my "dotfiles" repository GitHub.

I know this will be breaking change, but at least, I want some way to configure it (such as env variable like PYPOETRY_FOLLOW_XDG).

[yudai-nkt]

Second this as a macOS user organizing my dotfiles in a XDG-compliant manner.

Regarding the compatibility, could something like this be an option?

diff --git a/poetry/utils/appdirs.py b/poetry/utils/appdirs.py
index 522dcf3..63572e5 100644
--- a/poetry/utils/appdirs.py
+++ b/poetry/utils/appdirs.py
@@ -47,7 +47,7 @@ def user_cache_dir(appname):
 
         # Add our app name and Cache directory to it
         path = os.path.join(path, appname, "Cache")
-    elif sys.platform == "darwin":
+    elif sys.platform == "darwin" and "XDG_CACHE_HOME" not in os.environ:
         # Get the base path
         path = expanduser("~/Library/Caches")
 
@@ -93,7 +93,7 @@ def user_data_dir(appname, roaming=False):
     if WINDOWS:
         const = roaming and "CSIDL_APPDATA" or "CSIDL_LOCAL_APPDATA"
         path = os.path.join(os.path.normpath(_get_win_folder(const)), appname)
-    elif sys.platform == "darwin":
+    elif sys.platform == "darwin" and "XDG_DATA_HOME" not in os.environ:
         path = os.path.join(expanduser("~/Library/Application Support/"), appname)
     else:
         path = os.path.join(
@@ -125,7 +125,7 @@ def user_config_dir(appname, roaming=True):
     """
     if WINDOWS:
         path = user_data_dir(appname, roaming=roaming)
-    elif sys.platform == "darwin":
+    elif sys.platform == "darwin" and "XDG_CONFIG_HOME" not in os.environ:
         path = user_data_dir(appname)
     else:
         path = os.getenv("XDG_CONFIG_HOME", expanduser("~/.config"))
@@ -155,7 +155,7 @@ def site_config_dirs(appname):
     if WINDOWS:
         path = os.path.normpath(_get_win_folder("CSIDL_COMMON_APPDATA"))
         pathlist = [os.path.join(path, appname)]
-    elif sys.platform == "darwin":
+    elif sys.platform == "darwin" and "XDG_CONFIG_DIRS" not in os.environ:
         pathlist = [os.path.join("/Library/Application Support", appname)]
     else:
         # try looking in $XDG_CONFIG_DIRS

Although this indeed brings a breaking change, it has no effect on macOS users who do not set XDG-related environment variables. macOS users who deliberately set those variables (like me) will be affected, but I suppose they should be happy with this change.

I've prepared yudai-nkt/poetry@513c990, so I can send a PR if this is more or less the right direction.

[rpdelaney]

I don't think this needs to be a breaking change. Simply follow the freedesktop spec by default but fall back to the old behavior if files are not found there.

There's also this bit:

The installer installs the poetry tool to Poetry's bin directory. On Unix it is located at $HOME/.poetry/bin and on Windows at %USERPROFILE%.poetry\bin.

This should be installed to $XDG_DATA_HOME. On my system this would be /home/ryan/.local/share.

[Townk]

I created a PR to solve this issue, but since I don't know it is considered a new feature or a bug fix, I create it against the develop branch. If this can be a bug fix for 1.0, I can submit another PR:

#1507 #1823

[0alpha]

Is there any chance of this making it into 1.0.4, or whatever the next version is? It's one of the assorted UX papercuts that still remain.

Also, thanks for making the PR.

[wangkev]

Have there been any developments here? Would be interested in this as well.

[dimbleby]

poetry now outsources this to platformdirs, platformdirs/platformdirs#4 is similar at their end (but the discussion looks as though maintainers aren't too keen).

[Secrus]

This issue belongs upstream in platformdirs as noted by @dimbleby. If this is changed in platformdirs, don't hesitate to make an issue (or even better, a PR) if Poetry would need to change something in how it's using that dependency. Closing for now.

[justuswilhelm]

The issue, upstream, was closed. So now we are left with no way to set it. My use case is the following:

I work on several UNIX-like OSes. Every single other tool I use (say, npm and many more), uses ~/.cache as part of the XDG base directory spec. I would like to change this for poetry. There is a setting in poetry.toml for this. I would like to check this in my dotfiles repo. I symlink all my configuration folders from ~/.dotfiles to ~/.config. Because upstream (platformdirs) decided that, for inscrutable reasons, they can't, I can't do this for poetry, except when I am on my Debian machine. There was also some quip in the above linked issue about macOS not being UNIX enough?

I left Pipenv because it has many disagreeable defaults and doesn't work well for supporting large projects running on many different environments. You are doing the right thing by not re-inventing the wheel, but if a macOS user has XDG_CONFIG_HOME as an env var set, it's just a case of doing the right thing here and respecting user wishes.

Please consider if there isn't some other solution to this.

Seems with borg they had a similar issue when using platformdirs and found a workaround.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.