[Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

Sridhar Ratnakumar SridharR at activestate.com
Wed Jul 15 19:52:09 CEST 2009


On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau <cournape at gmail.com>  
wrote:

>> if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
>> shipped with it.
> As was stated by Debian packagers on the distutils ML, the problem is
> that docutils 0.5 breaks packages which work with docutils 0.4 in the
> first place.

Thus I am -1 on multi-version support .. and would rather have the python  
developers make their packages backward compatible just like what Armin  
did with Jinja and Jinja2. Debian at the moment has only one package  
"python-docutils" which is 0.5. How is a debian application supposed to  
depend upon 0.4? With Jinja, there is no problem .. there are  
'python-jinja' and 'python-jinja2'. Similarly, CherryPy should have gone  
with renaming their package names to CherryPy2 and CherryPy3.

-srid


PS: Quoting from a fellow developer:

> > [...] it sounds like CherryPy 3.x is really an incompatible
> > module that just kept the old name. That is rather unfortunate, but can
> > sometimes happen.
>  I have never seen a Python package changing its name (when significantly
> changing API, design, etc..). The only exception that comes to my mind
> is Jinja2 (renamed from 'Jinja'):
>  [Armin] (...) Because we love backwards compatibility these changes will
> go into a package called "jinja2"
> <http://lucumr.pocoo.org/2008/4/13/jinja2-making-things-awesome>

Well, congrats to the Jinja team then!  The others will eventually learn...
Mixing incompatible APIs in a single namespace and using a non-standardized
version numbering system to keep things apart creates a world of pain!

> The challenge however is in compartmentalizing versions according to
> their major release numbers. Versioning in the Python world is already a
> mess which we are beginning to sort out:
> http://wiki.python.org/moin/Distutils/VersionComparison (PyPM relies on
> this standard and the ongoing implementation - verlib.py)

How embarrassing for a cult that prides itself on having only one way for
everything they do...   CPAN versions numbers are just as much if not
more of a mess, but at least you can argue that it is the price for there
being "more than one way to do it".


More information about the Python-Dev mailing list