P.J. Eby wrote:
At 05:16 PM 7/15/2009 +0200, Joachim König wrote:
f you have m different versions of n packages then
you could have n**m different combinations for an application so you
need a
possiblilty to select one combination from n**m possible ones at
application
startup time. Is this
Joachim König wrote:
So one would have to set up the application specific packages before
running the application, but the
whole clutter of uncounted versions of the same package in one directory
could go away. The
drawback of this approach would be, that the same version of a package
would
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumarsridh...@activestate.com wrote:
Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP
Paul Moore wrote:
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumarsridh...@activestate.com wrote:
Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)
Multiple versions:
On Wed, Jul 15, 2009 at 12:10 PM, Paul Moorep.f.mo...@gmail.com wrote:
Disclaimer: I've only read the short version, so if some of this is
covered in the longer explanation, I apologise now.
Next time I won't put a short version ;)
PEP 376 support has added a requirement for 3 additional
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foordfuzzy...@voidspace.org.uk wrote:
Disclaimer: I've only read the short version, so if some of this is
covered in the longer explanation, I apologise now.
-1.
I agree. People with versioning issues *should* be using virtualenv.
Let's remove
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foordfuzzy...@voidspace.org.uk wrote:
Disclaimer: I've only read the short version, so if some of this is
covered in the longer explanation, I apologise now.
-1.
I agree. People with versioning issues
Tarek Ziadé wrote:
So basically site-packages is a distribution location that is
avoided by everyone because it doesn't
know how to handle multiple versions.
I think you overrate the importance of having multiple versions of a
package available
for the same python interpreter. If you have m
On Wed, Jul 15, 2009 at 5:14 PM, Paul Moorep.f.mo...@gmail.com wrote:
2009/7/15 Tarek Ziadé ziade.ta...@gmail.com:
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foordfuzzy...@voidspace.org.uk wrote:
Disclaimer: I've only read the short version, so if some of this is
covered in the longer
On Wed, Jul 15, 2009 at 11:00 PM, Tarek Ziadéziade.ta...@gmail.com wrote:
On Wed, Jul 15, 2009 at 12:10 PM, Paul Moorep.f.mo...@gmail.com wrote:
Disclaimer: I've only read the short version, so if some of this is
covered in the longer explanation, I apologise now.
Next time I won't put a
2009/7/15 David Cournapeau courn...@gmail.com:
As was stated by Debian packagers on the distutils ML, the problem is
that docutils 0.5 breaks packages which work with docutils 0.4 in the
first place.
http://www.mail-archive.com/distutils-...@python.org/msg05775.html
And current hacks to
On Wed, Jul 15, 2009 at 5:16 PM, Joachim Königh...@online.de wrote:
Tarek Ziadé wrote:
So basically site-packages is a distribution location that is
avoided by everyone because it doesn't
know how to handle multiple versions.
I think you overrate the importance of having multiple versions
At 11:10 AM 7/15/2009 +0100, Paul Moore wrote:
I propose that before the current prototype is turned into a final
(spec and) implementation, the PEP 302 extensions are extracted and
documented as an independent protocol, purely part of PEP 376. (This
*helps* implementers, as they can write
At 04:14 PM 7/15/2009 +0100, Paul Moore wrote:
Look - I really, really don't mind if people use setuptools. Honest.
But I do mind if core python gets changed to support little bits of
what setuptools does, adding complexity to deal with issues that
setuptools handles, but without making it
At 05:16 PM 7/15/2009 +0200, Joachim König wrote:
f you have m different versions of n packages then
you could have n**m different combinations for an application so you need a
possiblilty to select one combination from n**m possible ones at application
startup time. Is this really worth it?
At 04:59 PM 7/15/2009 +0100, Paul Moore wrote:
- Virtualenv isn't a workaround (I don't know virtualenv, I'll take
your word for it)
It's not one for system package maintainers because it would
effectively be managing multiple instances of 'python'. Really not a
suitable solution.
- I
On Wed, 15 Jul 2009 at 16:14, Paul Moore wrote:
Bluntly, as Python stands, import and sys.path do not offer any core
support for multiple versions. Custom solutions can be built on top of
that - that's what setuptools does. But they are precisely that -
custom solutions, and should be supported
2009/7/15 P.J. Eby p...@telecommunity.com:
[...]
So if politics demands that it be rejected by association with setuptools,
then just search-and-replace the API, PEP 8-ify it, call it something
different, and lie to everyone about where it came from. I won't tell if
you won't. ;-)
While
2009/7/15 P.J. Eby p...@telecommunity.com:
At 11:10 AM 7/15/2009 +0100, Paul Moore wrote:
I propose that before the current prototype is turned into a final
(spec and) implementation, the PEP 302 extensions are extracted and
documented as an independent protocol, purely part of PEP 376. (This
On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau courn...@gmail.com
wrote:
if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
shipped with it.
As was stated by Debian packagers on the distutils ML, the problem is
that docutils 0.5 breaks packages which work with docutils
At 07:07 PM 7/15/2009 +0200, Tarek Ziadé wrote:
Part of the rejection of setuptools is because of that and
because you don't
bless anyone to maintain the project code base, or do releases,
neither to communicate clearly
on what's its roadmap.
Jim Fulton and Ian Bicking have been
At 06:40 PM 7/15/2009 +0100, Paul Moore wrote:
And of course, someone has to do the clean-up. It seems to me that the
fact that people are more inclined to reinvent the code than to try to
understand the existing codebase and pick out the relevant bits, says
something important about how easy it
I've been trying to follow this discussion now for weeks. The signal to noise
ratio is pretty low.
I'd love to have an stdlib solution for distribution packaging and installation.
But I think we might as well pack it up and go home if the folks whom are
contributing to the discussion
2009/7/15 Chris McDonough chr...@plope.com:
I've been trying to follow this discussion now for weeks. The signal to
noise ratio is pretty low.
I agree :-(
I'd love to have an stdlib solution for distribution packaging and
installation. But I think we might as well pack it up and go home if
24 matches
Mail list logo
