3.3 / packaging - support for Windows installation locations
While packaging's support for path-based installation seems reasonably comprehensive, on recent Windows versions, installation locations aren't always simply based on fixed or declaratively specifiable locations. For example, say that some data needs to be installed in a user's "Documents" folder under Windows 7. You might assume that this would be e.g. "C:\Users\Vinay\Documents", but in fact that might not be the correct location. To do it correctly for all scenarios involves jumping through some hoops: from ctypes import windll, Structure, byref, w_char_p # and other stuff besides class GUID(Structure): # define a GUID structure in terms of ctypes longs, shorts etc. Documents_FolderID = GUID(...) # using constants from Windows KnownFolders.h path = w_char_p() # to hold the resulting path windll.shell32.SHGetKnownFolderPath(byref(Documents_FolderID), ..., byref(path), ...) and then use path.value as the location of the Documents folder. What's the best way of handling these sorts of situations with Python 3.3 packaging? Regards, Vinay Sajip
On 06/18/2011 02:26 PM, Vinay Sajip wrote:
What's the best way of handling these sorts of situations with Python 3.3 packaging? Isn't it something that should be handled by the sysconfig module? (http://docs.python.org/dev/library/sysconfig.html)
-- Alexis
Alexis Métaireau
On 06/18/2011 02:26 PM, Vinay Sajip wrote:
What's the best way of handling these sorts of situations with Python 3.3 packaging? Isn't it something that should be handled by the sysconfig module? (http://docs.python.org/dev/library/sysconfig.html)
Perhaps, but perhaps not. For example, the sysconfig.get_paths() returns a path like this for the 'data' key: C:\\Users\\Vinay\\AppData\\Roaming\\Python This might be fine for many applications, but say you were to install some Powershell scripts, those would need to live in C:\\Users\\Vinay\\Documents\\WindowsPowershell for Powershell to load them automatically. There's only one reference to the special location path determining code - in PC\bdist_wininst\install.c - which appears to be for executable installers only. This could in theory be handled by a project-specific post-installation step (which could e.g. be in Python code bundled with the project), which could be declared in setup.cfg and invoked by pysetup3 after the installation actions. Is there such a provision? If so, I couldn't find it, but perhaps I missed it and someone could point it out to me. Regards, Vinay Sajip
Le 18/06/2011 16:18, Vinay Sajip a écrit :
On 06/18/2011 02:26 PM, Vinay Sajip wrote:
What's the best way of handling these sorts of situations with Python 3.3 packaging? Isn't it something that should be handled by the sysconfig module? (http://docs.python.org/dev/library/sysconfig.html) Perhaps, but perhaps not. For example, the sysconfig.get_paths() returns a path
Alexis Métaireau
writes: like this for the 'data' key: C:\\Users\\Vinay\\AppData\\Roaming\\Python
This might be fine for many applications, but say you were to install some Powershell scripts, those would need to live in
C:\\Users\\Vinay\\Documents\\WindowsPowershell
for Powershell to load them automatically. There's only one reference to the special location path determining code - in PC\bdist_wininst\install.c - which appears to be for executable installers only.
This could in theory be handled by a project-specific post-installation step (which could e.g. be in Python code bundled with the project), which could be declared in setup.cfg and invoked by pysetup3 after the installation actions. Is there such a provision? If so, I couldn't find it, but perhaps I missed it and someone could point it out to me.
I think two features I’d like to add to 3.3 may cover your needs. The first one is standard functions to get the right config, data, cache, etc. directories for an application (http://bugs.python.org/issue7175); the second is a configure command for packaging (http://bugs.python.org/issue8254), which would record everything related to the installation (paths and al.) and make it available at build time and run time to other projects, making it possible for a plugin to find the right dir to install files for an application. See also the threads last summer about PEP 376 and plugins on distutils-sig (and I believe python-dev). Cheers
Éric Araujo
I think two features I’d like to add to 3.3 may cover your needs. The first one is standard functions to get the right config, data, cache, etc. directories for an application (http://bugs.python.org/issue7175); the second is a configure command for packaging (http://bugs.python.org/issue8254), which would record everything related to the installation (paths and al.) and make it available at build time and run time to other projects, making it possible for a plugin to find the right dir to install files for an application.
See also the threads last summer about PEP 376 and plugins on distutils-sig (and I believe python-dev).
Okay, I'll look at these - thanks. Is there somewhere online where design notes and ideas are being collected / summarised? It's hard to tell which parts of e.g. notmyidea.org and python-distribute.org are still current. Regards, Vinay Sajip
Okay, I'll look at these - thanks. Is there somewhere online where design notes and ideas are being collected / summarised?
Not really. * The bug report about config/cache/etc. paths API contains most of the discussion and links to python-dev threads. This is not related to packaging. * The bug report about configure links to the wiki I used last summer and my repository with the code; a few things are only in Tarek’s head. * The thinking about sysconfig.py, sysconfig.cfg and _sysconfig.cpython3.3.so is scattered on two or three bug reports and https://bitbucket.org/tarek/distutils2/src/tip/docs/design/wiki.rst .
It's hard to tell which parts of e.g. notmyidea.org and python-distribute.org are still current.
Yeah. Last summer, I pulled from all GSoC students repos and merged the docs so that notmyidea could always have all doc, even though not all the code was in the official repo. Then Alexis changed it to use the doc from the main repo, and then I think switched to readthedocs. python-distribute is/was lead by the distribute group, which overlaps with the packaging (distutils2) fellowship. Its packaging guide was not updated for a distutils2-in-the-stdlib world. I could make a new landing page on the Python to explain the status of distutils2, summarize future directions, tell where to find the docs, link to the existing pages like http://wiki.python.org/moin/Distutils/Contributing and http://wiki.python.org/moin/Distutils/FixingBugs . Do you think that would be better?
Éric Araujo
I could make a new landing page on the Python to explain the status of distutils2, summarize future directions, tell where to find the docs, link to the existing pages like http://wiki.python.org/moin/Distutils/Contributing and http://wiki.python.org/moin/Distutils/FixingBugs . Do you think that would be better?
I think so - when things are in a state of flux and lots of ideas are being discussed, once they have coalesced into a broad consensus, it's useful to be able to see what that consensus is with open issues pointed out, separated from discussions that perhaps went nowhere. That would make both contributions themselves easier, and also allow people working on related areas to take advantage of a better roadmap. Thanks for the helpful summary. Regards, Vinay Sajip
It's hard to tell which parts of e.g. notmyidea.org and python-distribute.org are still current. Yeah, that's right. I will put a redirection from distutils2.notmyidea.org to the new packaging doc hosted on docs.python.org/dev/ as distutils2 is not currently where we develop
On 06/18/2011 11:59 PM, Éric Araujo wrote: packaging those days. -- Alexis
participants (3)
-
Alexis Métaireau -
Vinay Sajip -
Éric Araujo