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
>
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 r
2009/7/15 Chris McDonough :
> 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 the
> folks w
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 "recreat
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
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 official
On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau
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 0.4 in the
first p
2009/7/15 P.J. Eby :
> 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* im
2009/7/15 P.J. Eby :
[...]
> 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 setuptools did addre
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 a
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 do
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?
Ob
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 possib
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 suppor
On Wed, Jul 15, 2009 at 5:16 PM, Joachim König 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 of
2009/7/15 David Cournapeau :
> 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 work around lac
On Wed, Jul 15, 2009 at 11:00 PM, Tarek Ziadé wrote:
> On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore 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
On Wed, Jul 15, 2009 at 5:14 PM, Paul Moore wrote:
> 2009/7/15 Tarek Ziadé :
>> On Wed, Jul 15, 2009 at 12:17 PM, Michael
>> Foord 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 ag
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 d
2009/7/15 Tarek Ziadé :
> On Wed, Jul 15, 2009 at 12:17 PM, Michael
> Foord 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 virtualen
On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foord 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 site-packages fr
On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore 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 methods to
> the
Paul Moore wrote:
2009/7/15 Tarek Ziadé :
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumar 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 does not support
ins
2009/7/15 Tarek Ziadé :
> On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
> Ratnakumar 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 does not support
>> installation
24 matches
Mail list logo
