On Tue, Sep 1, 2015 at 2:42 AM, Andrew Barnert via Python-ideas firstname.lastname@example.org wrote:
On Sep 1, 2015, at 01:00, Philipp A. email@example.com wrote:
When defining a place for config files, cache files, and so on, people usually hack around in a OS-dependent, misinformed, and therefore wrong way.
Thanks to the tempfile API we at least don’t see people hardcoding /tmp/ too much.
There is a beautiful little module that does things right and is easy to use: appdirs
Is appdirs compatible with the OS X recommendations (as required by the App Store). Apple only gives you cache and app data directories; prefs are supposed to use NSDefaults API or emulate the file names and formats properly, and you have to be sensitive to the sandbox.)
No, AFAICT it doesn't get this right -- it just hard-codes the OS X directories. It also didn't quite implement the XDG spec correctly (there's some fallback behavior you're supposed to do if the magic envvars don't make sense that it skips -- very unusual that this will matter). And windows I'm not sure about -- the logic in appdirs looked reasonable to me when I was reviewing this a few months ago, but there seem to be a bunch of semi-contradictory standards and so it's hard to know what's even "correct" in the tricky cases.
All of this is probably as much an argument *for* providing the correct functionality as a standard thing as it is against, but any PEP here probably needs to be thorough about citing the research to show that it's actually getting the various platform standards correct.
What makes it particularly difficult is that if you "fix a bug" in a library like appdirs, so that it starts suddenly returning different results on some computer somewhere, then what it looks like to the end user is that their data/settings/whatever have suddenly evaporated and whatever disk space was being used for caches never gets cleaned up and so forth. Generally when applications change how they compute these directories, they also include tricky migration logic to check both the old and new names, move stuff over if needed, but I'm not sure how a low-level library like this can support that usefully...