[Python-Dev] bdist_* to stdlib?

Phillip J. Eby pje at telecommunity.com
Tue Feb 14 20:53:37 CET 2006

(Disclaimer: I'm not currently promoting the addition of bdist_egg or any 
egg-specific features for the 2.5 timeframe, but neither am I 
opposed.  This message is just to clarify a few points and questions under 
discussion, not to advocate a particular outcome.  If you read this and 
think you see arguments for *doing* anything, you're projecting your own 
conclusions where there is only analysis.)

At 11:16 AM 2/14/2006 -0800, Guido van Rossum wrote:
>On 2/13/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > I'm actually opposed to bdist_egg, from a conceptual point of view.
> > I think it is wrong if Python creates its own packaging format
> > (just as it was wrong that Java created jar files - but they are
> > without deployment procedures even today).
>I think Jars are a lower-level thing than what we're talking about
>here; they're no different than shared libraries, and for an
>architecture that has its own bytecode and toolchain it only makes
>sense to invent its own cross-platform shared library format
>(especially given the "deploy anywhere" slogan).

Java, however, layers many things atop jars, including resources (files, 
images, messages, etc.) and metadata (manifests, deployment descriptors, 
etc.).  Eggs are the same.

To think that jars or eggs are a "packaging format" is a conceptual error 
if by "packaging format" you're equating them with .rpm, .deb, .msi, 
etc.  It is merely a convenient side benefit that .jar files and .egg files 
are convenient transport mechanisms for what's inside them - the jar or 
egg.  Jars and eggs are conceptual entities independent of the distribution 
format, and in the case of eggs there are two other formats (.egg directory 
and .egg-info tags) that can be used to express the conceptual entity.

> > The burden should be
> > on developer's side, for creating packages for the various systems,
> > not on the users side, when each software comes with its own
> > deployment infrastructure.
>Well, just like Java, if you have pure Python code, why should a
>developer have to duplicate the busy-work of creating distributions
>for different platforms? (Especially since there are so many different
>target platforms -- RPM, .deb, Windows, MSI, Mac, fink, and what have
>you -- I'm no expert but ISTM there are too many!)

Indeed.  Placing the burden on the developer's side simply means that it 
doesn't happen until volunteers pick it up, which happens slowly and only 
for "popular enough" packages.  Which means that as a practical matter, 
developers cannot release packages that depend on other packages without 
committing to some small set of target platforms and packaging systems -- 
the situation that setuptools was created to help change.

> > OTOH, users are fond of eggs, for reasons that I haven't yet
> > understood.
>I'm neutral on them; to be honest I don't even understand the
>difference between eggs and setuptools yet. :-)

Eggs are a way of associating metadata and resources with installed Python 
packages.  ".egg" is a zip or directory file layout that is one 
implementation of this concept.

Setuptools is a set of distutils enhancements that make it easier to build, 
test, distribute and deploy eggs, including the pkg_resources module (egg 
runtime support) and  the easy_install package manager.

>  I imagine that users
>don't particularly care about eggs, but do care about the ease of use
>of the tools around them, i.e. ez_setup.

And developers of course also care about not having to create those myriad 
installation formats, for platforms they may not even have.  :)  They also 
care about being able to specify dependencies reliably, which rules out 
entire classes of support issues and debugging.  It actually makes reuse of 
Python packages practical *without* unnecessarily tying the result to just 
one of the myriad platforms that Python runs on.  Some developers also like 
the plugin features, the ability to easily get data from their package 
directories, etc.

(Setuptools also offers a lot of creature comforts that the distutils 
doesn't, and some of those conveniences depend on eggs, but others do not.)

More information about the Python-Dev mailing list