Add appdirs module to stdlib
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 :)
On 1 September 2015 at 18:00, Philipp A. <flying-sheep@web.de> 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
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 :)
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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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 1 September 2015 at 10:09, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
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.
+1 to all of the above. Paul
On Tue, Sep 1, 2015 at 6:00 PM, Philipp A. <flying-sheep@web.de> 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
On Sep 1, 2015, at 01:00, Philipp A. <flying-sheep@web.de> 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.) 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...
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. <flying-sheep@web.de> 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 <gokoproject@gmail.com> 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 September 1, 2015 at 5:05:14 PM, Paul Moore (p.f.moore@gmail.com) wrote:
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.
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. I’m +1 on it though. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 1 September 2015 at 22:12, Donald Stufft <donald@stufft.io> 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 9/1/2015 5:04 PM, Paul Moore wrote:
On 1 September 2015 at 17:19, John Wong <gokoproject@gmail.com> 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.
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. Games that expect people to edit .ini files put them in the game directory. -- Terry Jan Reedy
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 9/2/2015 1:21 AM, random832@fastmail.us wrote:
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,
I added one, mostly written by Tal Einat, a year ago, but older versions of Idle have not disappeared (and the user config files are global to all versions, for a particular user). And there is not yet an installer for 3rd party extensions.
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. -- Terry Jan Reedy
On Wed, Sep 2, 2015 at 11:34 AM, Terry Reedy <tjreedy@udel.edu> 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 02.09.2015 20:54, Chris Kaynor 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
On Wed, Sep 2, 2015 at 11:34 AM, Terry Reedy <tjreedy@udel.edu> wrote: 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. Same as Win 7. Chris _______________________________________________ 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 2015-09-02 19:54, Chris Kaynor wrote:
On Wed, Sep 2, 2015 at 11:34 AM, Terry Reedy <tjreedy@udel.edu> 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 9/2/2015 2:54 PM, Chris Kaynor wrote:
On Wed, Sep 2, 2015 at 11:34 AM, Terry Reedy <tjreedy@udel.edu> wrote:
I do not know of any way to enable showing hidden files with Explorer. (If you know of one, tell me.)
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.
Thank you. I am still using Win 7. They show up on Alt-release. -- Terry Jan Reedy
On Wed, Sep 2, 2015, at 14:34, Terry Reedy wrote:
Quit the contrary. Files beginning with a '.' are not hidden on Windows Explorer
I was talking about dot files *on Unix* vs AppData on Windows. Being hidden from the normal view is clearly desired, or people wouldn't use the dot at all.
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
Terry Reedy writes:
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.
Yes, "ls -a" (or "ls -A", which omits "." and ".."). This applies to Mac OS X as well, and as of Yosemite I can't find any way to show hidden files in the Finder. (But there may be a way: I use Mac OS X because it's pretty and I can use traditional *nix commands in the terminal, not because I'm a Mac GUI wonk.)
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.
On 2 September 2015 at 05:31, Terry Reedy <tjreedy@udel.edu> 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.
As you say, that's an issue with Windows, not with the library (if indeed it *is* an issue with Windows - the users I've dealt with don't have huge problems with things in appdata, although they would usually expect the program to offer a config dialog rather than making them edit the file by hand - but that's off-topic for this thread).
Games that expect people to edit .ini files put them in the game directory.
That's a common choice on Windows, certainly (relating to historical issues where the official standards used to be a lot more user-hostile). It may well-be that the appdirs module should offer an "app-local" (or "portable", if you prefer) scheme in addition to the default scheme. Paul
On Tue, Sep 1, 2015 at 2:42 AM, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
On Sep 1, 2015, at 01:00, Philipp A. <flying-sheep@web.de> 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... -n -- Nathaniel J. Smith -- http://vorpus.org
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
On 01Sep2015 17:25, Yury Selivanov <yselivanov.ml@gmail.com> 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 <cs@zip.com.au> "waste cycles drawing trendy 3D junk" - Mac Eudora v3 config option
On 2 September 2015 at 07:22, Nathaniel Smith <njs@pobox.com> 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.
We'd also want to state up front that non-compliance with the relevant platform standards *is* considered a bug, so it may change in maintenance releases in order to support changes in the platform standards. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 01.09.2015 23:22, Nathaniel Smith 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 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...
A low-level library could provide an API to return "legacy" directories. These could on Freedesktop-compliant systems for example be the fallback directories which are used when the environment-variables are not present. And after bugfixes (see what Nick said), the old, incorrect behaviour could be presented. An application could, after not finding its data in the non-legacy directories, query the legacy directories and start a migration process. regards, jwi
On 01.09.15 11: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 :)
site_data_dir() returns a string. It contains multiple paths separated with path delimiter if multipath=True. I think that a function that returns a list of paths, including user dir, would be more helpful and Pythonic. See also PyXDG (http://www.freedesktop.org/wiki/Software/pyxdg/).
* Philipp A. <flying-sheep@web.de> [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/
-----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-----
To: python-ideas@python.org From: j.wielicki@sotecware.net Date: Sun, 18 Oct 2015 13:32:35 +0200 Subject: Re: [Python-ideas] Add appdirs module to stdlib
[snip]> > 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
[snip]
As someone who had to work with temporary files in the past, this appeals to me. I develop on Windows, and the program was not meant to be used on non-Windows platforms, so I used a lot of platform-dependant hacks I wish I could not use. I am by no means a pro, but I would still like to help with this. Cheers,-Emanuel Barry
participants (21)
-
Andrew Barnert -
Cameron Simpson -
Chris Angelico -
Chris Kaynor -
Donald Stufft -
Emanuel Barry -
Florian Bruhin -
John Wong -
Jonas Wielicki -
Matthias Bussonnier -
MRAB -
Nathaniel Smith -
Nick Coghlan -
Paul Moore -
Philipp A. -
random832＠fastmail.us -
Serhiy Storchaka -
Stephen J. Turnbull -
Sven R. Kunze -
Terry Reedy -
Yury Selivanov