[Robert Collins, 2011-01-06]
2011/1/6 Piotr Ożarowski pi...@debian.org:
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
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 then
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)
2011/1/6 Piotr Ożarowski pi...@debian.org:
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
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 both
On Thu, Jan 6, 2011 at 12:39 PM, Barry Warsaw ba...@python.org 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
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 1:14 PM, Barry Warsaw ba...@python.org 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
[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 select
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
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
So in the thread 'Python packaging, dependencies, upstream facilities'
we had a brief talk that faded out; rather than resurrecting the
entire thread, I'd like to pick one point that seems like a necessary
condition to me: installing the eggs in versioned paths rather than
simple module paths.
12 matches
Mail list logo
