[Python-Dev] Packaging and binary distributions (original) (raw)

Paul Moore p.f.moore at gmail.com
Mon Nov 7 11:22:27 CET 2011

On 7 November 2011 09:26, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

Martin v. Löwis <martin v.loewis.de> writes:

Again, that's a bdistmsi 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.

More information about the Python-Dev mailing list