Re: [Distutils] formencode as .egg in Debian ??
Josselin Mouette wrote:
>>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.
This will make it harder for people who use additional non-packaged
Python libraries when they depend on packaged libraries.
>>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.
easy_install works, right now, for these packages. There are some
outstanding issues, and those issues can probably be resolved in
easy_install, without any intervention by Debian. Maybe the simplest
resolution is adding an option like:
easy_install --already-provided=1.2.6 ElementTree
that will create a .egg-info directory. And we can encourage people to
fix Debian by putting a distutils.cfg file in place that installs
distutil software in /usr/local by default, as opposed to the current
situation where I believe distutils installs go alongside Debian packages.
>>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.
These are developer tools, regular users *are* developers.
If someone reports a bug, and I fix it, and they can't get access to
that because they can't install a new version of the package, then that
is counterproductive. It discourages feedback.
>>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.
Then you are cutting off me, the upstream maintainer, from the users,
because everything has to go through the Debian packager, and a separate
release cycle. *Or*, we develop various ad hoc techniques to allow
people to install other versions of packages *in spite* of the Debian
packages.
I just don't think it is an option to say that only one version of a
package can be installed. In /usr/lib/pythonX.Y/site-packages, sure,
and there can potentially be other restrictions. But you are limiting
your users too much if there can never be multiple versions installed.
>>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.
This is where the whole thing becomes weird, IMHO. I'm a Debian user
(among several distributions). I'm also a developer. As such, the
Debian system doesn't work well for me. The system doesn't need to be
primarily targetted at my use case, but I think my use case at least
needs to be taken into account. Much of the software we are currently
talking about is primarily targeted at people like myself (the exception
would be Trac, though even that has a developer focus). This may change
at some point -- there might be useful applications that Debian users
want easy access to, and those applications in turn require one of these
libraries.
But right now it is Python programmers who are asking for these
packages. It's entirely valid to say that these libraries aren't ready
to become Debian packages; I'm not really arguing that they should.
*But*, Debian policy can make things easier or more difficult for Debian
users who are using Eggs, regardless of whether there are packages involved.
--
Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Reply to: