[Python-Dev] Packaging and binary distributions
Vinay Sajip
vinay_sajip at yahoo.co.uk
Mon Oct 31 00:17:17 CET 2011
Paul Moore <p.f.moore <at> gmail.com> writes:
> The MSI format is a little more tricky, mainly because it is a more
> complex format and (as far as I can tell from a brief check) files are
> stored in the opaque CAB format, so the only way of getting data out
> is to do a temporary install somewhere. But I see no reason why that
> isn't achievable.
It's not just about getting the data out of the CAB, though - it's also about
integration with Add/Remove Programs and the rest of the Windows Installer
ecosystem.
> 1. I will write a 3rd party module to take bsist_wininst and bdist_msi
> modules and install them using packaging
It would be important to retain the flexibility currently offered by setup.cfg
hooks, as I don't believe any out-of-the-box approach will work for the wide
range of use cases on Windows (think Powershell scripts, Visio templates and
other Microsoft Office integration components).
I'm also not sure if these formats provide all the flexibility required - e.g.
they may be fine for extension modules, but how do they handle packaging include
files?
> For 3.3 at least, I'd expect developers to continue distributing
> bdist_wininst or bdist_msi format files. We'll see what happens with
> binary eggs.
>
> Unix/MacOS users who care will need to propose something themselves.
I'm not sure there's anything especially Windows-specific about the
bdist_wininst format, apart from the prepended GUI executable. One drawback of
any current scheme is that if you're packaging an extension module that runs on
say Windows, Linux and Mac OS X, there's no easy way to build or distribute a
single archive (for a given version of Python, say) which has all the binary
variants you want to include, such that at installation time, only the bits
relevant to the target platform are installed. The current packaging
functionality does sort of support this, but it entails potentially tedious
manual editing of the setup.cfg file to add information about what resources
apply to which platform - the kind of tedious editing which would be obviated by
the right kind of additional support code.
Regards,
Vinay Sajip
More information about the Python-Dev
mailing list