On Sep 21, 2010, at 10:30 AM, Piotr Ożarowski wrote: >[Robert Collins, 2010-09-20] >> Path to a solution: use an API marker analgous to the ABI markers C >> libraries have. Incompatible changes to a package bump the package >> *name*. e.g. >> python-zope.publication2.3 to python-zope.publication2.4 >> Compatible changes don't: >> python-zope.publication2.3-2.3.0ubuntu0 to >> python-zope.publication2.3-2.3.1ubuntu0 > >Gustavo does something like this with CherryPy (python-cherrypy and >python-cherrypy3 conflict with each other due to the same namespace, >though). I maintain python-jinja and python-jinja2 but my upstream >*did* change module name after breaking API (I will remove python-jinja >after releasing Squeeze). Of course, this happens all the time. Witness unittest2, distutils2, urllib2, httplib2 and the list goes on. It's ugly and inconvenient, but in many ways easier to manage and at least we *understand* how it works! >I'm not sure we should try to solve this. IMHO we should try to >convince upstreams that breaking API/ABI so often is a bad thing >instead. Good luck. :) >Please note that: >* 3rd party Python module authors break API or ABI a lot, and I mean > A LOT (sic!). Even if we'll just Provide: python-foo-API, that will > produce a lot of new virtual packages and a lot of confusion, >* something as simple as changing --install-lib causes many Python > modules to break (hardcoded paths, things like > `os.path.join(os.path.dirname(__file__), '..', '..', 'share', > 'foo')`, etc.) so playing with sys.path will require patching even > more files, >* adding new source package (which is the easiest way to support one > more upstream version at the same time) requires going thru NEW which > would make ftp-masters very unhappy (dozens of NEW packages every > month), >* maintaining 2 versions of the same module means twice as many work >for > both Debian maintainer and security team >* ... > >I see only one sane way to fix the problem - changing Python >interpreter to recognize API from filenames, like foo.1.py foo.2.py >foo.2.3.py (with `import foo <= 2` as valid syntax) and let upstream >authors decide when to bump it, just like C guys do, but that's a >topic for python-devel mailing list... It would be, but I'm skeptical. In general, libraries tend to come in (Python) packages these days and you're generally not going to mix APIs in files within the same package, unless the package is itself managing multiple APIs. It might be something that distutils2 can attack, either through its metadata files or by encoding the API in package directory names. -Barry
Attachment:
signature.asc
Description: PGP signature