[Robert Collins, 2011-01-06]
> 2011/1/6 Piotr Ożarowski :
> This issue exists with C libraries too, but its not forbidden. Why
> should C libraries be expected to permit this, but not Python
> libraries?
C libraries are linked at build time, Python libraries at runtime and
C libraries do not suffe
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
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
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
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
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
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
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
On Mon, Jan 3, 2011 at 9:12 PM, Piotr Ożarowski 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 p
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 availa
[Robert Collins, 2011-01-03]
> whats the simplest way to install this somewhere else - e.g.
> /usr/share/pyshared/wadllib-1.1.4
> and have
> import wadllib
> still work without user intervention.
>
> Two options seem to present themselves to me at the moment:
> - the pyshared symlink logic could
11 matches
Mail list logo
