-->"Phillip" == Phillip J Eby <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
