[Python-Dev] Packaging and binary distributions

[Paul Moore]

On 7 November 2011 09:26, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Martin v. Löwis <martin <at> v.loewis.de> writes:
>
>>
>> Again, that's a bdist_msi implementation issue. It could generate custom
>> actions that run the "proper" setup.cfg hooks (I presume - I have no
>> idea what a setup.cfg hook actually is).
>>
>
> I know that custom hooks are quite powerful, but my comment was about having
> the functionality in Python. Here's an example of a working hooks.py:

It seems to me that there are two separate things going on in this
sample. It's not 100% clear that they are separate, at first glance,
as packaging currently doesn't make a strong distinction between
things going on at "build" time, and things going on at "install"
time. This is essentially because the idea of binary installs is not
fundamental to the design. (Thanks for sharing this example, btw, I
hadn't really spotted this issue until I saw the code here).

Suppose you have two people involved - the "packager" who uses the
source code to create a binary distribution (MSI, wininst, zip,
doesn't matter - conceptually, it's a set of "final" files that need
no further processing and can just be put in the correct locations on
the target PC) and the "end user" who takes that binary distribution
and installs it on his PC.

Some of the hook code is designed to run at "build" time (the stuff
that adds the right resource files). This can be run on the packager's
machine quite happily, as long as the packager is using the same OS as
the end user. However, other parts of the hook code (the stuff that
defines the custom categories) must run on the end user's PC, as it
detects specific aspects of the target PC configuration.

I think Martin is only really interested in the second type of hook
here. I know that I am, insofar as they are the only type I would
expect to need to support if I were building a new binary distribution
format. But without the two types being more clearly separated, it's
not obvious that it's possible to "just support one type" in quite
that sense...

Paul.

PS There are subtleties here, of course - byte-compiling .py files is
probably an install-time action rather than a build-time one, so my
"no further processing required" comment isn't 100% true. But the
basic principle certainly applies.