On 9 October 2011 20:47, Tarek Ziadé <ziade.ta...@gmail.com> wrote: > On Sun, Oct 9, 2011 at 9:31 PM, PJ Eby <p...@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". _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com