On Mon, Jan 3, 2011 at 9:12 PM, Piotr Ożarowski <pi...@debian.org> wrote: > what's the point of installing two different versions of the same module > if only one will be used anyway? If the answer to that question is: > "in the application where I need different version, I will adjust > sys.path" - why not simply provide different version of the library as > private module? Security team will hate you anyway.
For the same reason we support libreadline5 and 6 : to transition higher level code without a flag day across the entire machine. Security team should not hate this any more or less than they do for C libraries, its for precisely the same reasons. >> I'm very interested in other approaches to make this work; > > teach upstream about the importance of stable API (yeah, I know Python > programmers do not care about it much, it could be worse¹, though) The best of intentions still sometimes leads to incompatible changes, but yeah, preach it :). > 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. I can see that breaking overly-clever packages, or things like the twisted splitup, bzrlib.plugins etc. I'd like to be minimally invasive. @Barry: yes, the C/C++/CLR/ library handling is precisely equivalent. I would expect only as many concurrent versions in the archive as we need to support. There are two use cases: - in sid, while transitioning an incompatible change - users using private packages with their own archive In the former case, we'd generally(1) drop an old version as soon as its rdepends(2) is empty. In the latter case, its up to the user to decide when they don't need a particular version. (1) Exceptions might occur if a maintainer feels that the package is extremely widely used outside of the packaging universe and wants to keep it available. (2) Figuring out rdepends sanely is another step to be taken, but I'm hoping to break this down far enough to get consensus on individual bits. It really does look like having better upstream facilities would make this a no-brainer for us; what I'd like to achieve though is something that /works/ for the existing python platform - for 2.7 which will be around a good long time, and then we'll have plenty of data to discuss with upstream. -Rob -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim7joembx_7nhtpb2mpkaq-9iiet7txbp8cp...@mail.gmail.com
