Josselin Mouette wrote: >>>Again, the ability to distribute it as a single package is good, >> >>What "single package" are you talking >>about? http://turbogears.org/download/ lists eggs and source packages for >>*10* different Python projects that it depends on, written by five >>different authors. Each is individually packaged, with eggs for Mac and >>Windows, and source packages that can build eggs for everything else. > > > You're reinventing the wheel. Really. This isn't a matter for the > Windows world, as users are accustomed to various, broken tools to > install stuff, and this one will probably be less broken than others. > But MacOS and Linux distributions already have a unified packaging > system, and I don't think it's useful to invent another package type, > especially if it's only suitable for Python.
I haven't followed this entire thread. But I'll chime in here: I'm an Egg consumer, and I want Egg features. Some Python software I've built *requires* eggs right now (Paste), some will require them in the near future (SQLObject -- at least with the full featureset). This isn't just dependency information, but the additional metadata Eggs allow for (entry points specifically). I do not know of any similar system for Python plugins. I'm at least passingly familiar with a lot of Python code, and I haven't seen a plugin system that doesn't suck in comparison. If you patch my projects and remove the dependency checks, I won't care that much (though it might be a nuisance); but if the Egg metadata goes away, the projects will be broken. So, perhaps in contrast to Phillip, I'll go further and say that Debian must support Eggs if it is going to package the software I'm writing (SQLObject, FormEncode, Paste), because if it doesn't then... well, then it will just be broken -- if not right away then soon -- and that's not a very good package then, is it? I think the same goes for TurboGears and maybe Trac. No one is forcing Debian to package any of these. I'd like it if Debian did contain some of these packages. But if that means that someone isn't willing to upgrade to SQLObject 0.8 because they have SQLObject 0.7 installed and Debian hasn't packaged 0.8, then I think the Debian packages have become pointless and even counterproductive. And that happens frequently, at least for developer libraries (as opposed to fully encapsulated applications). As to the question of what new things Eggs provide: Eggs -- putting aside the dependency checking -- solve a problem that is currently handled (from what I can tell) with a variety of ad hoc policies in Debian. An example might be, say, /etc/emacs/site-start.d, where a package that provides something puts a file in a well-known directory, and a package that consumes something looks in that directory. However, extra policy is not required for new consumers and producers using Eggs, as the tools all take that into account. So Eggs reduce the work a maintainer has to go through to adapt these kinds of systems to Debian. So, using TurboGears as an example, TurboGears will be able to see extensions provided by other packages, without any special effort. Back to dependency checking... Eggs also provide a cross-platform way to handle installation and dependencies. I use Debian, but a majority of the people using my software don't, and even I don't use it exclusively. I can't maintain Debian-specific data. However, I don't see why there's this resistence to map the data I maintain upstream directly to the Debian package data. You should see the duplication as a positive feature. But it should also go both ways -- it can be painful to do development on Debian because you reach a comfortable state, until the available Debian packages don't fit your needs for some reason, and then you have to abandon those packages and create a whole separate set of installed software. But if Debian packages provide the Egg metadata, then it will be much more reliable and comfortable to install updated versions of just a few libraries without using a Debian package. I don't develop my software as Debian packages. I don't think anyone does development like that. I use a variety of software, in a variety of versions, with some of the stable bits (e.g., MySQLdb) installed as Debian packages. I'd rather not step on the toes of installed packages, but I also want a development environment that tracks the projects I care about. Maybe you are just saying that Debian packages are unsuitable for software development. Maybe that is true; is that what you've decided? If so, then perhaps many of these projects simply shouldn't be packaged at all. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
