Re: [Distutils] formencode as .egg in Debian ??
-->"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.
Phillip> And if we were Debian developers rather than Python
Phillip> developers, this would be a sensible approach to take. As a
Phillip> practical matter, we have to worry, because our users aren't
Phillip> strictly Debian users, and asking them all to move to Debian
Phillip> isn't practical for most of us. ;)
Yep, I understand that totally.
Phillip> Let me ask you this: does Debian ban people from putting $id$
Phillip> strings in C code to allow identifying the version of the
Phillip> source that was used to build a library or executable?
No.
Phillip> Because that's what *exactly* what we're talking about here
Phillip> in respect to dependencies, just for Python code instead of
Phillip> C.
So, if a system package, shipped by the upstream developer as an egg, is
"unpacked" into a directory structure, and its metadata is maintained
in a .egg-info file somewhere in sys.path, non-system eggs will have all
they need to operate correctly?
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.
Phillip> But we can't tell if it's a packaging bug, or a bug against
Phillip> what version of our dependencies, unless we know what version
Phillip> the user is running.
So that's another goal of eggs? To provide information to a package
maintainer to assist in determining if it's the user's PYTHONPATH or
.pth files that are causing a bug?
I can see this would be helpful. But Debian won't tell you that (as you
said you'd like, above).
Phillip> Given that sys.path can include *both* Debian system packages
Phillip> and local user-installed packages, we need a more
Phillip> comprehensive way of dealing with the issue, which is what
Phillip> eggs provide.
I can see that this is *nice*; I'd debate "need". But I'm happy to
accept that for egg-based stuff, this is a nice feature.
>> Supporting the installation and simultaneous use of multiple
>> versions seems to be a goal of eggs?
Phillip> Absolutely.
>> FWIW, that's kinda heretical on Unix (which might explain some of
>> the antipathy).
Phillip> The Python approach is "Practicality Beats Purity", which I
Phillip> thought was also a Unix value.
I'm not going to try to assert "Unix values" here. My observation is
that historically, Unix has installed things into one of a couple of
directory hierarchies (/usr, /usr/local, /opt). Within those
hierarchies, there has been scope for only one version of any given
thing.
This is ok because developers take care to maintain API compatibility at
the source level, at least, and ABI compatibility if they're well
behaved.
If you need to break compatibility, it's normally done by renaming the
new verion (ie. gtk vs gtk2).
Without going into the merits of this, it's my observation that this has
been the in-practice approach (and you can draw whatever philosophical
"Unix values" you like from that).
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?
Phillip> There isn't any such thing, from an egg developer's
Phillip> perspective.
Really? So if I use one egg, everything has to be an egg?
Phillip> Any distutils package can be made into an egg, because all of
Phillip> the metadata needed is supplied by the standard distutils
Phillip> setup script. So, if you have the source, you can make it an
Phillip> egg.
What if I don't have the source (or setup.py) ?
Phillip> That doesn't mean you should change Debian to eggs, because
Phillip> eggs aren't trying to solve the problems that you guys solve
Phillip> either.
It seems to me that it's likely Debian will need to cope with eggs.
Phillip> But if you'd like for your system packages of Python project
Phillip> *not* to have to be duplicated as separately distributed
Phillip> eggs,
I personally would appreciate that not being the case
Phillip> then we need to have some dependency info, so that your
Phillip> packages can play in those areas where you *aren't* providing
Phillip> a complete solution, but *can* provide a part of it.
That seems reasonable.
Accepting that there will be parallel (I hesitate to say "competing")
systems, and that keeping them in sync is both hard and necessary seems
to be the open issue.
Phillip> Thus, maybe the issue for some is that supplying the
Phillip> dependency information would be an admission that there
Phillip> really *are* problems Debian doesn't solve, as opposed to
Phillip> "merely" helping with.
I don't perceive that to be the issue (but perhaps I'm wrong).
d
Reply to: