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

[Éric Araujo]

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
- packaging.database can read egg/PKG-INFO (zipped and unzipped) and
egg-info files
- packaging.install can detect that a project uses a setup.py with
setuptools, run that setup.py, and convert egg-info to dist-info

>  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 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.
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