[Python-Dev] Packaging and binary distributions

[Paul Moore]

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 bdist_wininst 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. bdist_msi 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 bdist_xxx formats, so the answer is "run
>>> pysetup run bdist_wininst 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.