Re: [Distutils] formencode as .egg in Debian ??
At 09:30 AM 11/25/2005 +1100, David Arnold wrote:
-->"Phillip" == Phillip J Eby <pje@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.
Reply to: