Re: [Distutils] formencode as .egg in Debian ??
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 | ianb@colorstudy.com | http://blog.ianbicking.org
Reply to: