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

Paul Moore p.f.moore at gmail.com
Mon Oct 10 11:49:56 CEST 2011

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, bdistdumb 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 bdistdumb doesn't get used). Specifically, bdistdumb 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 bdistdumb call the install commands with different arguments.  That is, it's a relatively shallow flaw in bdistdumb.

Agreed.

bdistwininst, for example, is basically a zipped bdistdumb 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.

More information about the Python-Dev mailing list