This sounds like a reasonable idea to me, and we can point folks to the original appdirs if they need a version-independent alternative.

Depending on the amount of code involved, we could potentially consider providing this as an API *in* pathlib, rather than needing an entire new module for the standard library version of it.

Regards, Nick.

+1, If this get into python, it would be nice to have a `python -m <module> <appname>` that return to user the config dirs. One of the most challenging issues we have with user is “where is my config/cache/...” and it’s always hard start the response by “It depends of...”. The “run this command to know” works better. -- M

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Sep 1, 2015 at 6:00 PM, Philipp A. 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.

There is a beautiful little module that does things right and is easy to use: appdirs

TI think this is a *really* good candidate for the stdlib...

Who maintains appdirs? Is s/he willing to maintain it on the stdlib's release schedule? If so, I'd be +1 on this; Python has a strong precedent for papering over OS differences and providing a consistent platform. ChrisA

But is appdirs only useful if you are running something that's more toward system package / desktop application? A lot of projects today create their own directory to save data, many use $HOME/DOTCUSTOM_DIR. So the use case of appdirs should be addressed. On Tue, Sep 1, 2015 at 5:42 AM, Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

On Sep 1, 2015, at 01:00, Philipp A. 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 https://pypi.python.org/pypi/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.)

If so, definitely +1, because that's a pain to do with anything but Qt (or of course PyObjC). If not, -0.5, because making it easier to do it wrong is probably not beneficial, even if that's what many *nix apps end up writing a lot of code to get wrong on Mac...

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 1 September 2015 at 17:19, John Wong wrote:

But is appdirs only useful if you are running something that's more toward system package / desktop application? A lot of projects today create their own directory to save data, many use $HOME/DOTCUSTOM_DIR. So the use case of appdirs should be addressed.

But that is not appropriate on Windows. Appdirs gives the above on Unix, but %APPDATA%\Appname on Windows, which conforms properly to platform standards. Paul

On 1 September 2015 at 22:12, Donald Stufft wrote:

I forget why, but we forked appdirs when we added it to pip because of something about how it treated Windows think. Appdirs also is opinionated in situations that there isn’t a platform standard so we’d want to make sure that we agree with those opinions on all platforms.

Certainly. I think the key point here is "let's have something in the stdlib that makes deciding where your app stores its files work correctly by default". Paul

On 2015-09-01 5:22 PM, Nathaniel Smith wrote: [..]

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...

+1 on all points. We really need a PEP for this kind of functionality in the standard library. Yury

* Philipp A. [2015-09-01 08:00:21 +0000]:

There is a beautiful little module that does things right and is easy to use: appdirs https://pypi.python.org/pypi/appdirs

TI think this is a *really* good candidate for the stdlib since this functionality is useful for everything that needs a cache or config (so not only GUI and CLI applications, but also scripts that download and cache stuff from the internet for faster re-running)

+1 from me as well. Another source for inspirations might be the QStandardPaths class from the Qt library (which is C++, but I'm using QStandardPaths in my PyQt applicaiton): http://doc.qt.io/qt-5/qstandardpaths.html They have a QStandardPath::writableLocation which gives you exactly one path to write to, a QStandardPath::standardLocations which gives you a list of paths, and a QStandardPath::locate which locates your config based on a name. They also had the issue with changing standards such as Local/Roaming appdata on Windows, and solved it by introducing more enum values to the StandardLocation enum: QStandardPaths::DataLocation Returns the same value as AppLocalDataLocation. This enumeration value is deprecated. Using AppDataLocation is preferable since on Windows, the roaming path is recommended. QStandardPaths::AppDataLocation Returns a directory location where persistent application data can be stored. This is an application-specific directory. To obtain a path to store data to be shared with other applications, use QStandardPaths::GenericDataLocation. The returned path is never empty. On the Windows operating system, this returns the roaming path. This enum value was added in Qt 5.4. QStandardPaths::AppLocalDataLocation Returns the local settings path on the Windows operating system. On all other platforms, it returns the same value as AppDataLocation. This enum value was added in Qt 5.4. Florian -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/

On Wed, Sep 2, 2015, at 00:31, Terry Reedy wrote:

The problem with Windows is that the standard is to put things in an invisible directory, which makes it difficult to tell people, especially non-experts, to edit a file in the directory.

I'm not sure you _should_ be telling non-experts to find a file to edit. Why doesn't your app provide a UI for it, or at least a button that pops up the file in the text editor (Minecraft, for example, has a button to pop up the folder you're expected to drop downloaded texture packs into), if editing it as free form text is something that end users _really_ should be expected to do? Plus, it's not really any harder to find than a "Hidden" directory beginning with a dot - in either case you have to either type the name or enable showing hidden files, and neither platform makes this easier than the other.

On 01Sep2015 17:25, Yury Selivanov wrote:

...

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 [...] 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...

If it were me I'd want to keep a little state recording what choices were made for these things and whether those were the defaults. Then you can check that on next run: if the choice was a default and the default no longer matches, migrate. Of course, if the default location for this state changes... Not pretending I'm offering a comprehensive solution, I remain, Cameron Simpson "waste cycles drawing trendy 3D junk" - Mac Eudora v3 config option

On Wed, Sep 2, 2015 at 11:34 AM, Terry Reedy wrote:

...

Plus, it's not really any harder to find than a "Hidden" directory beginning with a dot

Quit the contrary. Files beginning with a '.' are not hidden on Windows Explorer (or Command Prompt dir, for that matter). I do not know of any way to enable showing hidden files with Explorer. (If you know of one, tell me.) The secret to getting to one is to click the directory sequence bar to the right of the last entry to get a directory path string, click again to unselect it, then add the name. In this particular case, enter 'AppData/Roaming' or '%APPDATA%'. It is intentionally difficult for user to access these files.

There is an option in the GUI for it: On Windows 7, from an explorer window: Tools->Folder Options->View Tab then in the Advanced Settings list: "Show hidden files, folders, and drives". On Windows 7, the menus are hidden by default, and you need to hold Alt for them to show up. I think Vista uses the same options, and the menus are shown by default, while XP uses a slightly different layout, but its in roughly the same location. I do not know where it is on Windows 8 or 10, as I have never really used either of those. Chris

On 2015-09-02 19:54, Chris Kaynor wrote:

On Wed, Sep 2, 2015 at 11:34 AM, Terry Reedy wrote:

...

...

Plus, it's not really any harder to find than a "Hidden" directory beginning with a dot

Quit the contrary. Files beginning with a '.' are not hidden on Windows Explorer (or Command Prompt dir, for that matter). I do not know of any way to enable showing hidden files with Explorer. (If you know of one, tell me.) The secret to getting to one is to click the directory sequence bar to the right of the last entry to get a directory path string, click again to unselect it, then add the name. In this particular case, enter 'AppData/Roaming' or '%APPDATA%'. It is intentionally difficult for user to access these files.

There is an option in the GUI for it: On Windows 7, from an explorer window: Tools->Folder Options->View Tab then in the Advanced Settings list: "Show hidden files, folders, and drives". On Windows 7, the menus are hidden by default, and you need to hold Alt for them to show up. I think Vista uses the same options, and the menus are shown by default, while XP uses a slightly different layout, but its in roughly the same location.

I do not know where it is on Windows 8 or 10, as I have never really used either of those.

On Windows 10 it's on the File menu: File->Change folder options and search options

On Wed, Sep 2, 2015, at 14:34, Terry Reedy wrote:

I do not know of any way to enable showing hidden files with Explorer. (If you know of one, tell me.)

Didn't notice this on my first reply. Go into the Folder Options window, go to the "View" tab, and you will see an option labeled "Show hidden files, folders, and drives". This option is specific to a folder, there is a button to apply it to all folders. The Folder Options dialog box is available from the "Tools" menu in the classic UI (until Windows XP or maybe Vista), and [still hidden there, but more visible in] the "Organize" dropdown as "Folder and search options". My point stands that putting a dot in front of a filename shows _intent_ to have it hidden from ordinary users, since it has that effect on Unix, and makes it no easier to find it on Unix than finding the AppData folder is on Windows.

On 9/2/2015 5:40 PM, random832@fastmail.us wrote:

On Wed, Sep 2, 2015, at 14:34, Terry Reedy wrote:

...

I do not know of any way to enable showing hidden files with Explorer. (If you know of one, tell me.)

Didn't notice this on my first reply. Go into the Folder Options window, go to the "View" tab, and you will see an option labeled "Show hidden files, folders, and drives". This option is specific to a folder, there is a button to apply it to all folders.

The Folder Options dialog box is available from the "Tools" menu in the classic UI (until Windows XP or maybe Vista), and [still hidden there, but more visible in] the "Organize" dropdown as "Folder and search options".

Thanks. The latter might be the easiest.

My point stands that putting a dot in front of a filename shows _intent_ to have it hidden from ordinary users, since it has that effect on Unix, and makes it no easier to find it on Unix than finding the AppData folder is on Windows.

What I remember from 26 years ago is 'ls -a'. Still correct in a console? (No idea how to do the same on GUIs.) This was part of any Unix intro as one was expected to edit the shell configs to one's taste. -- Terry Jan Reedy

On Wed, Sep 2, 2015, at 18:38, Terry Reedy wrote:

What I remember from 26 years ago is 'ls -a'. Still correct in a console? (No idea how to do the same on GUIs.) This was part of any Unix intro as one was expected to edit the shell configs to one's taste.

What is and should be expected of a non-technical user on a modern desktop Unix system is very different from what it was 26 years ago. This is so obvious it should go without saying. And, anyway, Windows has got dir /a too. People who learned DOS 26 years ago probably likewise know it. Anyway, in summary: you have to either use a special option (not *hard* to discover, but not in your face either) to enable hidden files (ls -a, if they use the terminal *at all*, or whatever checkbox performs the same function in gnome/kde/xfce/whatever), or type the exact filename knowing it exists. Neither is much of a burden, but neither is any "better" than on Windows.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01.09.2015 10:00, Philipp A. 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 https://pypi.python.org/pypi/appdirs

TI think this is a *really* good candidate for the stdlib since this functionality is useful for everything that needs a cache or config (so not only GUI and CLI applications, but also scripts that download and cache stuff from the internet for faster re-running)

probably we should build the API around pathlib, since i found myself not touching os.path with a barge pole since pathlib exists.

i’ll write a PEP about this soon :)

Is anyone working on this? I would really like to see the functionality discussed in this thread. I have no deep knowledge about Windows, MacOS or FreeBSD though, which would make it hard for me to take this on my own. If we could get together a team with knowledgeable people from each platform, that would be great. best regards, jwi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWI4NSAAoJEMBiAyWXYliKfdwP/Rgi2w2ZyZA2tfFcjZMxh6ox niJYz3Uq2Jcci7VJlvPIObu9ioS1pdc/KdLIqMCO9BZzkm0+V/d9/6TLecBtE73s MDFBkVbBooK/km2xx1HCnfj3vT+Eh8+blPDwNABRKzVdGnuGLfZdQHGvw16NDYPI zKcBboS8Xp1F7Njwdm3ozlW34A5ApLMZV0D2WrtrhZk3PBTbjNVBmKqVdNrBzsyO F04F/8kPLoANBj4tBuI9O1KjnMbfwCN7snbu6LlDwhT8pAGW6kpTzOjxRZZdbjD6 NH6NyLbTjIWgVP8JgQ766vGXAwiatrd0ECQWoYHXgAhuP//KVgfmTBpIqoPPME7Y eGmM8XclzI4FS5ud87bgf9Zgr4xZcycX5J/lcXIp/ZPAajHfyWxVbJPHZDocNw7V ZDlEEfIfkbU4aT5faQutPF95eZgwXOxloOSNZI+u7a8Ke8iaTjeoawtksBlVzYbb 6MOLP6xdVXc+vg/9FFwbiDrLuOQiGv2YYENY2Lj3lMw6jvj6GL31XDKhVcyQQeJn yE1ylKwrBQzq2hw57vLwCJD9Tdn0qgOjA74pgl7SHPvkFjNpPXre5YkMTUxI13jI MGof+oR32WHLaA+Kt0dByzNSJPSdzubc4/zKKAT49G96znXua2MlM1nDdrRmhbHo uihjjtEQzIZ1O/uNMV2n =UtH/ -----END PGP SIGNATURE-----