FAQ
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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150901/fcc9aff6/attachment.html>

Search Discussions

  • Nick Coghlan at Sep 1, 2015 at 8:56 am

    On 1 September 2015 at 18: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

    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 at gmail.com | Brisbane, Australia
  • Matthias Bussonnier at Sep 1, 2015 at 9:09 am

    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 at gmail.com | Brisbane, Australia
    _______________________________________________
    Python-ideas mailing list
    Python-ideas at python.org
    https://mail.python.org/mailman/listinfo/python-ideas
    Code of Conduct: http://python.org/psf/codeofconduct/
  • Paul Moore at Sep 1, 2015 at 9:26 am

    On 1 September 2015 at 10:09, Matthias Bussonnier 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
  • Chris Angelico at Sep 1, 2015 at 9:29 am

    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
  • Andrew Barnert at Sep 1, 2015 at 9:42 am

    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

    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...
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150901/d85e3e59/attachment-0001.html>
  • John Wong at Sep 1, 2015 at 4:19 pm
    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 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 at python.org
    https://mail.python.org/mailman/listinfo/python-ideas
    Code of Conduct: http://python.org/psf/codeofconduct/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150901/f5d5545d/attachment.html>
  • Paul Moore at Sep 1, 2015 at 9:04 pm

    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
  • Donald Stufft at Sep 1, 2015 at 9:12 pm

    On September 1, 2015 at 5:05:14 PM, Paul Moore (p.f.moore at 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
  • Paul Moore at Sep 1, 2015 at 9:15 pm

    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
  • Terry Reedy at Sep 2, 2015 at 4:31 am

    On 9/1/2015 5:04 PM, Paul Moore 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.

    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
  • Random832 at Sep 2, 2015 at 5:21 am

    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.
  • Terry Reedy at Sep 2, 2015 at 6:34 pm

    On 9/2/2015 1:21 AM, random832 at 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
  • Chris Kaynor at Sep 2, 2015 at 6:54 pm

    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
  • Sven R. Kunze at Sep 2, 2015 at 8:01 pm
    On 02.09.2015 20: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.
    Same as Win 7.
    Chris
    _______________________________________________
    Python-ideas mailing list
    Python-ideas at python.org
    https://mail.python.org/mailman/listinfo/python-ideas
    Code of Conduct: http://python.org/psf/codeofconduct/
  • MRAB at Sep 2, 2015 at 8:15 pm

    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
  • Terry Reedy at Sep 2, 2015 at 10:33 pm

    On 9/2/2015 2:54 PM, Chris Kaynor wrote:
    On Wed, Sep 2, 2015 at 11:34 AM, Terry Reedy 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
  • Random832 at Sep 2, 2015 at 9:36 pm

    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.
  • Random832 at Sep 2, 2015 at 9:40 pm

    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.
  • Terry Reedy at Sep 2, 2015 at 10:38 pm

    On 9/2/2015 5:40 PM, random832 at 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
  • Stephen J. Turnbull at Sep 3, 2015 at 1:21 am
    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.)
  • Random832 at Sep 3, 2015 at 1:29 am

    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.
  • Paul Moore at Sep 2, 2015 at 7:52 am

    On 2 September 2015 at 05: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.

    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
  • Nathaniel Smith at Sep 1, 2015 at 9:22 pm

    On Tue, Sep 1, 2015 at 2:42 AM, Andrew Barnert via Python-ideas 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


    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
  • Yury Selivanov at Sep 1, 2015 at 9:25 pm
    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
  • Cameron Simpson at Sep 2, 2015 at 8:27 am

    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 <cs@zip.com.au>


    "waste cycles drawing trendy 3D junk" - Mac Eudora v3 config option
  • Nick Coghlan at Sep 2, 2015 at 4:05 am

    On 2 September 2015 at 07:22, 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.

    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 at gmail.com | Brisbane, Australia
  • Jonas Wielicki at Sep 3, 2015 at 8:43 am

    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
  • Andrew Barnert at Sep 1, 2015 at 9:47 pm
    Responses below, but first, another issue:


    Things like app data and prefs aren't a single directory. XDG has a notion of a search path rather than a single directory; Windows has a notion of separate search domains; OS X makes things as fun as possible by having both. For writing a new file, you're usually fine just writing to the first path in the default domain (as long as it exists or you can create it), but for reading files you're supposed to look in /etc or All Users or whatever if it's not found there. Most cross-platform wrappers I've used in the past didn't deal with this automatically, and a lot of them didn't even make it easy to do manually.

    On Sep 1, 2015, at 14:19, Nathaniel Smith wrote:

    On Sep 1, 2015 02:45, "Andrew Barnert via Python-ideas"
    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

    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.

    The biggest problem with most of the cross-platform libraries I've seen is that they assume there is a prefs directory, and on OS X, that really isn't true. If your app explicitly opens the exact same file that NSDefaults would have opened, you're breaking the rules. (Since the mandatory sandbox went into effect, this usually doesn't get you rejected from the App Store anymore, but before that it did.) And taking a quick look at appdirs, it has a user_config_dir that seems to mean exactly that. So, how can a stdlib library handle that?


    Meanwhile, it looks like appdirs expects you to give it an app name and company name to construct the paths. What happens if you give it names that don't match the ones in your bundle? You're opening files that belong to another app. Which is again violating Apple's rules.


    One more thing: I don't know if it's guaranteed that the right way of doing things on OS X (whether via Cocoa or CoreFoundation) won't spawn a background thread for you. After all, the APIs can talk to the sandbox service and sometimes even the iCloud service. Is that a problem for something in the stdlib?

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

    And that's especially true in the case of Apple's standards, which also include specific rules about how you're supposed to do such a migration, and doing so requires stuff that can't be done from entirely inside the code.
  • Paul Moore at Sep 1, 2015 at 11:05 pm

    On 1 September 2015 at 22:47, Andrew Barnert via Python-ideas wrote:
    Things like app data and prefs aren't a single directory. XDG has a notion of a search path rather than a single directory; Windows has a notion of separate search domains; OS X makes things as fun as possible by having both. For writing a new file, you're usually fine just writing to the first path in the default domain (as long as it exists or you can create it), but for reading files you're supposed to look in /etc or All Users or whatever if it's not found there. Most cross-platform wrappers I've used in the past didn't deal with this automatically, and a lot of them didn't even make it easy to do manually.

    This is a fair point. But it's also worth noting that the current
    state of affairs for many apps is to just bung stuff in ~/whatever.
    While appdirs may not get things totally right, at least it improves
    things. And if it (or something similar) were in the stdlib, it would
    at least provide a level of uniformity.


    So, in my view:


    1. We should have something that provides the functionality of appdirs
    in the stdlib.
    2. It probably needs a PEP to get the corner cases right.
    3. The behaviour of appdirs is a good baseline default - even if it
    isn't 100% compliant with platform standards it'll be better than what
    someone unfamiliar with the platform will invent.
    4. We shouldn't abandon the idea just because a perfect solution is
    unattainable.


    There are complex cases to consider (search paths, for example, and
    even worse how search paths interact with the app writing config data
    rather than just reading it, or migration when a scheme changes). The
    PEP should at least mention these cases, but it's not unreasonable to
    simply declare them out of scope of the module (most applications
    don't need anything this complex).


    Paul
  • Chris Angelico at Sep 2, 2015 at 12:47 am

    On Wed, Sep 2, 2015 at 9:05 AM, Paul Moore wrote:
    So, in my view:

    1. We should have something that provides the functionality of appdirs
    in the stdlib.
    2. It probably needs a PEP to get the corner cases right.
    3. The behaviour of appdirs is a good baseline default - even if it
    isn't 100% compliant with platform standards it'll be better than what
    someone unfamiliar with the platform will invent.
    4. We shouldn't abandon the idea just because a perfect solution is
    unattainable.

    +1

    There are complex cases to consider (search paths, for example, and
    even worse how search paths interact with the app writing config data
    rather than just reading it, or migration when a scheme changes). The
    PEP should at least mention these cases, but it's not unreasonable to
    simply declare them out of scope of the module (most applications
    don't need anything this complex).

    Might be worth starting with something simple: ask for one directory
    (the default or most obvious place), or ask for a full list of
    plausible directories to try. Then a config manager could be built on
    top of that which would handle write location selection, migration,
    etc, and that would be a separate proposal that makes use of the
    appdata module for the cross-platform stuff.


    ChrisA
  • Robert Collins at Sep 2, 2015 at 4:38 am

    On 2 September 2015 at 11:05, Paul Moore wrote:
    On 1 September 2015 at 22:47, Andrew Barnert via Python-ideas
    wrote:
    Things like app data and prefs aren't a single directory. XDG has a notion of a search path rather than a single directory; Windows has a notion of separate search domains; OS X makes things as fun as possible by having both. For writing a new file, you're usually fine just writing to the first path in the default domain (as long as it exists or you can create it), but for reading files you're supposed to look in /etc or All Users or whatever if it's not found there. Most cross-platform wrappers I've used in the past didn't deal with this automatically, and a lot of them didn't even make it easy to do manually.
    This is a fair point. But it's also worth noting that the current
    state of affairs for many apps is to just bung stuff in ~/whatever.
    While appdirs may not get things totally right, at least it improves
    things. And if it (or something similar) were in the stdlib, it would
    at least provide a level of uniformity.

    In about 5 years time. Maybe,


    The adoption curve for something that works on all Pythons is able to
    be much much higher than that for something which is only in the
    stdlib 6 months (or more) from now. Unless we do a rolling backport of
    it.


    And if we're going to do that... why? Why not just provide a
    documentation link to the thing and say 'pip install this' and/or
    'setuptools install_require this'.


    -Rob




    --
    Robert Collins <rbtcollins@hp.com>
    Distinguished Technologist
    HP Converged Cloud
  • Nick Coghlan at Sep 2, 2015 at 5:57 am

    On 2 September 2015 at 14:38, Robert Collins wrote:
    On 2 September 2015 at 11:05, Paul Moore wrote:
    This is a fair point. But it's also worth noting that the current
    state of affairs for many apps is to just bung stuff in ~/whatever.
    While appdirs may not get things totally right, at least it improves
    things. And if it (or something similar) were in the stdlib, it would
    at least provide a level of uniformity.
    In about 5 years time. Maybe,

    The adoption curve for something that works on all Pythons is able to
    be much much higher than that for something which is only in the
    stdlib 6 months (or more) from now. Unless we do a rolling backport of
    it.

    And if we're going to do that... why? Why not just provide a
    documentation link to the thing and say 'pip install this' and/or
    'setuptools install_require this'.

    My perspective on that has been shifting in recent years, to the point
    where I view this kind of standard library modules primarily as a tool
    to helps folks learn how the computing ecosystem works in practice.
    Consider PEP 3144, for example, and the differences between ipaddress,
    and its inspiration, ipaddr. The standard library one is significantly
    stricter about correctly using networking terminology, so you can
    actually study the ipaddress module as a way of learning how IP
    addressing works. The original ipaddr, by contrast, is only easy to
    use if you already know all the terms, and can say "Oh, OK, they're
    using that term somewhat loosely, but I can see what they mean".


    I think this is a case where a similar approach would make sense -
    like ipaddr before it, appdirs represents an actual cross-version
    production module, put together by a company (in this case ActiveState
    rather than Google) for their own use, but made available to the wider
    community Python through PyPI. As such, we know it's feature coverage
    is likely to be good, but the API design is likely to be optimised for
    experienced developers that already understand the concepts, and just
    want a library to handle the specific technical details.


    A standard library API would shift the emphasis slightly, and take
    into account the perspective of the *beginning* programmer, who may
    have only first learned about the command line and files and
    directories in the course of learning Python, and is now venturing
    into the realm of designing full desktop (and mobile?) applications.


    Regards,
    Nick.


    P.S. The statistics module is another example of being able to use the
    Python standard as a teaching tool to help learn something else: for
    many production use cases, you'd reach for something more
    sophisticated (like the NumPy stack), but if what you're aiming to do
    is to learn (or teach) basic statistical concepts, it covers the
    essentials.


    --
    Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
  • Paul Moore at Sep 2, 2015 at 7:46 am

    On 2 September 2015 at 06:57, Nick Coghlan wrote:
    A standard library API would shift the emphasis slightly, and take
    into account the perspective of the *beginning* programmer, who may
    have only first learned about the command line and files and
    directories in the course of learning Python, and is now venturing
    into the realm of designing full desktop (and mobile?) applications.

    Agreed. In this case, the focus should be on providing "correct"
    cross-platform defaults, and assisting (and encouraging) users to
    understand the choices and constraints applicable to other platforms,
    which may not be relevant on theirs.


    This may feel like a nuisance for single-platform developers (a
    Unix-only program doesn't need to care about local or roaming
    preferences, because they don't have the concept of a domain account),
    so it's important to get the defaults right so that people who don't
    need to care, don't have to. But the options should be accessible, so
    that people can learn to make the right choices (for example, pip puts
    preferences in the roaming profile, but the cache in the local
    profile, because you don't want to bloat the roaming profile with a
    cache, but you do want the user's preferences to be available on all
    the machines they use).


    Paul
  • Philipp A. at Sep 2, 2015 at 8:10 am
    OK, original poster here.


    thanks for the positive reception!


    so there are some issues which i?ll address


        1.


        *appdirs doesn?t get everything right*
        ? in order not to have inconsistencies, we could abandon the ?appdirs as
        a fallback? approach and create our own API which returns more correct
        results. this also frees us to make other changes where we see fit, e.g.
        see next point
        2.


        *there is a search path instead of a single directory sometimes*
        ? appdirs provides a multipath keyword argument which returns a
        (colon-delimited) ?list? of paths. we should provide sth. similar, only
        with python lists. maybe also convenience functions for getting a list of
        all files matching some subpath similar to [d / subpath for d in
        site_data_dir(appname, appauthor, all=True) if (d / subpath).exists()]
        3.


        *some platforms don?t have some specific subset of the functionality
        (e.g. no config dir on OSX)*
        ? provide a warning in the stdlib docs about that and refer to another
        settings API. unfortunately i can?t find a good NSDefaults library in
        python right now. i think the API should still return some directory that
        works for storing settings on OSX in case people want to use
        platform-independent config files.
        4.


        *it?s hard to tell newbies where their files are*
        ? unfortunately that?s how things are. the existing standards are
        confusing, but should be honored nonetheless. we can provide an api
    like python
        -m stddirs [--config|--data|...] <companyname> <appname> which prints a
        selection of standard directories.


    did i miss anything?


    and yeah: i also think that something that?s a little opinionated in case
    of ambiguities is vastly better than everyone hacking their own impromptu
    platform-dependent alternative.


    ~/.appname stopped being right on linux long ago and never was right on
    other platforms, which we should teach people.


    best, phil
    ?


    Nick Coghlan <ncoghlan@gmail.com> schrieb am Mi., 2. Sep. 2015 um 07:57 Uhr:

    On 2 September 2015 at 14:38, Robert Collins wrote:
    On 2 September 2015 at 11:05, Paul Moore wrote:
    This is a fair point. But it's also worth noting that the current
    state of affairs for many apps is to just bung stuff in ~/whatever.
    While appdirs may not get things totally right, at least it improves
    things. And if it (or something similar) were in the stdlib, it would
    at least provide a level of uniformity.
    In about 5 years time. Maybe,

    The adoption curve for something that works on all Pythons is able to
    be much much higher than that for something which is only in the
    stdlib 6 months (or more) from now. Unless we do a rolling backport of
    it.

    And if we're going to do that... why? Why not just provide a
    documentation link to the thing and say 'pip install this' and/or
    'setuptools install_require this'.
    My perspective on that has been shifting in recent years, to the point
    where I view this kind of standard library modules primarily as a tool
    to helps folks learn how the computing ecosystem works in practice.
    Consider PEP 3144, for example, and the differences between ipaddress,
    and its inspiration, ipaddr. The standard library one is significantly
    stricter about correctly using networking terminology, so you can
    actually study the ipaddress module as a way of learning how IP
    addressing works. The original ipaddr, by contrast, is only easy to
    use if you already know all the terms, and can say "Oh, OK, they're
    using that term somewhat loosely, but I can see what they mean".

    I think this is a case where a similar approach would make sense -
    like ipaddr before it, appdirs represents an actual cross-version
    production module, put together by a company (in this case ActiveState
    rather than Google) for their own use, but made available to the wider
    community Python through PyPI. As such, we know it's feature coverage
    is likely to be good, but the API design is likely to be optimised for
    experienced developers that already understand the concepts, and just
    want a library to handle the specific technical details.

    A standard library API would shift the emphasis slightly, and take
    into account the perspective of the *beginning* programmer, who may
    have only first learned about the command line and files and
    directories in the course of learning Python, and is now venturing
    into the realm of designing full desktop (and mobile?) applications.

    Regards,
    Nick.

    P.S. The statistics module is another example of being able to use the
    Python standard as a teaching tool to help learn something else: for
    many production use cases, you'd reach for something more
    sophisticated (like the NumPy stack), but if what you're aiming to do
    is to learn (or teach) basic statistical concepts, it covers the
    essentials.

    --
    Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
    _______________________________________________
    Python-ideas mailing list
    Python-ideas at python.org
    https://mail.python.org/mailman/listinfo/python-ideas
    Code of Conduct: http://python.org/psf/codeofconduct/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150902/58967a51/attachment-0001.html>
  • M.-A. Lemburg at Sep 2, 2015 at 9:30 am

    On 02.09.2015 10:10, Philipp A. wrote:
    ~/.appname stopped being right on linux long ago and never was right on
    other platforms, which we should teach people.

    Looking at the my home dir on Linux, there doesn't seem to be
    one standard, but rather a whole set of them and the good old
    ~/.appname is still a popular one (e.g. pip and ansible from
    Python land still use it; as do many other non-Python applications
    such as ncftp, emacs, svn, git, gpg, etc.).


    ~/.config/ does get some use, but mostly for GUI applications,
    not so much for command line ones.


    ~/.local/lib/ only appears to be used by Python :-)
    ~/.local/share/ is mostly used by desktops to register application
    shortcuts


    ~/.cache/ is being used by just a handful of tools, pip being one
    of them.


    appdirs seems to rely on the XDG Base Directory Specification for a lot
    of things on Linux (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
    That's probably fine for desktop GUI apps (the standard was apparently
    built for this use case), but doesn't apply at all for command line tools
    or applications like daemons or services which don't interact with the
    desktop, e.g. you typically won't find global config files for
    command line tools under /etc/xdg/, but instead under /etc/.


    For Windows, the CSIDL_* values have also been replaced with
    new ones under FOLDERID_* (the APIs have also evolved):


    Values:
    https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx
    https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx


    APIs:
    https://msdn.microsoft.com/en-us/library/windows/desktop/bb762181%28v=vs.85%29.aspx
    https://msdn.microsoft.com/en-us/library/windows/desktop/bb762188%28v=vs.85%29.aspx


    BTW: I wonder why the Windows functions in appdirs don't use
    the environment for much easier access to e.g. APPDATA and USERPROFILE.


    --
    Marc-Andre Lemburg
    eGenix.com


    Professional Python Services directly from the Source (#1, Sep 02 2015)
    Python Projects, Coaching and Consulting ... http://www.egenix.com/
    mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/
    mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
    ________________________________________________________________________
    2015-08-27: Released eGenix mx Base 3.2.9 ... http://egenix.com/go83


    ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::


        eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
         D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
                Registered at Amtsgericht Duesseldorf: HRB 46611
                    http://www.egenix.com/company/contact/
  • Donald Stufft at Sep 2, 2015 at 10:58 am

    On Sep 2, 2015, at 5:30 AM, M.-A. Lemburg wrote:

    Looking at the my home dir on Linux, there doesn't seem to be
    one standard, but rather a whole set of them and the good old
    ~/.appname is still a popular one (e.g. pip and ansible from
    Python land still use it; as do many other non-Python applications
    such as ncftp, emacs, svn, git, gpg, etc.).

    Just to be clear: pip supports and prefers the XDG spec, the old locations are just still supported for backwards compatibility. Though we did deviate from XDG in that we use /etc/ instead of /etc/xdg/.
  • M.-A. Lemburg at Sep 2, 2015 at 11:14 am
    I just commented on the ticket that references this discussion:


    http://bugs.python.org/issue7175


    In essence, Python already has an installation scheme which is
    defined in sysconfig.py (see the top of the file) and has had
    this ever since distutils got added to the stdlib.


    It just lacks explicit entries for "config" and "cache" files,
    so adding those would be more in line with coming up with
    yet another standard, e.g. for posix_user:


         'posix_user': {
             'stdlib': '{userbase}/lib/python{py_version_short}',
             'platstdlib': '{userbase}/lib/python{py_version_short}',
             'purelib': '{userbase}/lib/python{py_version_short}/site-packages',
             'platlib': '{userbase}/lib/python{py_version_short}/site-packages',
             'include': '{userbase}/include/python{py_version_short}',
             'scripts': '{userbase}/bin',
             'config': '{userbase}/etc',
             'cache': '{userbase}/var',
             'data': '{userbase}',
             },


    ({userbase} is set by looking at PYTHONUSERBASE and defaults to
    ~/.local/)


    --
    Marc-Andre Lemburg
    eGenix.com


    Professional Python Services directly from the Source (#1, Sep 02 2015)
    Python Projects, Coaching and Consulting ... http://www.egenix.com/
    mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/
    mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
    ________________________________________________________________________
    2015-08-27: Released eGenix mx Base 3.2.9 ... http://egenix.com/go83


    ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::


        eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
         D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
                Registered at Amtsgericht Duesseldorf: HRB 46611
                    http://www.egenix.com/company/contact/
  • Steve Dower at Sep 2, 2015 at 1:19 pm
    "BTW: I wonder why the Windows functions in appdirs don't use
    the environment for much easier access to e.g. APPDATA and USERPROFILE."


    The environment can become corrupted more easily and it's really difficult to diagnose that from a bug report that says "my config is corrupt". I assume appdirs using ctypes now, but I'd be happy to add the call into the os module to avoid that.


    Cheers,
    Steve


    Top-posted from my Windows Phone


    -----Original Message-----
    From: "M.-A. Lemburg" <mal@egenix.com>
    Sent: ?9/?2/?2015 2:31
    To: "Philipp A." <flying-sheep@web.de>; "Nick Coghlan" <ncoghlan@gmail.com>; "Robert Collins" <robertc@robertcollins.net>
    Cc: "Nathaniel Smith" <njs@vorpus.org>; "python-ideas at python.org" <python-ideas@python.org>
    Subject: Re: [Python-ideas] Add appdirs module to stdlib

    On 02.09.2015 10:10, Philipp A. wrote:
    ~/.appname stopped being right on linux long ago and never was right on
    other platforms, which we should teach people.

    Looking at the my home dir on Linux, there doesn't seem to be
    one standard, but rather a whole set of them and the good old
    ~/.appname is still a popular one (e.g. pip and ansible from
    Python land still use it; as do many other non-Python applications
    such as ncftp, emacs, svn, git, gpg, etc.).


    ~/.config/ does get some use, but mostly for GUI applications,
    not so much for command line ones.


    ~/.local/lib/ only appears to be used by Python :-)
    ~/.local/share/ is mostly used by desktops to register application
    shortcuts


    ~/.cache/ is being used by just a handful of tools, pip being one
    of them.


    appdirs seems to rely on the XDG Base Directory Specification for a lot
    of things on Linux (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
    That's probably fine for desktop GUI apps (the standard was apparently
    built for this use case), but doesn't apply at all for command line tools
    or applications like daemons or services which don't interact with the
    desktop, e.g. you typically won't find global config files for
    command line tools under /etc/xdg/, but instead under /etc/.


    For Windows, the CSIDL_* values have also been replaced with
    new ones under FOLDERID_* (the APIs have also evolved):


    Values:
    https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx
    https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx


    APIs:
    https://msdn.microsoft.com/en-us/library/windows/desktop/bb762181%28v=vs.85%29.aspx
    https://msdn.microsoft.com/en-us/library/windows/desktop/bb762188%28v=vs.85%29.aspx


    BTW: I wonder why the Windows functions in appdirs don't use
    the environment for much easier access to e.g. APPDATA and USERPROFILE.


    --
    Marc-Andre Lemburg
    eGenix.com


    Professional Python Services directly from the Source (#1, Sep 02 2015)
    Python Projects, Coaching and Consulting ... http://www.egenix.com/
    mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/
    mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
    ________________________________________________________________________
    2015-08-27: Released eGenix mx Base 3.2.9 ... http://egenix.com/go83


    ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::


        eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
         D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
                Registered at Amtsgericht Duesseldorf: HRB 46611
                    http://www.egenix.com/company/contact/
    _______________________________________________
    Python-ideas mailing list
    Python-ideas at python.org
    https://mail.python.org/mailman/listinfo/python-ideas
    Code of Conduct: http://python.org/psf/codeofconduct/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150902/f338c591/attachment.html>
  • Philipp A. at Sep 2, 2015 at 2:30 pm
    hi marc-andre,


    you seem some misconceptions and a *very* different experience from mine:


    M.-A. Lemburg mal at egenix.com <http://mailto:mal@egenix.com> schrieb am Mi.,
    2. Sep. 2015 um 11:30 Uhr:


    Looking at the my home dir on Linux, there doesn't seem to be
    one standard, but rather a whole set of them

    can you please link to the document from a standards authority describing
    those other stadards? ?


    and the good old ~/.appname is still a popular one (e.g. pip and ansible
    from
    Python land still use it; as do many other non-Python applications
    such as ncftp, emacs, svn, git, gpg, etc.).
    as hinted at by my tongue-in-cheek comment from above: that?s not a
    standard but an old convention.


    git uses ${XDG_CONFIG_DIR-$HOME/.config}/git/config (try it!), as does pip.


    the other ones are old as dirt so this is excusable. regarding newly
    developed programs i?ll only approve it for some rare exceptions like
    shells, where ~/.${SHELL}rc really is the only expected place for a config
    file. (and not that me approving it means something)


    ~/.config/ does get some use, but mostly for GUI applications,
    not so much for command line ones.
    where do you get this figure from? the xdg standard doesn?t say anything
    about only a kind of application being targeted by the standard, and as my
    fontconfig example shows, even libraries follow it.


    ~/.local/lib/ only appears to be used by Python :-)
    >
    yeah, on my system it doesn?t even exist! but that has a reson which you
    can read in the standard: only ~/.local/share is pointed at by the default
    for a standard dir. ~/.local/lib is probably an invention by whoever
    included that path in the default $PYTHONPATH


    ~/.local/share/ is mostly used by desktops to register application shortcuts
    >
    that?s a big understatement, there?s all kinds of stuff in there. i have 56
    dirs and files in there.


    ~/.cache/ is being used by just a handful of tools, pip being one of them.
    >
    hah! various parts of KDE, matplotlib, gstreamer, chromium, fontconfig,
    atom, shall i go on?


    --
    Marc-Andre Lemburg
    eGenix.com
    i hope i could convince you that this isn?t ?some contender among many?,
    but really *the* standard for some directories on linux.


    best, phil
    ?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150902/0cde5567/attachment.html>
  • Random832 at Sep 2, 2015 at 1:36 pm

    On Wed, Sep 2, 2015, at 04:10, Philipp A. wrote:
    *there is a search path instead of a single directory sometimes*
    ? appdirs provides a multipath keyword argument which returns a
    (colon-delimited) ?list? of paths.

    Why isn't it a real list? Paths on any platform can contain a colon;
    paths on Windows commonly do.
  • Philipp A. at Sep 2, 2015 at 2:40 pm

    <random832@fastmail.us> schrieb am Mi., 2. Sep. 2015 um 15:36 Uhr:

    On Wed, Sep 2, 2015, at 04:10, Philipp A. wrote:
    *there is a search path instead of a single directory sometimes*
    ? appdirs provides a multipath keyword argument which returns a
    (colon-delimited) ?list? of paths.
    Why isn't it a real list? Paths on any platform can contain a colon;
    paths on Windows commonly do.



    no idea why, but once we start defining our own API, this will be the most
    important cange from appdirs.


    maybe they use semicolons on windows, but i really don?t see why we
    shouldn?t just use python lists.


    best, philipp
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150902/e52106cf/attachment.html>
  • Eric Fahlgren at Sep 2, 2015 at 6:31 pm
    ~/.appname stopped being right on linux long ago and never was right on other platforms, which we should teach people.

    Ah, yes. I count 17 of those on my Windows machine (!) right now, including .idlerc, .ipython, .matplotlib, .ipylint.d etc., so we've got a ways to go. :)
  • Philipp A. at Sep 3, 2015 at 11:40 am
    Eric Fahlgren <ericfahlgren@gmail.com> schrieb am Mi., 2. Sep. 2015 um
    20:31 Uhr:

    ~/.appname stopped being right on linux long ago and never was right on
    other platforms, which we should teach people.

    Ah, yes. I count 17 of those on my Windows machine (!) right now,
    including .idlerc, .ipython, .matplotlib, .ipylint.d etc., so we've got a
    ways to go. :)

    ?on windows? wat. oh my god this is horrible. so wrong!


    if this isn?t the definitte argument why we need this API yesterday?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150903/e76396a3/attachment.html>
  • Paul Moore at Sep 2, 2015 at 8:19 am

    On 2 September 2015 at 05:38, Robert Collins wrote:
    This is a fair point. But it's also worth noting that the current
    state of affairs for many apps is to just bung stuff in ~/whatever.
    While appdirs may not get things totally right, at least it improves
    things. And if it (or something similar) were in the stdlib, it would
    at least provide a level of uniformity.
    In about 5 years time. Maybe,

    Most of the programs I write are for Python 3.4 at the moment, and
    will be for Python 3.5 as soon as it comes out. They won't be
    distributed outside of my group at work, if indeed anyone but me uses
    them. They won't care about older versions of Python. I don't even
    care about cross-platform. But I do want to set up a cache directory,
    or save some settings, without thinking *too* hard about where to put
    them. I don't want to have an external dependency because I'm forever
    running these things from whatever virtualenv I currently have active
    (sloppy work habits, I know, but that's the point - not everything is
    a nicely structured development project).


    For programs that need to support older versions of Python, a backport
    should be trivial - I can't see that this would need any particularly
    "modern" Python features.


    Paul
  • Steven D'Aprano at Sep 4, 2015 at 1:43 am

    On Wed, Sep 02, 2015 at 04:38:05PM +1200, Robert Collins wrote:


    And if we're going to do that... why? Why not just provide a
    documentation link to the thing and say 'pip install this' and/or
    'setuptools install_require this'.

    I can think of two reasons, one minor, one major:


    1. Many people behind corporate or school firewalls cannot just "pip
    install this". By "firewall" I'm talking more figuratively than
    literally. Of course there may be an actual firewall blocking access to
    PyPI, but that's typically very easy to bypass (download the library at
    home and bring it in on a USB stick). Less easy to bypass is corporate/
    school policy which prohibits the installation of unapproved software,
    often being a firing or expulsion offense. Getting approval may be
    difficult, slow or downright impossible.


    However, what makes this a minor reason is that software written under
    those conditions probably won't be distributed outside of the
    organisation itself, so who cares whether it complies with the standard
    locations for application data?


    2. More importantly is the stdlib itself. As someone has pointed out,
    the stdlib already drops config files in completely inappropriate
    locations on Windows, e.g. $HOME/.idlelib. It would be good if the
    stdlib itself could consistently use the standard locations for files.




    --
    Steve
  • Serhiy Storchaka at Sep 1, 2015 at 5:55 pm

    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/).
  • Florian Bruhin at Sep 2, 2015 at 4:18 am

    * 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 at 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/
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 819 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150902/c01eb355/attachment.sig>

Related Discussions

People

Translate

site design / logo © 2018 Grokbase