Yes absolutely, and there are open issues to provide site_log_dir and site_state_dir as well. One of the things I was definitely keen to discuss was slimming it down. At minimum, all XDG base directories should be provided, with suitable equivalents on Windows and macOS.
But beyond that it’s worth considering whether: a) site directories are needed or if it is better to stick to user directories; b) if a log directory makes sense; c) if user files directories like Desktop, Pictures etc. are worth including. All are convenient for some use cases but I don’t know if they are really needed frequently enough by typical Python scripts/packages/programs to merit going in the stdlib. The more locations are provided, the more likely that something has to change!
My view is that a stdlib version should either be opinionated or not, rather than offering both. The ability to specify roaming and non-roaming is important for Windows; the key is just to make sure the default is sensible so most people never have to think about it.
Yes exactly, this is to provide XDG_DATA_DIRS and XDG_CONFIG_DIRS on request. It’s similar to the “ideal” binary directory vs $PATH. I will also suggest having a different method for those, so that each XDG variable has a method, rather than having multipath as an option which I think leads to confusion.
Perhaps, but the platformdirs maintainers always took the position that there is no need to replicate anything that’s already in the stdlib. Of those, I’d say it maybe makes sense to at least have user_home_dir.
It’s an interesting idea, and would serve well as a reference implementation. I’ll put the idea of a fork to the platformdirs people.
I have thought a fair bit about what would be a good approach and have plenty of opinions, but I expect the current maintainers will have extremely valuable insight into what is sensible to do, and I’ll pitch my ideas to them first, then come here with a concrete proposal.
It’s probably worth noting that there is some disagreement on what the ideal location for CLI tool configuration on non-Linux platforms is, especially on macOS, where very few tools store their files in ~/Library/Application Support - there’s definitely macOS folks out there who are vocal about their preference of XDG and platformdirs does not support XDG on macOS. It probably hasn’t been noticed because platformdirs is scarcely-used to store user-editable configuration, but this has been a point of contention for libraries of other languages before (see e.g. directories-rs) and I’d expect a similar racket if there’s an uptick in platformdirs adoption for CLIs written in Python - worse if it ends up being “standardised”.
Thanks for the heads up, it’s useful to have an idea of likely sticking points.
The Apple guidelines are clear on what should be done; from what I can see the discussion at directories-rs mostly seems to revolve around whether on macOS preference should be given to Apple’s guidelines (use ~/Library/Application Support) or to the XDG spec/Unix norm (use ~/.config).
It was already an open question for me as to whether XDG environment variables should be looked for on macOS or Windows. A simple prefer-xdg flag, or similar, might be an idea. Then both use cases are served.
I would say a decent middle ground would be just pick a couple of the current platformdirs offerings. For the stdlib If ya want more, use platformdirs.
Note that we would need to have an opinion on these long term.
Maybe have a flags param to functions that defaults to a sentinel and in the future the flags can change locations if we need to change without breaking compatibility. Or have an object with that flag, etc.