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

Paul Moore p.f.moore at gmail.com
Mon Oct 31 12:21:45 CET 2011

On 31 October 2011 10:42, "Martin v. Löwis" <martin at v.loewis.de> wrote:

Am 31.10.2011 09:07, schrieb Vinay Sajip: This presumption is false (as is the claim that you need to install the MSI to get at the files). It's quite possible to extract the files from the MSI without performing the installation. There are actually two ways to do that: a) perform an "administrative" installation, which unpacks the files to disk but doesn't actually perform any installation procedure, or b) use the MSI API to extract first the CAB file, and then the files in the CAB file. This would be a bit work to do if you want to find out the full path names of the individual files, but it could work in theory.

Yes, I'm currently doing an administrative install via msiexec to get the files out. It's simple enough to do.

My point is really that a one-size-fits-all DATA location is unlikely to cater to all use cases. The flexibility offered by setup.cfg together with hooks gets around the limitation of a single location for data. I'm sure bdistwininst can be augmented to support arbitrary "base prefixes" (assuming that is the flexibility you talk about). It would just need a list of what directory names are prefixes, The MSI format is designed to provide exactly that flexibility of arbitrarily mapping source folders to destination folders during installation. bdistmsi would just need to be taught to interpret setup.cfg files.

Agreed - the "one size fits all" data location is a limitation. I'm not sure that in practical terms it is a big issue, though - it's been like that since the wininst format was designed, and nobody has ever complained. There are certainly cases where packages have needed to implement more or less clumsy workarounds (for example, not including documentation in binary distributions) but it's obviously never been enough of an issue to prompt people to fix it. The egg format has the same limitation, as far as I'm aware, so clearly even the "eggs solve everything" crowd don't feel it's a real issue :-)

Ah, I think I see what you are getting at. If someone uses the new features and flexibility of packaging to create a fancy custom install scheme, how do they bundle up a binary distribution from that? My (current) answer is that I don't know. The packaging module as it stands only offers the legacy bdistxxx formats, so the answer is "run pysetup run bdistwininst on it". If that breaks (as it is likely to - wininst format isn't very flexible) then tough, you're out of luck.

Yes, that's what I was getting at. Hmm. You are just describing a bug, not an inherent limitation.

Precisely. And it's a bug that no-one has felt the need to fix in many years. The flexibility is not new - distutils had at least as much flexibility if not more.

I'd love to see a binary format that was as flexible and powerful as building from source, which allowed OS integration where the user wanted it while still supporting venvs and non-system installations, and which was widely adopted by distribution authors. Oh, and can I have a pony? :-) Sadly, I don't have the time or understanding of the various requirements to deliver something like that.

Realistically, I'd just like to be able to benefit from the generosity of existing distribution authors who make compiled versions of their code available, however they choose to do so. Hence my current focus on consuming existing formats (and even the bdist_simple proposal/patch was little more than a tidied up bdist_wininst made OS-neutral).

Paul.

More information about the Python-Dev mailing list