[Distutils] Python 3.3 / packaging - how to make installation conditional on platform?

[Éric Araujo]

Le 18/06/2011 23:23, Vinay Sajip a écrit :
> Éric Araujo <merwok <at> netwok.org> 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.