Paths can be overridden using environment variables on Linux, but not MacOS?

[bede]

Thanks for creating platformdirs. I was surprised to learn that while on Linux, user_data_dir() can be overridden with $XDG_DATA_HOME (unix.py), it cannot be overridden on MacOS (macos.py).

It would be very useful if a single environment variable could be used to override the OS-specific default chosen by platformdirs. My assumption was that this is what platformdirs did until I tested it. Perhaps this could be made clearer to avoid confusion? I'm happy to PR the readme if welcomed.

[gaborbernat]

Duplicate of #4

[bede]

Hi @gaborbernat, evidently this path is well trodden, but did you read the final sentence?

Perhaps this could be made clearer to avoid confusion? I'm happy to PR the readme if welcomed.

I simply asked if clarification of the readme is welcome as a PR. That way fewer people will be surprised by the library not working as they expected. The extent of activity related to #4 shows that a lot of people are confused by this.

Also, the Readme says:

On Linux (and other Unices), according to the XDG Basedir Spec, it should be:

This is somewhat misleading since MacOS is a Unix-based OS, but is not covered by the behaviours this sentence references. This sentence led me to believe the intended behaviour is a bug.

Would you in principle be happy to merge clarification of MacOS/Windows behaviour in the Readme?

[gaborbernat]

Would you in principle be happy to merge clarification of MacOS/Windows behaviour in the Readme?

Definitely 😊 while macOS claims to be POSIX-compliant, in practice at no point their docs encourage or document the use of the XDG_DATA_HOME env var and such would surprise some user if we'd add support.

[bede]

Thank you, I understand the rationale for lack of support having read #4. Perhaps the best place to introduce a clarification is in the section platformdirs to the rescue? Perhaps just a sentence early on, in order to signpost users.

…

On Wed, 6 Mar 2024 at 00:01, Bernát Gábor ***@***.***> wrote: Would you in principle be happy to merge clarification of MacOS/Windows behaviour in the Readme? Definitely 😊 while macOS claims to be POSIX-compliant, in practice at no point their docs encourage or document the use of the XDG_DATA_HOME env var and such would surprise some user if we'd add support. — Reply to this email directly, view it on GitHub <#269 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHWAABIH5KDKTLDGP5ER5DYWZMGTAVCNFSM6AAAAABEH26OQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZHAZTQMJYGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gaborbernat]

Agreed, please put in a PR with that.

[wolfch-elsevier]

Thank you, I understand the rationale for lack of support having read #4. Perhaps the best place to introduce a clarification is in the section platformdirs to the rescue? Perhaps just a sentence early on, in order to signpost users.
…
On Wed, 6 Mar 2024 at 00:01, Bernát Gábor @.***> wrote: Would you in principle be happy to merge clarification of MacOS/Windows behaviour in the Readme? Definitely 😊 while macOS claims to be POSIX-compliant, in practice at no point their docs encourage or document the use of the XDG_DATA_HOME env var and such would surprise some user if we'd add support.

I am stuck in circular readathon between issue #4 the comments in this issue... and I hate to "beat a dead horse", but are you saying that platformdirs will not support the XDG_* environment variables on MacOS?

Why? Why would you not allow a developer to have the choice? You say, "...such would surprise some user if we'd add support." What kind of user would be surprised? Only a software developer would be using those XDG_* variables, not a non-technical user, so where is the surprise? I was definitely surprised by lack of support!

My use-case is having the reference platform for our code base using VSCode dev-container which is based on Linux, thus follows the XDG conventions. Sometimes we want to do a build outside the dev-container on MacOS so it would be much better to have the directory structure harmonized with Linux via the XDG environment variable overrides. Even the platformdirs says:

"On Linux (and other Unices), according to the XDG Basedir Spec, it should be...

I notice a number of other apps are following the XDG standard on MacOS, so this is not some un-heard of request:

$ ls -l ~/.config/
total 8
drwx------  3 wolf2  1002642239   96 Apr 12 11:31 act
drwxr-xr-x@ 3 wolf2  1002642239   96 Mar  8 06:44 fish
drwxr-x--x  4 wolf2  1002642239  128 Dec 19  2023 gh
-rw-r--r--  1 wolf2  1002642239   41 Mar 14  2023 github_token
drwx------  3 wolf2  1002642239   96 Mar 31 22:55 gtk-2.0
drwxr-xr-x  3 wolf2  1002642239   96 Dec 19  2022 iterm2
drwxr-xr-x  3 wolf2  1002642239   96 Feb 24  2023 jgit
drwxr-xr-x  3 wolf2  1002642239   96 Jun 12 08:33 pip

...and certainly MacOS is a UNIX variant. I think you're making some kind of argument that because MacOS is not precisely POSIX-compliant you must not consider allowing respect for XDG environment variable overrides, therefore only follow the rigid Apple directory guidelines - but then I look at the source code for macos.py and noticed that you're totally accommodating Homebrew and their non-POSIX, non-Apple recommended directory guidelines! i.e. /opt/homebrew and /opt/homebrew/share.

If you want to be consistent with not allowing us to override directory base names with XDG environment variables, then you should remove all support for Homebrew and Homebrew directories and update the README.md to state, "because Homebrew directories don't follow the Apple directory naming standards, we can't support Homebrew, sorry." ...or... you could just add support for overriding base directories via XDG environment variables! (I would happily provide a PR)

[gaborbernat]

I am stuck in circular readathon between issue #4 the comments in this issue... and I hate to "beat a dead horse", but are you saying that platformdirs will not support the XDG_* environment variables on MacOS?

Yes.

Why?

Because macOS has its protocol on application and configuration data that we follow instead. If you show me an Apple doc that says that XDG should work on macOS I will change my mind.

MacOS is a UNIX variant

This is only partially true, when and how it suits Apple, but not in general.

[wolfch-elsevier]

If you show me an Apple doc that says that XDG should work on macOS I will change my mind.

Where in the Apple documentation does it mention those Homebrew directories that you currently support? macOS Library Directory Details

It's up to you, but I think it's more important to serve the needs of the users of your library rather than Apple. I understand that if a developer uses your library in an application that will potentially be made a available on the App Store, that you want to precisely follow their guidelines (even if Homebrew is not mentioned in macOS Library Directory Details)

What about having a special environment variable like DEVELOPER_MODE=1 or something like that to enable the functionality of respecting XDG?

[wolfch-elsevier]

...well, the reason I chimed in on this issue was so the tools from https://github.com/astral-sh would respect the XDG Spec which is a widely used standard on UNIX-like operating systems, one of which is MacOS. Fortunately, they implemented a workaround by switching to the etcetera package, but thanks anyway.

See also: https://astral.sh/blog/ruff-v0.5.0#xdg-specification-now-used-on-macos