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

Éric Araujo merwok at netwok.org
Thu Oct 13 18:23:57 CEST 2011

Hi Philip,

[...] In any case, it definitely wasn't the case that eggs or setuptools were rejected for 2.5; they were withdrawn for reasons that didn't have anything to do with the format itself. Thanks for clarifying. I nonetheless remember strong opposition to pulling the code unmodified, from MvL IIRC.

(And, ironically enough, AFAIK the new packaging module uses code that's actually based on the bits of setuptools Fredrik was worried about supporting... setuptools presence in packaging is

but at least there now are more people providing that support.) Truth be told, I’m not sure it is so. The student who worked on packaging.database has not remained a member of our group; his mentor is also less active. But that’s not the hardest code in packaging. Regarding installation, we do have people with distribute knowledge and experience, so that’s good.

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. We’re not sure bdist_dumb is what we’re after—see my other messages.

Conversely, if you want a smarter format, why reinvent wheels? Recent packaging PEPs and distutils2 are all about reinventing wheels! Or rather standardizing best practices for wheels. Some ideas are taken near-identical from setuptools, other see great changes. In this case, we have to define our requirements, and if bdist_egg can work (as a distribution format, not an installation format!), then we may just take it. If it does not, we’ll have to make a new wheel.

Regards

More information about the Python-Dev mailing list