Re: coming back to packaging multiple versions of libraries

2011-01-05 Thread Robert Collins
On Thu, Jan 6, 2011 at 1:14 PM, Barry Warsaw wrote: > On Jan 06, 2011, at 12:45 PM, Robert Collins wrote: > >>I'm not trying to do this in a hidden way though? Why do you think >>that that is the case? > > Sorry, I meant "automatic". I'm not proposing anything magical: maintainer intent will alwa

RFS: marave

2011-01-05 Thread Gildardo Adrian Maravilla Jacome
Dear mentors, I am looking for a sponsor for my package "marave". * Package name: marave Version : 0.7-1 * URL : http://code.google.com/p/marave/ * License : gpl2 Section : editors It builds these binary packages: marave - Full screen editor writte

Re: coming back to packaging multiple versions of libraries

2011-01-05 Thread Barry Warsaw
On Jan 06, 2011, at 12:45 PM, Robert Collins wrote: >I'm not trying to do this in a hidden way though? Why do you think >that that is the case? Sorry, I meant "automatic". -Barry signature.asc Description: PGP signature

Re: coming back to packaging multiple versions of libraries

2011-01-05 Thread Robert Collins
On Thu, Jan 6, 2011 at 12:39 PM, Barry Warsaw wrote: > These are not necessarily mutually exclusive. ;) #3 and #4 are both worth > pursuing in any case, but kind of outside the domain of either upstream > (except were the stdlib is concerned) or debian-python.  Still, as a Python > programmer, if

Re: coming back to packaging multiple versions of libraries

2011-01-05 Thread Barry Warsaw
On Jan 05, 2011, at 11:40 PM, Piotr Ożarowski wrote: >IMHO installing two versions of the same (public) Python module should >be simply forbidden in policy. For one simple reason: if module foo uses >bar in version 1 and spam uses bar in version 2, imagine what will >happen with egg which uses bot

Re: coming back to packaging multiple versions of libraries

2011-01-05 Thread Robert Collins
2011/1/6 Piotr Ożarowski : > IMHO installing two versions of the same (public) Python module should > be simply forbidden in policy. For one simple reason: if module foo uses > bar in version 1 and spam uses bar in version 2, imagine what will > happen with egg which uses both foo and spam. This i

Re: coming back to packaging multiple versions of libraries

2011-01-05 Thread Piotr Ożarowski
IMHO installing two versions of the same (public) Python module should be simply forbidden in policy. For one simple reason: if module foo uses bar in version 1 and spam uses bar in version 2, imagine what will happen with egg which uses both foo and spam. Right now I see only these options: 1) cr

Re: coming back to packaging multiple versions of libraries

2011-01-05 Thread Barry Warsaw
On Jan 04, 2011, at 07:30 AM, Robert Collins wrote: >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 th