[Distutils] formencode as .egg in Debian ??

[Phillip J. Eby]

At 09:30 AM 11/25/2005 +1100, David Arnold wrote:
>-->"Phillip" == Phillip J Eby <pje at telecommunity.com> writes:
>
>   Phillip> Python developers would *love* to have Debian manage their
>   Phillip> packages, they would simply like to be able to verify at
>   Phillip> runtime that the management has in fact been done.  It's not
>   Phillip> that we don't trust you, it's just that we're paranoid.  :)
>
> From a Debian perspective, that's strictly your own affair.  Debian
>packages "just work", and if they don't it's a bug.  There's no need for
>anyone other than the packager to worry about this.

And if we were Debian developers rather than Python developers, this would 
be a sensible approach to take.  As a practical matter, we have to worry, 
because our users aren't strictly Debian users, and asking them all to move 
to Debian isn't practical for most of us.  ;)

Let me ask you this: does Debian ban people from putting $id$ strings in C 
code to allow identifying the version of the source that was used to build 
a library or executable?  Because that's what *exactly* what we're talking 
about here in respect to dependencies, just for Python code instead of C.


>   Phillip> We'd like for Debian to advertise to our packages, precisely
>   Phillip> what versions of which of our dependencies are installed.
>
>In general, I don't see why packages should care.  Either it works, in
>which case there's no problem, or it doesn't, in which case it's a
>packaging bug, and it will be fixed.

But we can't tell if it's a packaging bug, or a bug against what version of 
our dependencies, unless we know what version the user is running.  Given 
that sys.path can include *both* Debian system packages and local 
user-installed packages, we need a more comprehensive way of dealing with 
the issue, which is what eggs provide.


>Supporting the installation and simultaneous use of multiple versions
>seems to be a goal of eggs?

Absolutely.


>   FWIW, that's kinda heretical on Unix (which
>might explain some of the antipathy).

The Python approach is "Practicality Beats Purity", which I thought was 
also a Unix value.


>   Phillip> We'd also like for Debian to include the metadata we provided
>   Phillip> with our packages, when it installs them.
>
>It think that's a reasonable expectation.  So long as Python packages
>are location-agnostic, and allow Debian to put such things where it
>thinks is reasonable?

As long as it can be found by the package, without needing any special 
configuration.  Python packages are looked up relative to sys.path, so it's 
reasonable to expect to find the metadata on sys.path as well, preferably 
at a fixed location relative to the code.


>   Phillip> And we'd like all this to cleanly work with any
>   Phillip> locally-installed non-Debian eggs that might be in the mix,
>   Phillip> since we need to do development, beta testing, etc.
>
>And non-egg packages as well, right?

There isn't any such thing, from an egg developer's perspective.  Any 
distutils package can be made into an egg, because all of the metadata 
needed is supplied by the standard distutils setup script.  So, if you have 
the source, you can make it an egg.

With respect to the whole "Dependencies are a solved problem" thing, you're 
beating a dead horse.  I freely admit you can manage *system* dependencies 
better.  But that's only *part* of an application developer's 
problem.  That's no critique of your efforts, only a recognition of their 
scope.  For example, it doesn't help somebody developing a package while 
using Subversion-head versions of three other packages.  It doesn't help 
Windows users.  There's a whole bunch of things it just doesn't help with, 
that eggs do.

That doesn't mean you should change Debian to eggs, because eggs aren't 
trying to solve the problems that you guys solve either.  But if you'd like 
for your system packages of Python project *not* to have to be duplicated 
as separately distributed eggs, then we need to have some dependency info, 
so that your packages can play in those areas where you *aren't* providing 
a complete solution, but *can* provide a part of it.

Thus, maybe the issue for some is that supplying the dependency information 
would be an admission that there really *are* problems Debian doesn't 
solve, as opposed to "merely" helping with.