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

Vinay Sajip vinay_sajip at yahoo.co.uk
Mon Jun 20 11:48:13 CEST 2011


Éric Araujo <merwok <at> netwok.org> writes:

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

Okay.

> Categories are extensible, so it’s a way.  See also the short
> description of the packaging configure command in my other message.

Thinking about it further - I'm not sure it'll be sufficient, in a number of
cases, at least under Windows but potentially on other platforms, too. Where
software is self-contained, having a fixed set of categories for different types
of assets is sensible and sufficient. Where software needs to interoperate with
other software, for example, things can get a little more complicated. I've
already given an example relating to Powershell. As another example: say I'm
developing some software to interoperate with legacy systems such as Microsoft
Office (including Outlook) or Sharepoint, which are prevalent in the corporate
world. The chances are very high that I'll need to install things in what is,
from packaging's perspective, an essentially arbitrary set of locations. It's
seems that it's not really possible to codify these using the schemes which we
have now - schemes which are perfectly useful in the context of e.g. harmonising
how we work with Linux distro packagers.

I don't know if this has been brought up before, or discussed and rejected - but
I think that something along the lines of Debian's prerm/postrm,
preinst/postinst should be available, defined in the same way as setup_hooks in
setup.cfg, to be called at the appropriate time in the pysetup3 lifecycle. This
would provide some measure of standardisation, allowing projects with simple
needs to omit them entirely, but those with more complex needs to do things
which we can't foresee. As a bare minimum, prerm and postinst: these can rely on
the distribution being installed and so have access to packages inside it.

Of course, this is the rationale behind the post-install script option for
bdist_wininst.

Regards,

Vinay Sajip



More information about the Distutils-SIG mailing list