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

[Michael Foord]

On 9 Oct 2011, at 21:14, Paul Moore wrote:
> 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.

Just to agree with Paul, a typical Windows Python user will not be able to install a non-binary version of a distribution that includes C code. Even on the Mac it is common to distribute binaries.

Michael

> 
> 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".
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
> 




--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html