(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" <[EMAIL PROTECTED]> 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.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
