Le dimanche 27 novembre 2005 à 13:30 -0600, Ian Bicking a écrit : > > 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. As I understand it, dependencies and generic metadata are two slightly different features that come together with eggs. While the latter is merely an annoyance for us, the former is a nice feature, even if I dislike the implementation. > 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. Removing the dependency checks entirely and replacing them with Debian dependencies is definitely an option, and I happen to prefer it slightly to the necessity of adding empty .egg-info files to all python module packages. > 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. Of course you are forcing Debian to package these. As long as your projects have enough users, someone will want to build a Debian package. The whole point of this thread is to make this package not suck. > 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). I'm happy you see stable releases as "counterproductive". However many of our users happen to like them, as they don't like to upgrade their software every other day. Again, eggs are a useful tool only for developers, not for regular users. > 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. This is slightly different from dependencies. It seems weird to use the same framework to bring both features. > 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. It is not possible to do it automatically - not in a reliable way. > 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 fail to see how it changes anything. If it's to be able to install two versions of the same package at once, I have already explained why it's a bad idea to even support it. > 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. It should be obvious Debian packages aren't useful for the development of the packages themselves. They are a way to install software in an easy and generic way for our users. If your software isn't useful to anyone else than the people developing it, it should indeed not be packaged for Debian. Regards, -- .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=