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

[Vinay Sajip]

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

> I'd propose that the install arguments used in bdist_wininst be
> transferred to bdist_dumb (or a new command bdist_binary created based
> on the same), because the bdist_wininst 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 bdist_wininst 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 install_method to _run_install_from_dir 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 bdist_wininst (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).

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

Regards,

Vinay Sajip