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

[Vinay Sajip]

> I'm not sure what you mean by a "setup.cfg-based directory". Could 

> you
> clarify, and maybe explain how you'd expect to create such an archive?
> We may be talking at cross-purposes here.

Here's how I see it: at present, you can install a project by specifying

pysetup3 install path-to-directory

where the named directory contains a setup.cfg (replacing setup.py) and a bunch of things to install. Exactly what to install where is specified in the setup.cfg: it covers not only python packages and modules but also arbitrary binary files. The setup.cfg format is extensible enough to allow specifying where files are installed not only declaratively (as static paths in setup.cfg) but also according to criteria computed at installation time (e.g., write some PowerShell scripts to the installing user's PowerShell profile location).

Of course, since you can install arbitrary data (and record what was installed where, to allow uninstallation to work), you can certainly install DLLs too (modulo the user having write permissions for the installation location, but that's true for data files, too).

In theory, therefore, a binary distribution could be installed from a directory containing a setup.cfg, some DLLs, Python source files, and other text and binary data files. Moreover, it would be just as easy to zip that whole directory up (using any zipping tools), and pass it around as a .zip file; at installation time, the packaging code would unpack the directory in a temporary location and install from there.

The zip archive can, of course, be appended to an executable which does the relevant unpacking and calls to packaging code to actually do the installation. The scheme is conceptually the same as the wininst-x.y.exe does - only the details differ. This gives a one (double-)click installer.

> Agreed - but I'm looking at a pysetup install approach to work for
> source and binary packages, essentially replacing the use of
> bdist_wininst and bdist_msi with sdist/bdist_simple archives. That's a
> change of heart for me, as I used to argue for wininst/msi over
> setuptools and similar - but pysetup includes all the listing and
> uninstalling features I wanted, so the "one unified approach" has won
> me over in preference to the platform integration.

Right, but AFAICT pysetup3 will work now with a binary distribution, other than it does not contain mechanisms for checking Python version and platform compatibilities. Being a command line script, it will even support virtual environments without too much trouble - I've been working on this in the pythonv branch with some success. What's missing from things is a .exe installer; even though you might be happy without one, not having it may be seen by some as a retrograde step.

> Ideally bdist_wininst and bdist_msi would also integrate with pysetup
> and with virtual environments, but I imagine that could be pretty hard
> to make work cleanly, as Windows doesn't really support multiple
> installations of a software package...

I don't think Windows itself cares in general, it's more about the specifics of what's being installed. Obviously some things like COM components would need to be managed centrally, but I would imagine that if you had two projects with separate versions of e.g. C-based extensions, you could install the relevant DLLs in separate virtual environments and not necessarily have problems with them coexisting.

> (Plus, I've no real idea about how bdist_wininst works, so while you
> may be right, I wouldn't know how to do anything with your suggestion
> :-))

Though I can't claim to have looked at the codebase in detail, the overall scheme would appear to be this: bdist_wininst creates an executable from wininst-x.y.exe (part of Python, in a distutils directory), appends some metadata (used in the UI of wininst-x.y.exe - things like the package name, icon etc.) and appends to that an archive containing all the stuff to install. When the executable is run, the UI is presented incorporating relevant metadata, user input solicited and the archive contents installed according to that input. However, the installation locations are determined from the registry information on installed Pythons only, with no nod to the possibility of users having installed multiple virtual environments from those installed Pythons.

Regards,

Vinay Sajip