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

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

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