[Python-Dev] Packaging and binary distributions

"Martin v. Löwis" martin at v.loewis.de
Mon Oct 31 11:42:58 CET 2011


Am 31.10.2011 09:07, schrieb Vinay Sajip:
> Paul Moore <p.f.moore <at> gmail.com> writes:
> 
>> Hang on. I'm talking here about repackaging the binary files in the
>> MSI file for use in a pysetup install invocation. As pysetup has no
>> GUI, and doesn't integrate with Add/Remove, there's no issue here. If
>> you want a GUI and Add/Remove integration, just run the MSI. Or am I
>> missing something? We seem to be at cross purposes here, I suspect I'm
>> missing your point.
> 
> As you say later in your post, we're probably just coming at this from two
> different perspectives. I think you mentioned the possible need to install to a
> temporary location just to extract files from the CAB; then you would
> presumably need to uninstall again to remove the Add/Remove Programs entry
> created when you installed to the temporary location (or else I misunderstood
> your meaning here).

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.

>> Why? Again, if this is purely as a means to consume bdist_xxx files,
>> then the only flexibility needed is enough to cater for any variations
>> in data stored in the bdist_xxx format. The wininst format is easy
>> here - it has directories PLATLIB, PURELIB, DATA, SCRIPTS and HEADERS
>> (corresponding to the installation --install-xxx parameters) and
>> that's all. As long as the module is flexible enough to deal with
>> that, it can read anything bdist_wininst can produce.
> 
> 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.

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

Regards,
Martin


More information about the Python-Dev mailing list