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

[Paul Moore]

On 9 October 2011 20:47, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> On Sun, Oct 9, 2011 at 9:31 PM, PJ Eby <pje at telecommunity.com> wrote:
> ...
>>> What we can do however
>>> is to see what bdist_egg does and define a new bdist command inspired by
>>> it, but without zipping, pkg_resource calls, etc.
>>
>> Why?  If you just want a dumb bdist format, there's already bdist_dumb.
>>  Conversely, if you want a smarter format, why reinvent wheels?
>
> Just to make sure we're on the same page here.
>
> PEP 376 provide the installation format for the 'future' --
> http://www.python.org/dev/peps/pep-0376/
[...]
> Now for a binary archive, that would get installed ala PEP 376, why
> not ? I'd just be curious to have someone list the advantage of having
> a project released that way besides the "importable as-is" feature.

Agreed. I'm not looking at a new binary installed format - PEP 376
covers this fine. What I am looking at is how/if users without a
compiler can get a file that contains all the bits they need to
install a distribution.

My expectation would be that the user would type pysetup install
some_binary_format_file.zip and have that file unpacked and all the
"bits" put in the appropriate place. Basically just like installing
from a source archive - pysetup install project-1.0.tar.gz - but
skipping the compile steps because the compiler output files are
present. That may need some extra intelligence in pysetup if it
doesn't have this feature already (I sort of assumed it would, but
that's likely because of my interest in binary formats) but if not it
shouldn't be hard to add - just unzip the bits into the right place,
or something similar.

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.

See the following for an example:

PS D:\Data\python-sample> unzip -l .\dist\PackageName-1.0.win32.zip
Archive:  ./dist/PackageName-1.0.win32.zip
  Length     EAs   ACLs    Date   Time    Name
 --------    ---   ----    ----   ----    ----
     6656      0      0  09/10/11 20:56
Apps/Python32/Lib/site-packages/hello.pyd
      208      0      0  09/10/11 20:56
Apps/Python32/Lib/site-packages/PackageName-1.0-py3.2.egg-info
 --------  -----  -----                   -------
     6864      0      0                   2 files

It should be simple enough to fix this in bdist_dumb, although a new
name might be needed if backward compatibility of the old broken
format matters...

If pysetup doesn't have support for binary archives at all, then I'm
happy to take a look at what might be involved in adding this. But I
don't know the code at all, and I have little time, so I'm rather
hoping I won't need to...

Paul.

PS The problem for me is that if pysetup only handles source builds,
it's STILL annoyingly incomplete for my requirements (and possibly
many Windows users') So I feel this is a hole that needs to be filled
before 3.3 is released, or pysetup won't be suitable as "the way to do
all packaging in Python".