Le 18/06/2011 23:23, Vinay Sajip a écrit :
Éric Araujo
writes: This is not a design choice but a bug: http://bugs.python.org/issue11637 We definitely want to support project-local hooks module, as they will certainly be used a lot during the transition years. Thanks for the pointer. I may need this to be fixed in my pythonv fork, so I will attempt a patch there.
Thanks, I’ll be here to review the patch. It should be easy, just remember to add or update tests.
I’m not sure data files support environment markers. Anyway, please report any info missing from the docs, they’re far from complete. On further study, I see you're right - environment markers will work only with some of the data. This gap can certainly be handled by setup hooks, once #11637 is fixed, but there's also another problem which I've encountered: on Windows at least, installing into the conventional appdata paths is fine for simple applications, but insufficient for applications that need to interact better with the Windows ecosystem. For example, if you want to install Powershell modules, they live not in conventional appdata locations but rather in subdirectories below a user's Documents folder, which is obtained by making calls into the Windows Shell API, such as SHGetKnownFolderPath or SHGetSpecialFolderPath. I can't see any references to these in packaging or sysconfig, so how are these values being determined?
Well, I don’t think they are. The paths used for Windows are a transposition of UNIX paths to C:\\PythonX.Y, with Scripts, Lib, etc. subdirs; they’re not very Windows-y. IOW, I think improving the installation schemes on Windows for 3.3 to feel more native would be a good thing. See also http://bugs.python.org/issue9878 : Avoid parsing pyconfig.h and Makefile by autogenerating extension module (which means that using C APIs is wholly in line with future direction for sysconfig).
I appreciate that might not be a packaging issue but rather a sysconfig one, but it's certainly of interest to packagers :-)
This is definitely on-topic: sysconfig was extracted from distutils, is maintained by Tarek and evolved by the packaging fellowship. Installation is part of packaging.
The only references I found to the shell APIs is in PC\bdist_winst\install.c, which (I presume) wouldn't be invoked during a "pysetup3 install" operation.
Yep, only during pysetup run bdist_wininst, IIUC.
So, it seems to me like some way is needed for a project to be able to inject additional categories like {userdocs} and path mappings for them, for its resources. I appreciate that this is more an issue for Windows than Unix platforms, but is there such a mechanism?
Categories are extensible, so it’s a way. See also the short description of the packaging configure command in my other message.
Incidentally, I noticed a repeated assignment in packaging/install.py:_run_install_from_dir(): func = install_methods[install_method] is called twice in succession, I couldn't see why.
Just a small mistake in ebff46b232ed.