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

Michael Foord fuzzyman at voidspace.org.uk
Mon Oct 10 01:34:17 CEST 2011

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 bdistegg does and define a new bdist command inspired by it, but without zipping, pkgresource calls, etc.

Why? If you just want a dumb bdist format, there's already bdistdumb. 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 somebinaryformatfile.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, 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. 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 bdistdumb, 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

More information about the Python-Dev mailing list