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

Paul Moore p.f.moore at gmail.com
Mon Oct 10 20:29:26 CEST 2011

On 10 October 2011 17:12, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

Paul Moore <p.f.moore gmail.com> writes:

I'd propose that the install arguments used in bdistwininst be transferred to bdistdumb (or a new command bdistbinary created based on the same), because the bdistwininst zip format has the following advantages:

1. Proven format, so it should deal with any edge cases like header files reasonably. And the code already exists. 2. Easily recognisable directory names (PLATLIB, PURELIB, etc) making detection easy without needing extra metadata. 3. At a pinch, a bdistwininst installer could be treated as a dumb distribution without change (assuming the stdlib zip handling correctly ignores prepended data like the exe header). Then pysetup could be enhanced to recognise and install the binary format in pretty much the same way as it does source formats (add another installmethod to runinstallfromdir that copies the files to the target locations along with appropriate checking and/or metadata handling). A simple change to packaging will allow an archive containing a setup.cfg-based directory to be installed in the same way as a source directory. AFAICT this gives a more useful result than bdistwininst (as you typically want to install in more places than PURELIB and PLATLIB, and the setup.cfg scheme allows for writing files to locations such as Powershell script directories for a user).

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.

There might be a small amount of extra work to do, to check binary version compatibility, but that shouldn't be hard.

If this is useful, I could look at creating a patch. (Once I get my build environment fixed so I can get 3.3 up and running - it looks like Python 3.3 can't be built with Visual C++ Express these days, the IDE can't convert the solution files because Express Edition doesn't support 64-bit. I'll have to fish out the full version and install that...) There's one thing that you touched on in an earlier post, which hasn't been further discussed: support for virtual environments. The executable installer format covers two things: packaging of version specific/compiled code, and the simplicity of point-and-click installation. This latter convenience is worth having, but the current installer stub (wininst-x.y.exe) does not know anything about virtual environments. If we care about virtual environment support (and I think we should), wininst.exe could be enhanced to provide a "Browse..." button to allow a user to select a virtual environment to install into, in addition to the detection of installed Pythons from the registry. If this is coupled with the ability to invoke a setup.cfg-based installation when the appended archive is for a setup.cfg-based directory tree, won't this pretty much tick all the boxes?

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.

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

(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 :-))

Paul.

More information about the Python-Dev mailing list