[Python-Dev] Packaging and binary distributions for Python 3.3

[Paul Moore]

On 13 October 2011 18:30, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> wininst and msi bdists can continue to be used as previously, for people
>> who want clicky installation to their system Python.  With built-in
>> package management and virtual environments in 3.3+, we can just
>> recommend that people publish bdist_simple instead of wininst or eggs.
>
> Pardon me for jumping in - but I fail to see why those missing features
> can't be provided by bdist_wininst and bdist_msi in a straight-forward
> manner. Giving people even more choice is bad, IMO, as it will confuse
> users. There should be one obvious way.

I don't particularly disagree - although I would point out that the
two formats bdist_wininst and bdist_msi already offer more than one
obvious way...

My contention is that there *are* two distinct use cases - platform
integrated installation (on Windows that implies a GUI to most
people), and Python's native installation process (pysetup). This
isn't new, before packaging the "python-native" form was
setuptools/eggs, for better or worse. Ideally, both forms should have
full capabilities, making the decision a style/preference choice
rather than a functionality choice. But this particular choice is
always with us, and people are familiar with it. (Native vs
cross-platform GUIs, cygwin vs mingw, etc, etc). So we need two
obvious ways, one for each case. (It would be nice if one way could
cover both cases, of course - having pysetup consume bdist_wininst
files is my attempt to achieve that).

I don't really understand the benefits of bdist_msi over
bdist_wininst, and I certainly don't understand the MSI technology
well enough to comment on what it's capable of, so I'm going to stick
to bdist_wininst in the following. My apologies for anything I miss as
a result. But it does strike me that the existence of both MSI and
wininst is where the confusing duplication exists, rather than having
GUI and command line alternatives.

The GUI and platform integration aspects of the bdist_wininst format
are all part of the executable "bit". I haven't looked at that code at
all, but I am certain it can be modified to provide whatever user
experience is desired. The only real problem here is how many people
have the knowledge and/or inclination to work on that code. When it
comes to installing the actual package, I don't know how the
bdist_wininst code does it - the data is there in zip format, and I
suspect that the code simply unzips the data in the expected
directories. But the zipped up data in bdist_wininst could be consumed
by the packaging module, just by writing a new install method. This
would reuse all of the various packaging support routines and
infrastructure. The bdist_wininst executable code *could* be modified
to invoke that packaging method - whether that's worthwhile isn't
clear to me (I don't know how extensive the changes would be to get
the benefit reusing the same implementation).

As MSI format is a specialised format, I don't believe this option is
open for bdist_msi.

> In particular wrt. virtual environments: I see no need to actually
> *install* files multiple times. It's rather sufficient that the
> distributions to be installed are *available* in the virtual env after
> installation, and unavailable after being removed. Actually copying
> them into the virtual environment might not be necessary or useful.
>
> So I envision a setup where the MSI file puts the binaries into a place
> on disk where pysetup (or whatever tool) finds them, and links them
> whereever they need to go (using whatever linking mechanism might work).
> For MSI in particular, there could be some interaction with pysetup,
> e.g. to register all virtualenvs that have linked the installation,
> and warn the user that the file is still in use in certain locations.
> Likewise, automated download might pick an MSI file, and tell it not
> to place itself into the actual Python installation, but instead into
> a location where pysetup will find it.

I can't really comment on this. I agree in principle with what you're
saying, but I know little about the MSI format so I can't say much
more. It feels to me like you're suggesting that the MSI file
encapsulate the file layout logic that already has to exist in
pysetup, though, which sounds like duplication of effort. Can MSI call
out to pysetup to actually install the files and save this
duplication?

Paul.