At 11:53 AM 11/23/2005 +1100, David Arnold wrote:
-->"Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
Phillip> This is a major advantage over developers who do not do this,
Phillip> not only in developer effectivness, but also because a
Phillip> developer who depends exclusively on a specific packaging
Phillip> system will not have the same effective reach for their
Phillip> offering, or conversely will require a greater investment of
Phillip> effort to support various packaging systems.
<coming to this a little late>
So, this would seem to imply that installation of eggs is similar to
using PEAR or CPAN?
Not at the level I think you mean. Apart from the .pth file, and any
scripts, each egg has its *own*, 100% encapsulated file or directory, for
example, which is quite different from at least CPAN. (I don't know
anything about PEAR.)
One thing in particular is significantly different: eggs have runtime
discovery and introspection of metadata and dependencies. It would be more
appropriate to compare them with Eclipse plugins or "OSGi bundles" for
Java. (These are an enhanced jar format with dependency information,
version info, platform metadata, etc.)
Adding a language-specific mechanism simply causes problems, with stray
files installed into directories "owned" by a .deb package, versions of
CPAN/PEAR-installed packages drifting out of date with the interpreter
and standard library, and just the cognitive load of needing to deal
with something other than apt-get.
Eggs cannot overwrite each other's contents, or indeed anything else other
than scripts (which can be directed to individual package directories ala
Stow if you prefer). Eggs carry the Python version number they are built for.
In addition, eggs do not have to be installed in system library
directories; an application can simply dump all its eggs and its main
script in a single directory, and then run from there without relying on
system packages at all. The egg runtime identifies which versions of which
eggs are needed to satisfy the dependencies when the script runs.
My experiences with CPAN/PEAR
packages have been universally bad, and I now try very, very hard to use
nothing except apt/dpkg.
That's certainly understandable, but comparison with CPAN is definitely
inappropriate, since many of the issues that can exist with CPAN (or the
bare distutils in Python's case) simply cannot exist with .egg files and
directories. For example, even if a user ran easy_install as root and
installed a new version of a package, the older .egg would still remain on
the system, and none of the files in the new egg would overwrite the older
egg's files, since eggs are installed as either a zipfile or directory,
named for the package/version/python-version/platform. (Note, by the way,
that this means you can actualy install .eggs for multiple architectures in
the same directory and get away with it.)
Let's say the user installed SomeEgg-1.2, replacing the system-installed
SomeEgg-1.1. If they want to put things back the way they were, they need
only run "easy_install SomeEgg==1.1", which will find the still-untouched
SomeEgg-1.1 sitting where it always was, and this will rewrite the .pth
file to make SomeEgg-1.1 the active version again. Meanwhile, whatever
program the user installed that needed SomeEgg-1.2 will most likely
continue to work, as long as it's using the egg dependency machinery to get
at it.
Of course, the user who's installing some program that needs newer packages
than are offered by the packaging vendor can simply designate another
installation directory, and tell EasyInstall to put any new eggs and
scripts there, instead of adding them to the main system. They are then
nicely isolated from any system-level changes.
I understand that from a Python-only perspective eggs might have a bunch
of ease-of-use advantages, but from my point of view I'd suggest it's
better that the developer (or Debian packager) takes the trouble to make
it work with dpkg so all Debian users get to maintain the consistency
they're used to.
Which is all very well and good, except there are plenty of packaging
systems besides Debian, and platforms that don't even have anything
resembling a packaging system. (And likely plenty of Python developers
who've never heard of Debian, and a larger number who've never used it.)
In any case, the current discussion is more about the issue of providing
metadata so that Python developers can *tell* when the packaging system
provides a usable version of something, without having to write tools for
every packaging system in existence. Providing the .egg-info directory
with Debian-installed packages is a reasonable solution for offering
system-provided packages, but without using the .egg file/directory
formats. (The irony here is that the solution perceived as more desirable
here, is the one that *requires* the package maintainers to avoid
inter-project conflicts, whereas the "default" format for eggs avoids such
issues almost entirely!)
As far as the benefits or lack thereof of Debian itself, I certainly can't
say. However, having had to administer boxes with the RPM and pkgsrc
systems, I would say that eggs are immensely superior for the Python
developer, and I doubt that Debian has any features that would sway me on
that point if I did use it. Just the ability to have SomeEgg-1.1 and
SomeEgg-1.2 simultaneously available is a lifesaver, from my perspective.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
