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

Paul Moore p.f.moore at gmail.com
Thu Oct 13 20:36:11 CEST 2011

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 bdistsimple instead of wininst or eggs. Pardon me for jumping in - but I fail to see why those missing features can't be provided by bdistwininst and bdistmsi 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.

More information about the Python-Dev mailing list