[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
(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