Robert brings this up every time I see him. :) I'm glad we're still talking about it; while I'm sympathetic to the use case, it just seems like a problem fraught with difficulties. One question is whether the entire Debian packaging system knows that there are multiple versions of a package available, and how it handles that. Note that this happens in other cases and AFAIK it's always resolved by including the version number in the package name (gir1.0/gir1.2 comes to mind). So, would you have packages python-wadllib1.1.4 and python-wadllib1.2 in the archive? That's going to get pretty unwieldy as a general policy. Or maybe all supported versions of wadllib get installed when you install python-wadllib, but then packages get bigger and the Debian maintainer still has to manage the complexity of multiple versions (e.g. when can you drop wadllib 1.1.4?). We see similar solutions in the Python world, what with unittest2, httplib2, and so on (heck, even Python3 ;). These are usually reserved for more severe and deliberate API breaks, such as rewrites. Unfortunately, we usually have to live with the ugly module names forever. Piotr makes other good points, so just a few additional comments. On Jan 03, 2011, at 09:12 AM, Piotr Ożarowski wrote: >teach upstream about the importance of stable API (yeah, I know Python >programmers do not care about it much, it could be worse¹, though) Not all upstreams are bad at this, or perhaps a better way of saying this is that many are good at maintaining stable APIs. It's not really a Python thing, since the quality, stability, and guarantees of Python libraries probably run the gamut as much as libraries in any other language (<cough> BerkeleyDB </cough>). The standard library strives for this with stated policy (PEP 387) but it's tricky. For example, sometimes you have to forego a bug fix because the only way to fix it properly is to break the API. You can sometimes play tricks (e.g. add optional args to the end of the parameters, or a parallel function) but you have to have backward compatibility as a firm principle of your software development. I do think that if a library you care about breaks compatibility, you should file bugs and be tenacious about them. In wadllib's case, you know the developers and might even have write permissions to the tree. :) The stdlib is made more difficult IMO by the batteries-included philosophy. Meaning, individual modules generally lose their own identifiable versioning when pulled into the stdlib, and only get multiple versions for deliberate major breaks described above, e.g. we ship both urllib and urllib2. >You could also provide wadllib/__init__.py file which will modify >__path__ to point to the newest installed versions (and f.e. check for >WADLIBVERSION env. variable if someone doesn't want the newest version) >but it's an ugly hack and could cause more harm than good, IMHO. Agreed. It would be more useful for the wadllib developers to work harder at keeping a stable API between minor versions. If the API breaks, bump the major version number. Then the distros can do all the difficult work of analyzing dependencies, and deciding when and how to transition to the new version. This happens all the time. Don't give up though Robert! I think the problem is bigger than just Python, but if anyone can come up with some innovative ideas that could work, you can! -Barry
Attachment:
signature.asc
Description: PGP signature