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

[Paul Moore]

2011/10/10 PJ Eby <pje at telecommunity.com>:
> On Sun, Oct 9, 2011 at 4:14 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> As regards the format, bdist_dumb is about the right level - but
>> having just checked it has some problems (which if I recall, have been
>> known for some time, and are why bdist_dumb doesn't get used).
>> Specifically, bdist_dumb puts the location of site-packages ON THE
>> BUILD SYSTEM into the archive, making it useless for direct unzipping
>> on a target system which has Python installed somewhere else.
>
> I don't know about the case for packaging/distutils2, but I know that in
> original distutils, you can work around this by making bdist_dumb call the
> install commands with different arguments.  That is, it's a relatively
> shallow flaw in bdist_dumb.

Agreed.

> bdist_wininst, for example, is basically a zipped bdist_dumb with altered
> install arguments and an .exe header tacked on the front.  (Along with a
> little extra data crammed in between the two.)

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

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

Paul.