[Distutils] How to force installing setuptools instead of distribute ?

[David Cournapeau]

Hi,

Ubuntu Lucid uses distribute instead of setuptools, and I cannot
manage to use setuptools with virtualenv because of this. I upgraded
to the last version of virtualenv, which claims to install setuptools
by default, but I still get distribute instead, and I would guess this
is because of Ubuntu using distribute, but who knows....

Is there a simple way to force virtualenv to install setuptools (the
PJE version, *not* the distribute fork) ?

cheers,

David

[P.J. Eby]

At 11:10 AM 7/1/2010 +0900, David Cournapeau wrote:
>Hi,
>
>Ubuntu Lucid uses distribute instead of setuptools, and I cannot
>manage to use setuptools with virtualenv because of this. I upgraded
>to the last version of virtualenv, which claims to install setuptools
>by default, but I still get distribute instead, and I would guess this
>is because of Ubuntu using distribute, but who knows....
>
>Is there a simple way to force virtualenv to install setuptools (the
>PJE version, *not* the distribute fork) ?

Have you tried requesting an exact version number of setuptools?
(e.g. setuptools==0.6c11 or setuptools==dev06)

(Distribute uses a hack of pkg_resources to pretend that it satisfies
requirements that specify "setuptools". However, I don't think it
fakes what *version* of setuptools it pretends to be.)

[David Cournapeau]

On Thu, Jul 1, 2010 at 11:23 AM, P.J. Eby <***@telecommunity.com> wrote:
> At 11:10 AM 7/1/2010 +0900, David Cournapeau wrote:
>>
>> Hi,
>>
>> Ubuntu Lucid uses distribute instead of setuptools, and I cannot
>> manage to use setuptools with virtualenv because of this. I upgraded
>> to the last version of virtualenv, which claims to install setuptools
>> by default, but I still get distribute instead, and I would guess this
>> is because of Ubuntu using distribute, but who knows....
>>
>> Is there a simple way to force virtualenv to install setuptools (the
>> PJE version, *not* the distribute fork) ?
>
> Have you tried requesting an exact version number of setuptools? (e.g.
> setuptools==0.6c11 or setuptools==dev06)

I have tried that, but easy_install considers it does not need it
because distribute has a version higher (0.6.13):

install_dir /home/david/src/rt_analytics/tmp/lib/python2.6/site-packages/
Searching for distribute
Best match: distribute 0.6.13
Processing distribute-0.6.13-py2.6.egg
distribute 0.6.13 is already the active version in easy-install.pth
Installing easy_install script to /home/david/src/rt_analytics/tmp/bin
Installing easy_install-2.6 script to /home/david/src/rt_analytics/tmp/bin

Using /home/david/src/rt_analytics/tmp/lib/python2.6/site-packages/distribute-0.6.13-py2.6.egg
Processing dependencies for distribute
Finished processing dependencies for distribute

> (Distribute uses a hack of pkg_resources to pretend that it satisfies
> requirements that specify "setuptools".  However, I don't think it fakes
> what *version* of setuptools it pretends to be.)

Yes, that's the core of the issue. Setuptools does not seem so
obnoxious anymore... this is quite infuriating.

David

[David Cournapeau]

On Thu, Jul 1, 2010 at 11:35 AM, David Cournapeau <***@gmail.com> wrote:

>
> Yes, that's the core of the issue. Setuptools does not seem so
> obnoxious anymore... this is quite infuriating.

FWIW, the issue seems to a mix of distribute claiming to be any
setuptools version + ubuntu virtualenv package which does not include
the setuptools eggs.

I don't understand why this "works" this way, but adding the
setuptools eggs into the ubuntu virtualenv package makes the issue
goes away (i.e. virtualenv does use setuptools and not distribute as
advertised in its help message). That may help someone else with the
same issue

David

[P.J. Eby]

At 11:35 AM 7/1/2010 +0900, David Cournapeau wrote:
>On Thu, Jul 1, 2010 at 11:23 AM, P.J. Eby <***@telecommunity.com> wrote:
> > Have you tried requesting an exact version number of setuptools? (e.g.
> > setuptools==0.6c11 or setuptools==dev06)
>
>I have tried that, but easy_install considers it does not need it
>because distribute has a version higher (0.6.13):
>
>install_dir /home/david/src/rt_analytics/tmp/lib/python2.6/site-packages/
>Searching for distribute
>Best match: distribute 0.6.13

Did you try asking for an *exact* version of setuptools with '=='
(not using '>=' or leaving off a version)?

[David Cournapeau]

On Fri, Jul 2, 2010 at 12:18 AM, P.J. Eby <***@telecommunity.com> wrote:

>
> Did you try asking for an *exact* version of setuptools with '==' (not using
> '>=' or leaving off a version)?

Yes. The exact command I have tried is

easy_install setuptools==0.6c11

David

[P.J. Eby]

At 12:37 AM 7/2/2010 +0900, David Cournapeau wrote:
>On Fri, Jul 2, 2010 at 12:18 AM, P.J. Eby <***@telecommunity.com> wrote:
>
> >
> > Did you try asking for an *exact* version of setuptools with '=='
> (not using
> > '>=' or leaving off a version)?
>
>Yes. The exact command I have tried is
>
>easy_install setuptools==0.6c11

Ouch. I was under the impression that it only masqueraded as
setuptools when given a ranged request, not an exact request. That's
unfortunate.

[Suresh V.]

P.J. Eby wrote:
> At 12:37 AM 7/2/2010 +0900, David Cournapeau wrote:
>> On Fri, Jul 2, 2010 at 12:18 AM, P.J. Eby <***@telecommunity.com> wrote:
>>
>> >
>> > Did you try asking for an *exact* version of setuptools with '=='
>> (not using
>> > '>=' or leaving off a version)?
>>
>> Yes. The exact command I have tried is
>>
>> easy_install setuptools==0.6c11
>
> Ouch. I was under the impression that it only masqueraded as setuptools
> when given a ranged request, not an exact request. That's unfortunate.

Tarek: Could you please respond to this? Hope this is a bug.

Suresh

[Zubin Mithra]

Hello,

>
> Ubuntu Lucid uses distribute instead of setuptools, and I cannot
> manage to use setuptools with virtualenv because of this. I upgraded
> to the last version of virtualenv, which claims to install setuptools
> by default, but I still get distribute instead, and I would guess this
> is because of Ubuntu using distribute, but who knows....
>
> Is there a simple way to force virtualenv to install setuptools (the
> PJE version, *not* the distribute fork) ?
>

There are two reasons I'd recommend you to use virtualenv over distribute :-
1. Setuptools is no longer being maintained.
2. Distribute is Py3k compatible while setuptools is not. On the event that
virtualenv gets ported to Py3k, it will be using distribute and not
setuptools.

Is there any particular reason you wish to use setuptools?

Zubin

[David Cournapeau]

On Thu, Jul 1, 2010 at 1:15 PM, Zubin Mithra <***@gmail.com> wrote:

>
> Is there any particular reason you wish to use setuptools?

Distribute broke basic features of easy_install, which makes it
useless for my case (see for example #142). Those are fixed in
setuptools.

Also, as a rule, I like to be in control of what I use as a programmer
if I wish so, and the whole business of distribute claiming to be
setuptools is really obnoxious. I can't understand how the community
"allowed" distribute to take over setuptools like it does.

David

[Éric Araujo]

Hello

[David]
> Distribute broke basic features of easy_install, which makes it
> useless for my case (see for example #142).
Is that http://bitbucket.org/tarek/distribute/issue/142 ?
IIUC, distribute wanted to be a superset of setuptools, so bug fixes in
setuptools are supposed to go into distribute too. I’m not sure
distribute will still have the same momentum though, since we’re in the
process of taking good ideas out of it and adding them to distutils2 to
make a cleaner base for distribution (package) management in Python: see
http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon-summit-packaging-sprint-detailed-report/

> Also, as a rule, I like to be in control of what I use as a programmer
> if I wish so, and the whole business of distribute claiming to be
> setuptools is really obnoxious.
You’re perfectly entitled to do that. distribute does provide
setuptools, so it seems normal that it would say so. (Had Python a
package manager, distribute would “provide” the setuptools package while
still allowing people to choose between the two implementations. I think
it was not feasible.)

> I can't understand how the community "allowed" distribute to take
> over setuptools like it does.
Well, probably because they wanted to use a version with more bugs fixed
and new features (e.g. 3.x support).

Kind regards

[David Cournapeau]

On Thu, Jul 1, 2010 at 2:55 PM, Éric Araujo <***@netwok.org> wrote:
> Hello
>
> [David]
>> Distribute broke basic features of easy_install, which makes it
>> useless for my case (see for example #142).
> Is that http://bitbucket.org/tarek/distribute/issue/142 ?
> IIUC, distribute wanted to be a superset of setuptools, so bug fixes in
> setuptools are supposed to go into distribute too. I’m not sure
> distribute will still have the same momentum though, since we’re in the
> process of taking good ideas out of it and adding them to distutils2 to
> make a cleaner base for distribution (package) management in Python: see
> http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon-summit-packaging-sprint-detailed-report/

Hm, that's a bit different from my understanding, but that's a bit
irresponsible of Ubuntu to provide distribute if it does not get at
least the bug fixes which go into setuptools. Maybe there is a
miscommunication here, dunno. I thought the point of distribute was to
get bug fixes that setuptools maintainers did not take care of.

>
>> Also, as a rule, I like to be in control of what I use as a programmer
>> if I wish so, and the whole business of distribute claiming to be
>> setuptools is really obnoxious.
> You’re perfectly entitled to do that. distribute does provide
> setuptools, so it seems normal that it would say so. (Had Python a
> package manager, distribute would “provide” the setuptools package while
> still allowing people to choose between the two implementations. I think
> it was not feasible.)

If distribute were called distribute, it would have enabled people who
want to use it to use it. But what's done is done :)

> Well, probably because they wanted to use a version with more bugs fixed
> and new features (e.g. 3.x support).

Sure, it had to be done since so many packages depend on setuptools.

I just hope that more care were taken in the whole situation, because
those tools are so pervasive that even developers who don't use them
have to support them (through virtualenv, easy_install, etc...).
Setuptools already caused me a lot of trouble as a numpy/scipy
maintainer, and distribute makes it even worse at the moment.

David

[Tarek Ziadé]

On Thu, Jul 1, 2010 at 9:12 AM, David Cournapeau <***@gmail.com> wrote:
[..]
> Hm, that's a bit different from my understanding,
> but that's a bit
> irresponsible of Ubuntu to provide distribute if it does not get at
> least the bug fixes which go into setuptools.
> Maybe there is a
> miscommunication here, dunno. I thought the point of distribute was to
> get bug fixes that setuptools maintainers did not take care of.

It's precisely because Ubuntu is a good distribution that they decided
to switch to distribute to get the most active project in it.

If a bugfix didn't make it in Distribute, that's not an issue with Ubuntu
but a regression in Distribute we need to fix.

So as I told you many time, if you want to help, add an issue in the tracker,
or help us fixing this bug by providing a patch :)


>
>>
>>> Also, as a rule, I like to be in control of what I use as a programmer
>>> if I wish so, and the whole business of distribute claiming to be
>>> setuptools is really obnoxious.

And the whole business of setuptools claiming to be distutils in some places
is really obnoxious too. And the fact that setuptools didn't evolve
for two years, and
was locked for maintenance was really obnoxious too.

It's not an ideal situation but it helped.


> If distribute were called distribute, it would have enabled people who
> want to use it to use it. But what's done is done :)

Not at all, using the same namespace was the only way to fix the bugs we had.

> I just hope that more care were taken in the whole situation, because
> those tools are so pervasive that even developers who don't use them
> have to support them (through virtualenv, easy_install, etc...).
> Setuptools already caused me a lot of trouble as a numpy/scipy
> maintainer, and distribute makes it even worse at the moment.

We are trying to do our best, and again, I am inviting you to help us.
Maybe we will be more responsible and take better care of things if we
had you around :)

Regards
Tarek

--
Tarek Ziadé | http://ziade.org

[Tarek Ziadé]

On Thu, Jul 1, 2010 at 10:50 AM, Tarek Ziadé <***@gmail.com> wrote:
[..]
>
> So as I told you many time, if you want to help, add an issue in the tracker,
> or help us fixing this bug by providing a patch :)

I am sorry about this, I didn't see that you did provide a patch for #142.

I am lacking of time at this point, so I have added you in the bitbucket,
so please could you push your fix ?

We can ship a new release soon with this bug fix, and any other pending
ones if there are some.

Regards
Tarek

[David Cournapeau]

On Thu, Jul 1, 2010 at 6:10 PM, Tarek Ziadé <***@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 10:50 AM, Tarek Ziadé <***@gmail.com> wrote:
> [..]
>>
>> So as I told you many time, if you want to help, add an issue in the tracker,
>> or help us fixing this bug by providing a patch :)
>
> I am sorry about this, I didn't see that you did provide a patch for #142.
>
> I am lacking of time at this point, so I have added you in the bitbucket,
> so please could you push your fix ?

I could, but I would rather not without someone reviewing it. I really
don't know this code, I just copied from setuptools code. The
pkg_resources code is so convoluted that I don't have any idea on how
my patch works within the whole thing.

David

[Tarek Ziadé]

On Thu, Jul 1, 2010 at 11:56 AM, David Cournapeau <***@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 6:10 PM, Tarek Ziadé <***@gmail.com> wrote:
>> On Thu, Jul 1, 2010 at 10:50 AM, Tarek Ziadé <***@gmail.com> wrote:
>> [..]
>>>
>>> So as I told you many time, if you want to help, add an issue in the tracker,
>>> or help us fixing this bug by providing a patch :)
>>
>> I am sorry about this, I didn't see that you did provide a patch for #142.
>>
>> I am lacking of time at this point, so I have added you in the bitbucket,
>> so please could you push your fix ?
>
> I could, but I would rather not without someone reviewing it. I really
> don't know this code, I just copied from setuptools code. The
> pkg_resources code is so convoluted that I don't have any idea on how
> my patch works within the whole thing.

This bug should be pretty simple to reproduce in the test suite. If
you can add a test that's great.

In any case I'll have a look before I cut a release.

[David Cournapeau]

On Thu, Jul 1, 2010 at 5:50 PM, Tarek Ziadé <***@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 9:12 AM, David Cournapeau <***@gmail.com> wrote:
> [..]
>> Hm, that's a bit different from my understanding,
>> but that's a bit
>> irresponsible of Ubuntu to provide distribute if it does not get at
>> least the bug fixes which go into setuptools.
>> Maybe there is a
>> miscommunication here, dunno. I thought the point of distribute was to
>> get bug fixes that setuptools maintainers did not take care of.
>
> It's precisely because Ubuntu is a good distribution that they decided
> to switch to distribute to get the most active project in it.
>
> If a bugfix didn't make it in Distribute, that's not an issue with Ubuntu
> but a regression in Distribute we need to fix.
>
> So as I told you many time, if you want to help, add an issue in the tracker,
> or help us fixing this bug by providing a patch :)
>
>
>>
>>>
>>>> Also, as a rule, I like to be in control of what I use as a programmer
>>>> if I wish so, and the whole business of distribute claiming to be
>>>> setuptools is really obnoxious.
>
> And the whole business of setuptools claiming to be distutils in some places
> is really obnoxious too. And the fact that setuptools didn't evolve
> for two years, and
> was locked for maintenance was really obnoxious too.
>
> It's not an ideal situation but it helped.
>
>
>> If distribute were called distribute, it would have enabled people who
>> want to use it to use it. But what's done is done :)
>
> Not at all, using the same namespace was the only way to fix the bugs we had.

This is obviously wrong: you could have kept the name distribute, and
people who wanted to use distribute would do import distribute instead
of import setuptools. Instead, everybody is forced against their will
to use distribute instead of setuptools.

The fact that setuptools started this awful trend is no justification
for perpetuating it.

David

[Tarek Ziadé]

On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <***@telecommunity.com> wrote:
> At 10:50 AM 7/1/2010 +0200, Tarek Ziadé wrote:
>>
>> It's precisely because Ubuntu is a good distribution that they decided
>> to switch to distribute to get the most active project in it.
>
> Really?  I would've thought that the most *stable* version of a project
> would generally be the better choice for an operating system distribution.
>  ;-)

It's a better choice than setuptools, which is unmaintained for two
years with pending bugfixes.

Stable != unmaintained ;)

[Tres Seaver]

Tarek Ziadé wrote:
> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <***@telecommunity.com> wrote:
>> At 10:50 AM 7/1/2010 +0200, Tarek Ziadé wrote:
>>> It's precisely because Ubuntu is a good distribution that they decided
>>> to switch to distribute to get the most active project in it.
>> Really? I would've thought that the most *stable* version of a project
>> would generally be the better choice for an operating system distribution.
>> ;-)
>
> It's a better choice than setuptools, which is unmaintained for two
> years with pending bugfixes.

Somewhat ironic from a developer who just posted that he didn't have
time to merge a six-week-od fix for a three-month-old bug in distribute
which is already fixed (or never existed, maybe, I haven't looked) in a
seven-month-old setuptools.



Tres.
- --
===================================================================
Tres Seaver [phone] ***@palladion.com
Palladion Software "Excellence by Design" http://palladion.com

[Tarek Ziadé]

On Thu, Jul 1, 2010 at 7:24 PM, Tres Seaver <***@palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziadé wrote:
>> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <***@telecommunity.com> wrote:
>>> At 10:50 AM 7/1/2010 +0200, Tarek Ziadé wrote:
>>>> It's precisely because Ubuntu is a good distribution that they decided
>>>> to switch to distribute to get the most active project in it.
>>> Really?  I would've thought that the most *stable* version of a project
>>> would generally be the better choice for an operating system distribution.
>>>  ;-)
>>
>> It's a better choice than setuptools, which is unmaintained for two
>> years with pending bugfixes.
>
> Somewhat ironic from a developer who just posted that he didn't have
> time to merge a six-week-od fix for a three-month-old bug in distribute
> which is already fixed (or never existed, maybe, I haven't looked) in a
> seven-month-old setuptools.

If you want to check, it might be in here
http://svn.python.org/view?view=rev&revision=75384
And if you see anything else we missed, let us know !

Anyway, what you are saying is exactly the point: this piece of
software shouldn't rely on one person when that person cannot spend
time on it anymore (or not enough time)
because people get frustrated, things are not moving, and he gets
attacks from people here.

The big difference is that Distribute is not locked by me, eg there
are 10+ commiters
able to merge changes. Maybe you could have merge it yourself, since
Distribute is open to contributions ?

You just have to give me your bitbucket account and you'll have a
write access right away.

Apart from that, Distutils-SIG has been a nice place for months, (by
"nice" I mean a normal ML), and it looks like we are back on the bad
habits here. :(

So let's stop the flames about the setuptools / distribute war. If
people want to have a bits of it, they can check the archives.

Thanks,
Tarek

--
Tarek Ziadé | http://ziade.org

[David Cournapeau]

On Fri, Jul 2, 2010 at 1:24 AM, Tarek Ziadé <***@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <***@telecommunity.com> wrote:
>> At 10:50 AM 7/1/2010 +0200, Tarek Ziadé wrote:
>>>
>>> It's precisely because Ubuntu is a good distribution that they decided
>>> to switch to distribute to get the most active project in it.
>>
>> Really?  I would've thought that the most *stable* version of a project
>> would generally be the better choice for an operating system distribution.
>>  ;-)
>
> It's a better choice than setuptools, which is unmaintained for two
> years with pending bugfixes.

It is again obviously wrong, since setuptools works and distribute
does not for my use case.

I am not sure how to put this more clearly: if you pretend to be a
piece of software you are not, you better have to work for 100 % cases
of the old one. Not 90 %, not 99 %. Anything short of 100 % is
unacceptable.

If you can't guarantee 100 % compatibility, you don't force people to
use your software instead of another one, I don't understand how I
even have to explain this, really.

David

[Tarek Ziadé]

On Fri, Jul 2, 2010 at 12:42 AM, David Cournapeau <***@gmail.com> wrote:
> On Fri, Jul 2, 2010 at 1:24 AM, Tarek Ziadé <***@gmail.com> wrote:
>> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <***@telecommunity.com> wrote:
>>> At 10:50 AM 7/1/2010 +0200, Tarek Ziadé wrote:
>>>>
>>>> It's precisely because Ubuntu is a good distribution that they decided
>>>> to switch to distribute to get the most active project in it.
>>>
>>> Really?  I would've thought that the most *stable* version of a project
>>> would generally be the better choice for an operating system distribution.
>>>  ;-)
>>
>> It's a better choice than setuptools, which is unmaintained for two
>> years with pending bugfixes.
>
> It is again obviously wrong, since setuptools works and distribute
> does not for my use case.
>
> I am not sure how to put this more clearly: if you pretend to be a
> piece of software you are not, you better have to work for 100 % cases
> of the old one. Not 90 %, not 99 %. Anything short of 100 % is
> unacceptable.
>
> If you can't guarantee 100 % compatibility, you don't force people to
> use your software instead of another one, I don't understand how I
> even have to explain this, really.

What's unacceptable right now is your tone. I am going to ask you to
stop this now.

What is your problem ? a bug seems to have been fixed in setuptools
and was not backported
in distribute. That was a miss we are going to fix. Like all software,
there are bugs, regressions, etc. You made a patch, great, it'll be
pushed.

[David Cournapeau]

On Fri, Jul 2, 2010 at 6:45 PM, Tarek Ziadé <***@gmail.com> wrote:

> What is your problem ? a bug seems to have been fixed in setuptools
> and was not backported
> in distribute. That was a miss we are going to fix. Like all software,
> there are bugs, regressions, etc.  You made a patch, great, it'll be
> pushed.

The problem is not the bug. Of course, every software has bugs. The
issue is that import setuptools give distribute, even though I do want
setuptools, and that distribute does that against both upstream will
and my will. The issue is that I have wasted days of free work on
numpy/scipy because of all this softwares that had causes issues *even
though my project don't use setuptools/distribute*.

I am sure you would be pissed too if people were installing numpy,
would change behavior of say zope behind your back, and you would get
all the bug reports from your users.

David

[Barry Warsaw]

On Jul 01, 2010, at 04:12 PM, David Cournapeau wrote:

>Hm, that's a bit different from my understanding, but that's a bit
>irresponsible of Ubuntu to provide distribute if it does not get at
>least the bug fixes which go into setuptools. Maybe there is a
>miscommunication here, dunno. I thought the point of distribute was to
>get bug fixes that setuptools maintainers did not take care of.

Please submit a bug report here:

https://bugs.edge.launchpad.net/ubuntu/+source/python-virtualenv

Feel free to assign it to me (barry) or just send me the bug # and I'll take a
look at it.

-Barry

[David Cournapeau]

On Fri, Jul 2, 2010 at 12:23 AM, Barry Warsaw <***@python.org> wrote:
> On Jul 01, 2010, at 04:12 PM, David Cournapeau wrote:
>
>>Hm, that's a bit different from my understanding, but that's a bit
>>irresponsible of Ubuntu to provide distribute if it does not get at
>>least the bug fixes which go into setuptools. Maybe there is a
>>miscommunication here, dunno. I thought the point of distribute was to
>>get bug fixes that setuptools maintainers did not take care of.
>
> Please submit a bug report here:
>
> https://bugs.edge.launchpad.net/ubuntu/+source/python-virtualenv
>
> Feel free to assign it to me (barry) or just send me the bug # and I'll take a
> look at it.

This is issue 142 on bitbucket (distribute fork on Tarek account), and
there was a similar bug on setuptools issue tracker (submitted by
Zooko as well), but cannot find it ATM.

thanks for looking into this,

David

[Barry Warsaw]

On Jul 02, 2010, at 12:53 AM, David Cournapeau wrote:

>On Fri, Jul 2, 2010 at 12:23 AM, Barry Warsaw <***@python.org> wrote:
>> On Jul 01, 2010, at 04:12 PM, David Cournapeau wrote:
>>
>>>Hm, that's a bit different from my understanding, but that's a bit
>>>irresponsible of Ubuntu to provide distribute if it does not get at
>>>least the bug fixes which go into setuptools. Maybe there is a
>>>miscommunication here, dunno. I thought the point of distribute was
>>>to get bug fixes that setuptools maintainers did not take care of.
>>
>> Please submit a bug report here:
>>
>> https://bugs.edge.launchpad.net/ubuntu/+source/python-virtualenv
>>
>> Feel free to assign it to me (barry) or just send me the bug # and
>> I'll take a look at it.
>
>This is issue 142 on bitbucket (distribute fork on Tarek account), and
>there was a similar bug on setuptools issue tracker (submitted by
>Zooko as well), but cannot find it ATM.
>
>thanks for looking into this,

Maybe it's just me, but I'm having a hard time understanding and reproducing
this bug report on Ubuntu. Do you have a reproducible test case that I can
use to see the problem? Substituting pywin32 for something actually
installable on Ubuntu doesn't seem to exhibit the bug.

-Barry

[David Cournapeau]

On Fri, Jul 2, 2010 at 3:30 AM, Barry Warsaw <***@python.org> wrote:
> On Jul 02, 2010, at 12:53 AM, David Cournapeau wrote:
>
>>On Fri, Jul 2, 2010 at 12:23 AM, Barry Warsaw <***@python.org> wrote:
>>> On Jul 01, 2010, at 04:12 PM, David Cournapeau wrote:
>>>
>>>>Hm, that's a bit different from my understanding, but that's a bit
>>>>irresponsible of Ubuntu to provide distribute if it does not get at
>>>>least the bug fixes which go into setuptools. Maybe there is a
>>>>miscommunication here, dunno. I thought the point of distribute was
>>>>to get bug fixes that setuptools maintainers did not take care of.
>>>
>>> Please submit a bug report here:
>>>
>>> https://bugs.edge.launchpad.net/ubuntu/+source/python-virtualenv
>>>
>>> Feel free to assign it to me (barry) or just send me the bug # and
>>> I'll take a look at it.
>>
>>This is issue 142 on bitbucket (distribute fork on Tarek account), and
>>there was a similar bug on setuptools issue tracker (submitted by
>>Zooko as well), but cannot find it ATM.
>>
>>thanks for looking into this,
>
> Maybe it's just me, but I'm having a hard time understanding and reproducing
> this bug report on Ubuntu.  Do you have a reproducible test case that I can
> use to see the problem?

Sure. Create a dummy setup.py:

from setuptools import setup
setup(name="foo", install_requires=["somepkg"])

with "somepkg" any package already installed on ubuntu, and then:

virtualenv tmp
source tmp/bin/activate
python setup.py install

You will see that somepkg is downloaded and installed even though it
is already there. It happened for me for any value of somepkg,
including twisted, django, simplejson.

As for using setuptools instead of distribute in virtualenv, I cannot
see the option on my current machine (with lucid virtualenv), which is
weird because I clearly remember having seen it at work. I will check
there to see what's different,

David

[P.J. Eby]

At 12:53 AM 7/2/2010 +0900, David Cournapeau wrote:
>This is issue 142 on bitbucket (distribute fork on Tarek account), and
>there was a similar bug on setuptools issue tracker (submitted by
>Zooko as well), but cannot find it ATM.

http://bugs.python.org/setuptools/issue17

A fix was released in setuptools more than 8 months ago.

[P.J. Eby]

At 09:45 AM 7/1/2010 +0530, Zubin Mithra wrote:
>1. Setuptools is no longer being maintained.

This is not true. Please don't spread it, and I'd appreciate it if
you'd kindly issue a retraction in any other forum where you've
spread it. Thanks.

[Zubin Mithra]

Hello,

On Thu, Jul 1, 2010 at 8:47 PM, P.J. Eby <***@telecommunity.com> wrote:

> At 09:45 AM 7/1/2010 +0530, Zubin Mithra wrote:
>
>> 1. Setuptools is no longer being maintained.
>>
>
> This is not true. Please don't spread it, and I'd appreciate it if you'd
> kindly issue a retraction in any other forum where you've spread it.
> Thanks.
>

My sincere apologies.
I was under the impression that it was not being maintained. It'd be great
if you could point me towards the main setuptools trunk.

However, I have not worded this out on any other forum, so that should'nt be
a problem. :)

Cheers
Zubin

[P.J. Eby]

At 09:00 PM 7/1/2010 +0530, Zubin Mithra wrote:
>My sincere apologies.
>I was under the impression that it was not being maintained. It'd be
>great if you could point me towards the main setuptools trunk.

There's a link on the PyPI project page, as well as a link to the 0.6
stable branch. There's also a pointer to the bug tracker there. See
http://pypi.python.org/pypi/setuptools


>However, I have not worded this out on any other forum, so that
>should'nt be a problem. :)

Thanks. Not only is it not true that it's not maintained, but it's
actually actively developed (albeit at a glacial pace).

The most recent commits to the trunk this year are in relation to new
features in progress for 0.7; I just don't make releases that often,
and in fact I'm hesitating a bit about releasing 0.6final and 0.7a1
because that's when I expect certain parties will start cranking up
the hate machine and FUDslinging again. :-(

[Tarek Ziadé]

On Thu, Jul 1, 2010 at 5:47 PM, P.J. Eby <***@telecommunity.com> wrote:
[..]
> Thanks.  Not only is it not true that it's not maintained, but it's actually
> actively developed (albeit at a glacial pace).
>
> The most recent commits to the trunk this year are in relation to new
> features in progress for 0.7; I just don't make releases that often, and in
> fact I'm hesitating a bit about releasing 0.6final and 0.7a1 because that's
> when I expect certain parties will start cranking up the hate machine and
> FUDslinging again.  :-(

When this will stop, it's pathetic...

We had very good reasons to fork, so you are the one FUDing right here.

Can't you join the the current community effort in packaging instead
of working on your side and send messages like this ?

We could use your skills in distutils2, instead of having to deal with
all of this.

And even in setuptools, we could use your skills to add the
compatibility layers for the new PEPs. It will happen in Distribute in
any case.

[Tarek Ziadé]

On Thu, Jul 1, 2010 at 5:30 PM, Zubin Mithra <***@gmail.com> wrote:
> Hello,
> On Thu, Jul 1, 2010 at 8:47 PM, P.J. Eby <***@telecommunity.com> wrote:
>>
>> At 09:45 AM 7/1/2010 +0530, Zubin Mithra wrote:
>>>
>>> 1. Setuptools is no longer being maintained.
>>
>> This is not true.  Please don't spread it, and I'd appreciate it if you'd
>> kindly issue a retraction in any other forum where you've spread it.
>>  Thanks.

I find your behavior outrageous and counter productive for the
packaging community.

What is your definition of "maintained" ?

I consider that setuptools is not maintained, despite your 2/3 latest
commits in reaction of the fork. Doing a svn log on your project is
enough to see this. No real activity in the last 2/3 years.

I will continue to say that this is not what I call maintaining a
software, especially since you have locked its maintenance.

So I will personnaly spread it everywhere.

Use Distribute.

Tarek
--
Tarek Ziadé | http://ziade.org

[Barry Warsaw]

On Jul 01, 2010, at 11:10 AM, David Cournapeau wrote:

>Ubuntu Lucid uses distribute instead of setuptools, and I cannot
>manage to use setuptools with virtualenv because of this. I upgraded
>to the last version of virtualenv, which claims to install setuptools
>by default, but I still get distribute instead, and I would guess this
>is because of Ubuntu using distribute, but who knows....
>
>Is there a simple way to force virtualenv to install setuptools (the
>PJE version, *not* the distribute fork) ?

Yes. For Lucid, I modified our version of virtualenv to accept a --setuptools
option to use traditional setuptools.

% virtualenv --version
1.4.5
% virtualenv --help
Usage: virtualenv [OPTIONS] DEST_DIR

Options:
--version show program's version number and exit
-h, --help show this help message and exit
-v, --verbose Increase verbosity
-q, --quiet Decrease verbosity
-p PYTHON_EXE, --python=PYTHON_EXE
The Python interpreter to use, e.g.,
--python=python2.5 will use the python2.5 interpreter
to create the new environment. The default is the
interpreter that virtualenv was installed with
(/usr/bin/python)
--clear Clear out the non-root install and start from scratch
--no-site-packages Don't give access to the global site-packages dir to
the virtual environment
--unzip-setuptools Unzip Setuptools or Distribute when installing it
--relocatable Make an EXISTING virtualenv environment relocatable.
This fixes up scripts and makes all .pth files
relative
--distribute Ignored. Distribute is used by default. See
--setuptools to use Setuptools instead of Distribute.
--setuptools Use Setuptools instead of Distribute. Set environ
variable VIRTUALENV_USE_SETUPTOOLS to make it the
default.

-Barry