[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 11:53 AM 11/23/2005 +1100, David Arnold wrote:
>-->"Phillip" == Phillip J Eby <pje at telecommunity.com> 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.