[Python-Dev] Packaging and binary distributions

[Vinay Sajip]

>

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

In this case at least, the code *all* runs at installation time: the distributed
package contains all files for all platforms, and at installation time the
choice is made as to which files to actually install from the installation
directory to the target directories.

While this might not be ideal for all packagers, the only downside of having
all files for all platforms available in a single distribution is disk space - an
increasingly cheap commodity. OTOH there is some advantage in having a
single package which would be usable on all platforms (supported by the
package being distributed), albeit perhaps for a particular version of Python.


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

In terms of the flexibility required, the code to determine the "personal
path" is being run at installation time, to determine the target folder for
the PowerShell scripts. It's this kind of flexibility (by which I mean Python
coded logic) that I don't see how to easily provide in the MSI format,
short of recoding in e.g. C, in a custom action DLL or EXE. (This latter
approach is what I've used in the PEP 397 launcher MSI.)

Regards,

Vinay Sajip