[Distutils] RFC: Binary Distribution Format for distutils2/packaging

PJ Eby pje at telecommunity.com
Wed Mar 14 17:54:40 CET 2012


On Wed, Mar 14, 2012 at 11:17 AM, Jim Fulton <jim at zope.com> wrote:

> On Tue, Mar 13, 2012 at 11:00 PM, PJ Eby <pje at telecommunity.com> wrote:
> ...
> > I'm not sure what else you'll actually gain by introducing
> > a new format.  IIUC, what new-style metadata egg files lack can be
> > determined programmatically from their contents or the existing metadata
> > files, so there seems to be little reason not to at least consume
> existing
> > egg files.
>
> I'm not sure whether you're referring to the distribution format, or
> the meta-data format, or both.
>
> I don't really have an opinion, myself, about the meta data format.
> Other have decided it's going to be different. <shrug>
>
> Having decided to use a different meta data format, it makes sense to
> use a different
> distribution format.  While d2/p might support eggs for a while (not
> sure of that), we
> wouldn't want new distributions to be in egg format, so we need an
> alternative.
>
> (Personally, I don't have an issue with the egg format, but the decision
> was
> made by others to move away from it.)
>

In that case, I think it's really important to explicitly spell out the
requirements and use cases for the new format; different people use .egg
files differently, and the discussion here already reflects these different
perceptions.

The packaging PEPs cover only replacements for EGG-INFO/PKG-INFO and
EGG-INFO/requires.txt.  AFAIK, they don't include replacements for:

* entry_points.txt -- plugin discovery
* namespace_packages.txt -- namespace package management
* dependency_links.txt -- suggesting additional locations for finding
dependencies
* native_libs.txt, eager_resources.txt, zip-safe/zip-not-safe -- support
for in-zipfile access to resources and native libraries

Which of these use cases will be supported by the new format, and which
will not?  Dropping any of them essentially means that some people are not
going to have a migration path.   (PEP 382 or 402 will eventually clear up
the namespace_packages bit, but are unlikely to be backported to 2.x.)

Also, is there an official discovery API for finding additional metadata
(such as would be needed by EggTranslations' i18n system built on egg
metadata)?

I assume that you're aware of most of the above, as Zope has historically
made use of at least the first two items on the list above.  But a PEP for
this new format really ought to spell out the use cases it's going to
handle, or not, and why (or why not).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120314/d42e191d/attachment.html>


More information about the Distutils-SIG mailing list