[Python-Dev] "setuptools has divided the Python community"
cournape at gmail.com
Wed Mar 25 17:16:29 CET 2009
On Thu, Mar 26, 2009 at 12:37 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Barry Warsaw wrote:
>> Maybe there's a difference between being a Zope user and using zope
>> packages? I think it's great that I can pick and choose
>> zope.interfaces and other packages in my not-Zope project. But if I'm
>> deploying actual Zope-the-web-thing I just want to install it from my
>> distro and be done with it. It's up to my distro to determine
>> compatibility, handle bug and security fixing, etc.
> Historically, the distros have done a less than stellar job here, too.
I don't think that's entirely accurate. For softwares which I don't
care directly as a developer, because I only use them, and don't
intend to change anything in it, the linux distribution is god's
heaven IMO. Being able to update, upgrade everything in a centralized,
predictable manner works very well.
It fails for software I am directly involved in, or maybe the layer
just below: for example, there is no way for me to get a python 2.6 on
my distribution (Ubuntu), so I cannot easily test the python projects
I am involved in for python 2.6. But for layers below, it is almost
perfect. If python, as a platform, could be as reliable as debian, I
would be extremely happy. I just don't think it is possible, because
of the huge amount of work this requires. Tools are just a small part
of it - you need a lot of discipline and work to make sure everything
fits together, and that can't happen for every python lib/application
I already mention this on the distutils ML, but IMO, the only workable
solution is to have a system which makes it *possible* for OS
distributors to package in whatever they see fit (.deb, .rpm, .dmg,
.exe, .msi). Distutils, as of today, makes it much harder than it is
for non trivial softwares (documentation, controlling what goes where,
etc...). That's something we can hope to improve. Again, I will take
the autoconf example: it has no policy, and can be used for different
kind of situations, because you can (if you want) control things in a
very fine-grained manner. Automatic, 'native' installers which are
well integrated into every system, this seems so far from reach I
don't see how this can even be considered.
More information about the Python-Dev