From cournape at gmail.com  Thu Jul  1 04:10:12 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 1 Jul 2010 11:10:12 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
Message-ID: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>

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

From pje at telecommunity.com  Thu Jul  1 04:23:57 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 30 Jun 2010 22:23:57 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.c
 om>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
Message-ID: <20100701022352.400C63A404D@sparrow.telecommunity.com>

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.)


From cournape at gmail.com  Thu Jul  1 04:35:08 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 1 Jul 2010 11:35:08 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701022352.400C63A404D@sparrow.telecommunity.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<20100701022352.400C63A404D@sparrow.telecommunity.com>
Message-ID: <AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.com>

On Thu, Jul 1, 2010 at 11:23 AM, P.J. Eby <pje at 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

From cournape at gmail.com  Thu Jul  1 05:06:47 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 1 Jul 2010 12:06:47 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<20100701022352.400C63A404D@sparrow.telecommunity.com>
	<AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.com>
Message-ID: <AANLkTikHqZHMscG5Tc-dzpUZcEufzf8feL1L0AZQgtlJ@mail.gmail.com>

On Thu, Jul 1, 2010 at 11:35 AM, David Cournapeau <cournape at 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

From zubin.mithra at gmail.com  Thu Jul  1 06:15:06 2010
From: zubin.mithra at gmail.com (Zubin Mithra)
Date: Thu, 1 Jul 2010 09:45:06 +0530
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
Message-ID: <AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100701/3d562221/attachment-0001.html>

From cournape at gmail.com  Thu Jul  1 06:51:38 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 1 Jul 2010 13:51:38 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
Message-ID: <AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>

On Thu, Jul 1, 2010 at 1:15 PM, Zubin Mithra <zubin.mithra at 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

From merwok at netwok.org  Thu Jul  1 07:55:45 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 01 Jul 2010 07:55:45 +0200
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
Message-ID: <4C2C2DE1.8050103@netwok.org>

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


From lukshuntim at gmail.com  Thu Jul  1 08:48:16 2010
From: lukshuntim at gmail.com (lukshuntim at gmail.com)
Date: Thu, 01 Jul 2010 14:48:16 +0800
Subject: [Distutils] stdeb- setting build-depends to python-dev
Message-ID: <4C2C3A30.9040801@gmail.com>

Hi,

I'm using stdeb in debian/sid and the control file it generates defaults 
to build-depends on python-all-dev. What should I do to make it 
(build-)depend on python-dev? I've tried the --xs-python-version option 
but I got python-all-dev all the same.

Thanks in advance,
ST
--

From cournape at gmail.com  Thu Jul  1 09:12:23 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 1 Jul 2010 16:12:23 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <4C2C2DE1.8050103@netwok.org>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
Message-ID: <AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>

On Thu, Jul 1, 2010 at 2:55 PM, ?ric Araujo <merwok at 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

From ziade.tarek at gmail.com  Thu Jul  1 10:50:31 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 1 Jul 2010 10:50:31 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
Message-ID: <AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>

On Thu, Jul 1, 2010 at 9:12 AM, David Cournapeau <cournape at 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

From ziade.tarek at gmail.com  Thu Jul  1 11:10:21 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 1 Jul 2010 11:10:21 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
Message-ID: <AANLkTikknhijLIKo9M_4tBFZ3MWw0xfVtr9JhyKXsb5-@mail.gmail.com>

On Thu, Jul 1, 2010 at 10:50 AM, Tarek Ziad? <ziade.tarek at 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

From cournape at gmail.com  Thu Jul  1 11:56:46 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 1 Jul 2010 18:56:46 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTikknhijLIKo9M_4tBFZ3MWw0xfVtr9JhyKXsb5-@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
	<AANLkTikknhijLIKo9M_4tBFZ3MWw0xfVtr9JhyKXsb5-@mail.gmail.com>
Message-ID: <AANLkTilCPX-U0ztPCEw9sqzFKQX4Y8Azyr0Ih4pUC84c@mail.gmail.com>

On Thu, Jul 1, 2010 at 6:10 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Jul 1, 2010 at 10:50 AM, Tarek Ziad? <ziade.tarek at 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

From ziade.tarek at gmail.com  Thu Jul  1 12:03:20 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 1 Jul 2010 12:03:20 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTilCPX-U0ztPCEw9sqzFKQX4Y8Azyr0Ih4pUC84c@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
	<AANLkTikknhijLIKo9M_4tBFZ3MWw0xfVtr9JhyKXsb5-@mail.gmail.com>
	<AANLkTilCPX-U0ztPCEw9sqzFKQX4Y8Azyr0Ih4pUC84c@mail.gmail.com>
Message-ID: <AANLkTilzifh2-JsG9ogTIKv_kao0-PnfaR0A1wQu66qU@mail.gmail.com>

On Thu, Jul 1, 2010 at 11:56 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Thu, Jul 1, 2010 at 6:10 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Thu, Jul 1, 2010 at 10:50 AM, Tarek Ziad? <ziade.tarek at 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.

From merwok at netwok.org  Thu Jul  1 15:13:24 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 01 Jul 2010 15:13:24 +0200
Subject: [Distutils] stdeb- setting build-depends to python-dev
In-Reply-To: <4C2C3A30.9040801@gmail.com>
References: <4C2C3A30.9040801@gmail.com>
Message-ID: <4C2C9474.6080709@netwok.org>

Hello

If nobody can answer you here, you can ask on
debian-python at lists.debian.org

Regards


From pje at telecommunity.com  Thu Jul  1 17:17:02 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 01 Jul 2010 11:17:02 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.c
 om>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
Message-ID: <20100701151652.1E09A3A404D@sparrow.telecommunity.com>

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.


From pje at telecommunity.com  Thu Jul  1 17:18:17 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 01 Jul 2010 11:18:17 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.c
 om>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<20100701022352.400C63A404D@sparrow.telecommunity.com>
	<AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.com>
Message-ID: <20100701151805.CCDF43A404D@sparrow.telecommunity.com>

At 11:35 AM 7/1/2010 +0900, David Cournapeau wrote:
>On Thu, Jul 1, 2010 at 11:23 AM, P.J. Eby <pje at 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)?


From barry at python.org  Thu Jul  1 17:19:36 2010
From: barry at python.org (Barry Warsaw)
Date: Thu, 1 Jul 2010 11:19:36 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
Message-ID: <20100701111936.35539e38@heresy>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100701/ed621624/attachment.pgp>

From barry at python.org  Thu Jul  1 17:23:44 2010
From: barry at python.org (Barry Warsaw)
Date: Thu, 1 Jul 2010 11:23:44 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
Message-ID: <20100701112344.6cf86519@heresy>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100701/f5d49c7c/attachment.pgp>

From zubin.mithra at gmail.com  Thu Jul  1 17:30:14 2010
From: zubin.mithra at gmail.com (Zubin Mithra)
Date: Thu, 1 Jul 2010 21:00:14 +0530
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701151652.1E09A3A404D@sparrow.telecommunity.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<20100701151652.1E09A3A404D@sparrow.telecommunity.com>
Message-ID: <AANLkTimNLWVeJGUFXAesjA6Hu3U3f7BL5YijvYFEzxvO@mail.gmail.com>

Hello,

On Thu, Jul 1, 2010 at 8:47 PM, P.J. Eby <pje at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100701/03e77984/attachment-0001.html>

From strawman at astraw.com  Thu Jul  1 17:35:59 2010
From: strawman at astraw.com (Andrew Straw)
Date: Thu, 01 Jul 2010 08:35:59 -0700
Subject: [Distutils] stdeb- setting build-depends to python-dev
In-Reply-To: <4C2C3A30.9040801@gmail.com>
References: <4C2C3A30.9040801@gmail.com>
Message-ID: <4C2CB5DF.8020405@astraw.com>

On 06/30/2010 11:48 PM, lukshuntim at gmail.com wrote:
> I'm using stdeb in debian/sid and the control file it generates
> defaults to build-depends on python-all-dev. What should I do to make
> it (build-)depend on python-dev? I've tried the --xs-python-version
> option but I got python-all-dev all the same.
Hi, Thanks for the report. You've discovered a bug, and I've added it to
our tracker, where you can watch its progress:
http://github.com/astraw/stdeb/issues/issue/35

(And this is the right place to ask questions about stdeb.)
-Andrew


From cournape at gmail.com  Thu Jul  1 17:37:33 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 00:37:33 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701151805.CCDF43A404D@sparrow.telecommunity.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<20100701022352.400C63A404D@sparrow.telecommunity.com>
	<AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.com>
	<20100701151805.CCDF43A404D@sparrow.telecommunity.com>
Message-ID: <AANLkTilRf3ArjIzusntAyqkPvDtavWngbX5lH0TYkhQn@mail.gmail.com>

On Fri, Jul 2, 2010 at 12:18 AM, P.J. Eby <pje at 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

From cournape at gmail.com  Thu Jul  1 17:40:39 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 00:40:39 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
Message-ID: <AANLkTik3h4vvQPqtvI5cL6TA4XFsurG-B-efL7jHGw7c@mail.gmail.com>

On Thu, Jul 1, 2010 at 5:50 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Jul 1, 2010 at 9:12 AM, David Cournapeau <cournape at 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

From pje at telecommunity.com  Thu Jul  1 17:47:59 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 01 Jul 2010 11:47:59 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTimNLWVeJGUFXAesjA6Hu3U3f7BL5YijvYFEzxvO@mail.gmail.c
 om>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<20100701151652.1E09A3A404D@sparrow.telecommunity.com>
	<AANLkTimNLWVeJGUFXAesjA6Hu3U3f7BL5YijvYFEzxvO@mail.gmail.com>
Message-ID: <20100701154748.EE7733A40A5@sparrow.telecommunity.com>

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.  :-(


From pje at telecommunity.com  Thu Jul  1 17:51:18 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 01 Jul 2010 11:51:18 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTilRf3ArjIzusntAyqkPvDtavWngbX5lH0TYkhQn@mail.gmail.c
 om>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<20100701022352.400C63A404D@sparrow.telecommunity.com>
	<AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.com>
	<20100701151805.CCDF43A404D@sparrow.telecommunity.com>
	<AANLkTilRf3ArjIzusntAyqkPvDtavWngbX5lH0TYkhQn@mail.gmail.com>
Message-ID: <20100701155107.999EA3A404D@sparrow.telecommunity.com>

At 12:37 AM 7/2/2010 +0900, David Cournapeau wrote:
>On Fri, Jul 2, 2010 at 12:18 AM, P.J. Eby <pje at 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.


From cournape at gmail.com  Thu Jul  1 17:53:27 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 00:53:27 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701112344.6cf86519@heresy>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<20100701112344.6cf86519@heresy>
Message-ID: <AANLkTimPzss2YkebbXqetTNAdNRfZr-DKa0zhLQdFLDU@mail.gmail.com>

On Fri, Jul 2, 2010 at 12:23 AM, Barry Warsaw <barry at 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

From merwok at netwok.org  Thu Jul  1 17:57:13 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 01 Jul 2010 17:57:13 +0200
Subject: [Distutils] stdeb- setting build-depends to python-dev
In-Reply-To: <4C2CB5DF.8020405@astraw.com>
References: <4C2C3A30.9040801@gmail.com> <4C2CB5DF.8020405@astraw.com>
Message-ID: <4C2CBAD9.4070601@netwok.org>

> (And this is the right place to ask questions about stdeb.)
I?m sorry, I read the message too fast. stdeb does belong on this list,
I hope I didn?t sound unfriendly when I made my hasty suggestion. Thanks
Andrew.

Regards


From ziade.tarek at gmail.com  Thu Jul  1 18:24:12 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 1 Jul 2010 18:24:12 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701152032.8ADA83A404D@sparrow.telecommunity.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
	<20100701152032.8ADA83A404D@sparrow.telecommunity.com>
Message-ID: <AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>

On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <pje at 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 ;)

From ziade.tarek at gmail.com  Thu Jul  1 18:30:15 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 1 Jul 2010 18:30:15 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTimNLWVeJGUFXAesjA6Hu3U3f7BL5YijvYFEzxvO@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<20100701151652.1E09A3A404D@sparrow.telecommunity.com>
	<AANLkTimNLWVeJGUFXAesjA6Hu3U3f7BL5YijvYFEzxvO@mail.gmail.com>
Message-ID: <AANLkTilMSulYfjrDrxdt-Xp6S87sH6Ygf2D5X9arREPX@mail.gmail.com>

On Thu, Jul 1, 2010 at 5:30 PM, Zubin Mithra <zubin.mithra at gmail.com> wrote:
> Hello,
> On Thu, Jul 1, 2010 at 8:47 PM, P.J. Eby <pje at 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

From ziade.tarek at gmail.com  Thu Jul  1 18:39:07 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 1 Jul 2010 18:39:07 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701154748.EE7733A40A5@sparrow.telecommunity.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<20100701151652.1E09A3A404D@sparrow.telecommunity.com>
	<AANLkTimNLWVeJGUFXAesjA6Hu3U3f7BL5YijvYFEzxvO@mail.gmail.com>
	<20100701154748.EE7733A40A5@sparrow.telecommunity.com>
Message-ID: <AANLkTimQX7gTAWnNSRmDkRpdwbDbv3ygwzWEOtlcT9ly@mail.gmail.com>

On Thu, Jul 1, 2010 at 5:47 PM, P.J. Eby <pje at 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.

From tseaver at palladion.com  Thu Jul  1 19:24:36 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 01 Jul 2010 13:24:36 -0400
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>	<4C2C2DE1.8050103@netwok.org>	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>	<20100701152032.8ADA83A404D@sparrow.telecommunity.com>
	<AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>
Message-ID: <i0ij0o$qsp$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:
> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <pje at 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          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwsz1AACgkQ+gerLs4ltQ7ATQCeJGSKPc4b1+NRPon8NMwNjbFD
r1UAnjFg8SxY7FjlhFfG8wninfZVts7O
=tg7g
-----END PGP SIGNATURE-----


From ziade.tarek at gmail.com  Thu Jul  1 20:12:34 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 1 Jul 2010 20:12:34 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <i0ij0o$qsp$1@dough.gmane.org>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
	<20100701152032.8ADA83A404D@sparrow.telecommunity.com>
	<AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>
	<i0ij0o$qsp$1@dough.gmane.org>
Message-ID: <AANLkTily6NVFPDLiWz_P8-4aS1ZaOxBCrfpHxc5vWQEH@mail.gmail.com>

On Thu, Jul 1, 2010 at 7:24 PM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <pje at 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

From barry at python.org  Thu Jul  1 20:30:11 2010
From: barry at python.org (Barry Warsaw)
Date: Thu, 1 Jul 2010 14:30:11 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTimPzss2YkebbXqetTNAdNRfZr-DKa0zhLQdFLDU@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<20100701112344.6cf86519@heresy>
	<AANLkTimPzss2YkebbXqetTNAdNRfZr-DKa0zhLQdFLDU@mail.gmail.com>
Message-ID: <20100701143011.3dce407d@heresy>

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

>On Fri, Jul 2, 2010 at 12:23 AM, Barry Warsaw <barry at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100701/f8f40208/attachment.pgp>

From pje at telecommunity.com  Thu Jul  1 21:20:50 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 01 Jul 2010 15:20:50 -0400
Subject: [Distutils] How to force installing setuptools instead of
 distribute ?
In-Reply-To: <AANLkTimPzss2YkebbXqetTNAdNRfZr-DKa0zhLQdFLDU@mail.gmail.c
 om>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<20100701112344.6cf86519@heresy>
	<AANLkTimPzss2YkebbXqetTNAdNRfZr-DKa0zhLQdFLDU@mail.gmail.com>
Message-ID: <20100701192040.910653A404D@sparrow.telecommunity.com>

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.


From techtonik at gmail.com  Thu Jul  1 22:36:20 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 1 Jul 2010 23:36:20 +0300
Subject: [Distutils] easy_install wrong download site preference
In-Reply-To: <20100630165409.0D70F3A404D@sparrow.telecommunity.com>
References: <AANLkTim21s6ROmQ2S4rJePA6HT23jOeWoeCMNCDtctr_@mail.gmail.com>
	<20100630165409.0D70F3A404D@sparrow.telecommunity.com>
Message-ID: <AANLkTiluz8Gl7iwCnL_yNuKMy61xPHtMzq9MfCbFAYbc@mail.gmail.com>

On Wed, Jun 30, 2010 at 7:54 PM, P.J. Eby <pje at telecommunity.com> wrote:
>
> It prefers newer packages, or, if the versions are the same, it prefers the shortest download URL. ?In this case, the Google Code url is shorter.

That's illogical. Better prefer PyPI if versions are the same.

>> Is it possible to raise the priority of PyPI mirror for protobuf project somehow?
>
> No. ?If (e.g.) http://pypi.python.org/packages/source/p/protobuf/protobuf-2.3.0.tar.gz and http://protobuf.googlecode.com/files/protobuf-2.3.0.tar.gz aren't equivalent files, they should not be named the same thing -- especially since this practice can confuse humans as well as easy_install.

http://protobuf.googlecode.com/files/protobuf-2.3.0.tar.gz contains
source code for the whole project including C++ compiler, Java, Python
and other libraries. Renaming Python library seems like a hack - not a
solution.

> On a practical level, if it's too late for the Python project to use a different name, ?I would suggest changing the PyPI homepage links (for current and past releases) to point to a Python-specific project page, that does not contain links to download the generic, non-Python package. ?This will keep easy_install from considering them as candidates for downloading.

PyPI is that page. Google Code URL homepage doesn't have any Python
related downloads at all. What if we set download_url instead of
homepage back to PyPI page - will it satisfy setuptools as a quick
fix? (I understand that people do not want to touch setuptools code
anymore)

> (Note: you will have to go into PyPI's administration interface and manually change the home page link for *all past versions* as well, due to the way the /simple index works.)

Where is the relevant code for this PyPI? I wonder why it didn't set
rel="download" for PyPI downloads if it should?

-- 
anatoly t.

From pje at telecommunity.com  Thu Jul  1 23:10:39 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 01 Jul 2010 17:10:39 -0400
Subject: [Distutils] easy_install wrong download site preference
In-Reply-To: <AANLkTiluz8Gl7iwCnL_yNuKMy61xPHtMzq9MfCbFAYbc@mail.gmail.c
 om>
References: <AANLkTim21s6ROmQ2S4rJePA6HT23jOeWoeCMNCDtctr_@mail.gmail.com>
	<20100630165409.0D70F3A404D@sparrow.telecommunity.com>
	<AANLkTiluz8Gl7iwCnL_yNuKMy61xPHtMzq9MfCbFAYbc@mail.gmail.com>
Message-ID: <20100701211028.AB52A3A404D@sparrow.telecommunity.com>

At 11:36 PM 7/1/2010 +0300, anatoly techtonik wrote:
>On Wed, Jun 30, 2010 at 7:54 PM, P.J. Eby <pje at telecommunity.com> wrote:
> >
> > It prefers newer packages, or, if the versions are the same, it 
> prefers the shortest download URL. ? In this case, the Google Code 
> url is shorter.
>
>That's illogical. Better prefer PyPI if versions are the same.

The "shortest path" logic is there to avoid certain file recognition 
problems that occur without it.  The special case of PyPI isn't 
special enough to break those rules.


>PyPI is that page. Google Code URL homepage doesn't have any Python
>related downloads at all.

There isn't any way to know that from the filename.


>What if we set download_url instead of
>homepage back to PyPI page - will it satisfy setuptools as a quick
>fix?

No.  You'd need to remove the current "home_page" setting, or point 
it elsewhere.


>  (I understand that people do not want to touch setuptools code
>anymore)

That's not really the issue; the issue here is that package 
precedence is based on a stable comparison scheme, where it doesn't 
make sense to give one location priority over another, as it will 
simply lead to someone else complaining about the changed behavior, 
because they were relying on a different URL having precedence under 
the current scheme.

What's more, even if I made this change and released it immediately 
into the wild, you would *still* have this problem for the entire 
existing installed base, which is considerable.  (Many people have 
not upgraded from setuptools 0.6c2 or 0.6c9, which are many years old.)

And, the distribute fork would need to match the behavior as well, or 
there's that group of people who may still end up with the wrong 
file.  Already, AFAICT, distribute has changed (at least in the 
repository) the path precedence rules in a way that is not consistent 
with the way setuptools does it, for both URLs *and* local file 
paths, so I can't really give any guidance as to what their version 
of easy_install will do -- it may do the "right thing" in this case, 
but if so, it's essentially by accident.  (i.e., it won't necessarily 
do the right thing in other cases, since their changes weren't 
motivated by the same issue.)

(One thing that I *could* do, would be to give precedence to links 
with #md5 tags -- this would automatically make PyPI (and PyPI-clone) 
links score higher, and would be less likely to introduce problems 
than trying to force recognition of PyPI specifically.  But this 
would still have the problem of getting out into the field in a timely way.)


> > (Note: you will have to go into PyPI's administration interface 
> and manually change the home page link for *all past versions* as 
> well, due to the way the /simple index works.)
>
>Where is the relevant code for this PyPI? I wonder why it didn't set
>rel="download" for PyPI downloads if it should?

That's not the problem either; easy_install is *finding* those links 
just fine; if you use "easy_install -vvn protobuf" you'll see it list 
both the PyPI tgz's and the Google Code URLs as candidates; it's just 
using the URL length as the tie-breaker.


From techtonik at gmail.com  Fri Jul  2 00:33:19 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 2 Jul 2010 01:33:19 +0300
Subject: [Distutils] easy_install wrong download site preference
In-Reply-To: <20100701211028.AB52A3A404D@sparrow.telecommunity.com>
References: <AANLkTim21s6ROmQ2S4rJePA6HT23jOeWoeCMNCDtctr_@mail.gmail.com>
	<20100630165409.0D70F3A404D@sparrow.telecommunity.com>
	<AANLkTiluz8Gl7iwCnL_yNuKMy61xPHtMzq9MfCbFAYbc@mail.gmail.com>
	<20100701211028.AB52A3A404D@sparrow.telecommunity.com>
Message-ID: <AANLkTilFubS6NtVmrVCNxZJW8sYIJQQlE5zW1paFBa0F@mail.gmail.com>

On Fri, Jul 2, 2010 at 12:10 AM, P.J. Eby <pje at telecommunity.com> wrote:
>> >
>> > It prefers newer packages, or, if the versions are the same, it prefers
>> > the shortest download URL. ? In this case, the Google Code url is shorter.
>>
>> That's illogical. Better prefer PyPI if versions are the same.
>
> The "shortest path" logic is there to avoid certain file recognition
> problems that occur without it. ?The special case of PyPI isn't special
> enough to break those rules.

Although practicality beats purity. Can you list those "certain file
recognition problems"? I.e. Explicit is better than implicit.

>> PyPI is that page. Google Code URL homepage doesn't have any Python
>> related downloads at all.
> There isn't any way to know that from the filename.

That's why it should use the site where all filenames are Python
downloads if filenames are the same.

>> What if we set download_url instead of
>> homepage back to PyPI page - will it satisfy setuptools as a quick
>> fix?
> No. ?You'd need to remove the current "home_page" setting, or point it
> elsewhere.

That's very strange. Then what download_url is for?

>> ?(I understand that people do not want to touch setuptools code
>> anymore)
>
> That's not really the issue; the issue here is that package precedence is
> based on a stable comparison scheme, where it doesn't make sense to give one
> location priority over another, as it will simply lead to someone else
> complaining about the changed behavior, because they were relying on a
> different URL having precedence under the current scheme.

These rules need to be described first. What if somebody already broke
the proper order and now everybody suffers? If autodiscovery rules
were well described - it was possible to analyse them and propose more
intuitive approach. Then if "someone else" will attempt to complain -
you could send them to the PEP or another "how and why" document.

> What's more, even if I made this change and released it immediately into the
> wild, you would *still* have this problem for the entire existing installed
> base, which is considerable. ?(Many people have not upgraded from setuptools
> 0.6c2 or 0.6c9, which are many years old.)

Do you know how many? I suspect they probably do not need protocol
buffers anyway. In either case it is absolutely normal to require
newer version of setuptools for installation and mention it in docs.

> And, the distribute fork would need to match the behavior as well, or
> there's that group of people who may still end up with the wrong file.

Chances are that it will be the right file (according to "how and why" PEP). =)

> ?Already, AFAICT, distribute has changed (at least in the repository) the
> path precedence rules in a way that is not consistent with the way
> setuptools does it, for both URLs *and* local file paths, so I can't really
> give any guidance as to what their version of easy_install will do -- it may
> do the "right thing" in this case, but if so, it's essentially by accident.
> ?(i.e., it won't necessarily do the right thing in other cases, since their
> changes weren't motivated by the same issue.)

There definitely should be some FAQ/doc/agreement about how weight of
the links is calculated during discovery process. Should we with
describing current state in Google Wave?

> (One thing that I *could* do, would be to give precedence to links with #md5
> tags -- this would automatically make PyPI (and PyPI-clone) links score
> higher, and would be less likely to introduce problems than trying to force
> recognition of PyPI specifically. ?But this would still have the problem of
> getting out into the field in a timely way.)

Perhaps not specifically PyPI, but any [default] index/mirror site
should be scored higher, although any fix would suffice.

I don't see what md5 is for. If it is for downloads protection then
people who can upload malicious package will have it regenerated
automatically, and for MITM attacks it is not a problem to replace md5
either.

>> Where is the relevant code for this PyPI? I wonder why it didn't set
>> rel="download" for PyPI downloads if it should?
>
> That's not the problem either; easy_install is *finding* those links just
> fine; if you use "easy_install -vvn protobuf" you'll see it list both the
> PyPI tgz's and the Google Code URLs as candidates; it's just using the URL
> length as the tie-breaker.

I thought it will raise the weight of those links if there could be a
rel="download" attribute.
-- 
anatoly t.

From cournape at gmail.com  Fri Jul  2 00:36:23 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 07:36:23 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701143011.3dce407d@heresy>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<20100701112344.6cf86519@heresy>
	<AANLkTimPzss2YkebbXqetTNAdNRfZr-DKa0zhLQdFLDU@mail.gmail.com>
	<20100701143011.3dce407d@heresy>
Message-ID: <AANLkTilTZ1YqlOyr22iHyUAm4kZ_WbV7mOwHhxqaiDC7@mail.gmail.com>

On Fri, Jul 2, 2010 at 3:30 AM, Barry Warsaw <barry at 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 <barry at 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

From cournape at gmail.com  Fri Jul  2 00:42:04 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 07:42:04 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
	<20100701152032.8ADA83A404D@sparrow.telecommunity.com>
	<AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>
Message-ID: <AANLkTinRtfFOMUpXTqv1pPWGZCaZg2JJr-JtmtzTV1bA@mail.gmail.com>

On Fri, Jul 2, 2010 at 1:24 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <pje at 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

From pje at telecommunity.com  Fri Jul  2 04:06:04 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 01 Jul 2010 22:06:04 -0400
Subject: [Distutils] easy_install wrong download site preference
In-Reply-To: <AANLkTilFubS6NtVmrVCNxZJW8sYIJQQlE5zW1paFBa0F@mail.gmail.c
 om>
References: <AANLkTim21s6ROmQ2S4rJePA6HT23jOeWoeCMNCDtctr_@mail.gmail.com>
	<20100630165409.0D70F3A404D@sparrow.telecommunity.com>
	<AANLkTiluz8Gl7iwCnL_yNuKMy61xPHtMzq9MfCbFAYbc@mail.gmail.com>
	<20100701211028.AB52A3A404D@sparrow.telecommunity.com>
	<AANLkTilFubS6NtVmrVCNxZJW8sYIJQQlE5zW1paFBa0F@mail.gmail.com>
Message-ID: <20100702020559.230C53A404D@sparrow.telecommunity.com>

At 01:33 AM 7/2/2010 +0300, anatoly techtonik wrote:
>On Fri, Jul 2, 2010 at 12:10 AM, P.J. Eby <pje at telecommunity.com> wrote:
> >> >
> >> > It prefers newer packages, or, if the versions are the same, it prefers
> >> > the shortest download URL. ?? In this case, the Google Code 
> url is shorter.
> >>
> >> That's illogical. Better prefer PyPI if versions are the same.
> >
> > The "shortest path" logic is there to avoid certain file recognition
> > problems that occur without it. ? The special case of PyPI isn't special
> > enough to break those rules.
>
>Although practicality beats purity. Can you list those "certain file
>recognition problems"? I.e. Explicit is better than implicit.

I have a vague recollection that it was Fredrik Lundh's website that 
sparked the original realization of the need for preferring shorter 
URLs, but I wouldn't swear to it.  I'd have to dig through years of 
revision history to find the original change, assuming I documented 
it well enough.  The choice of short paths over long was also 
intended to favor nearby files over further ones, and local paths over URLs.

(All that being said, it's still fundamentally a heuristic, and not a 
very good one at that.  But that doesn't automatically make any other 
heuristic *better*; this is one area where status quo bias is a good thing.)


>That's why it should use the site where all filenames are Python
>downloads if filenames are the same.

And how would that work with all the PyPI clones, private indexes, etc.?


> > No. ? You'd need to remove the current "home_page" setting, or point it
> > elsewhere.
>
>That's very strange. Then what download_url is for?

The home page and download URLs are simply treated as pages which may 
contain links to files, if they are not themselves links to 
files.  That's the only special status they have.


> >> ? (I understand that people do not want to touch setuptools code
> >> anymore)
> >
> > That's not really the issue; the issue here is that package precedence is
> > based on a stable comparison scheme, where it doesn't make sense 
> to give one
> > location priority over another, as it will simply lead to someone else
> > complaining about the changed behavior, because they were relying on a
> > different URL having precedence under the current scheme.
>
>These rules need to be described first. What if somebody already broke
>the proper order and now everybody suffers? If autodiscovery rules
>were well described - it was possible to analyse them and propose more
>intuitive approach. Then if "someone else" will attempt to complain -
>you could send them to the PEP or another "how and why" document.

http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-available-for-easyinstall

http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api


>I thought it will raise the weight of those links if there could be a
>rel="download" attribute.

There is no "weighting" of links - what is weighted are 
distributions, and distribution objects only have their raw URL 
available as a basis for sorting once the version and archive type 
(the two higher-precedence attributes) are considered.  The place 
where a URL was retrieved from is not tracked, and thus can't be used 
for sorting without a good chunk of refactoring...  which refactoring 
would likely break tools that build on top of setuptools' PackageIndex class.

In short, what you're asking for is a pretty major feature that would 
be difficult to implement in a way that would be guaranteed not to 
break other things.


From ziade.tarek at gmail.com  Fri Jul  2 11:45:07 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 11:45:07 +0200
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTinRtfFOMUpXTqv1pPWGZCaZg2JJr-JtmtzTV1bA@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
	<20100701152032.8ADA83A404D@sparrow.telecommunity.com>
	<AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>
	<AANLkTinRtfFOMUpXTqv1pPWGZCaZg2JJr-JtmtzTV1bA@mail.gmail.com>
Message-ID: <AANLkTik-yuo4ojbjdnCqEVKPtsiP-M1z7cUFTKfc4Rkg@mail.gmail.com>

On Fri, Jul 2, 2010 at 12:42 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 1:24 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Thu, Jul 1, 2010 at 5:20 PM, P.J. Eby <pje at 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.

From cournape at gmail.com  Fri Jul  2 11:54:48 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 18:54:48 +0900
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <AANLkTik-yuo4ojbjdnCqEVKPtsiP-M1z7cUFTKfc4Rkg@mail.gmail.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>
	<AANLkTimLaVUkeYOZDxaZDpmkXFyR606ZN4O0kCuHC5g9@mail.gmail.com>
	<AANLkTinxYCvA0LEqijjRXl5604IEXipSj7ZvpqiCXoFI@mail.gmail.com>
	<4C2C2DE1.8050103@netwok.org>
	<AANLkTinXqgwvTkRS1Xl_N6mBnQ8XpkdAa8jLS9Piremk@mail.gmail.com>
	<AANLkTim4m4oRUTJVrT6_RYyi654zytuny98bJybioDZ3@mail.gmail.com>
	<20100701152032.8ADA83A404D@sparrow.telecommunity.com>
	<AANLkTimdN8gihlvUAMvky10yq_cuX1GJftR61C931uP4@mail.gmail.com>
	<AANLkTinRtfFOMUpXTqv1pPWGZCaZg2JJr-JtmtzTV1bA@mail.gmail.com>
	<AANLkTik-yuo4ojbjdnCqEVKPtsiP-M1z7cUFTKfc4Rkg@mail.gmail.com>
Message-ID: <AANLkTikNeToBMT2d-wrQ9ja-yjFGZysbFfDYRRHqG0LT@mail.gmail.com>

On Fri, Jul 2, 2010 at 6:45 PM, Tarek Ziad? <ziade.tarek at 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

From ziade.tarek at gmail.com  Fri Jul  2 12:08:33 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 12:08:33 +0200
Subject: [Distutils] Packaging situation + mailing list rules
Message-ID: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>

Hello,

>From time to time this mailing list is getting very unpleasant to work
in because some old disagreements,
and because some people are starting to get really nasty.

Here's a reminder of the current packaging situation, and a few rules
I suggest, for the benefit of all

1. Python <= 2.7 contains Distutils

2. Distutils is frozen, and won't evolve anymore

3. Setuptools is built on Distutils

4. Distribute forks Setuptools for various reasons. If you disagree
with this choice, there's no need to send a mail here, because this
    is done. You can send me a private mail, but don't send a mail
here because things are always getting nasty afterwards.
    Make sure to read the archives first, to understand why it was done.

5. Debian, Ubuntu and Fedora are using Distribute rather than
Setuptools. If you find differences in the behavior, you can send
    a mail in this list, so we can fix Distribute. If you disagree
with the distros choice, there's no need to send a mail here,
    because this is done. You can send *them* a mail, or tell them you
disagree with this choice.
    Of course, the most effective behavior would be to work on having
Distribute fixed if you find an issue, but that's up to you.

6. Distutils2 is being built, and has its own mailing list now.
Distutils2 will replace Distutils in Python 3.2 or 3.3.
    It' s built on the various PEPs that were accepted lately, and any
help is welcome..
    The list is here:
http://groups.google.fr/group/the-fellowship-of-the-packaging, and is
moderated.

7. New members of the lists will not know the situation, so they won't
be able to follow these rules of course. But people that
    are hanging around here for years can apply them.

Of course this is just a series of suggestion. You can disagree with
all these rules if you want, but I think they need to be applied in
this mailing-list for the benefit of all.

Thanks,
Tarek

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

From techtonik at gmail.com  Fri Jul  2 14:09:33 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 2 Jul 2010 15:09:33 +0300
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
Message-ID: <AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>

Great post, Tarek. Following good old newsgroups/FIDOnet tradition it
could be nice to see this transformed to Rules/FAQ document that will
be reposted automatically here by a robot about once a month.

Without such documents your proposal will be weakly supported, because
people will still have questions, and you will need to answer them
reasonably to eliminate the source of conflict for making
collaboration moving into the right direction (which you also need to
define).

1. Why the rules?
> From time to time this mailing list is getting very unpleasant to work
> in because some old disagreements, and because some people are
> starting to get really nasty.

2. What are those 'disagreements' people can agree upon?

3. "Python <= 2.7 contains Distutils" - is there anything wrong with that?

4. "Distutils is frozen, and won't evolve anymore" - mmm, ahem.. well.. ok.

5. But you know - I am somewhat familiar with distutils code - it is
much easier for me to continue patching it than start using something
that will only appear in some distant 3k Python I have no desire to
play with now. I need to solve real world problems and these are all
with Python 2.x

6. Why Distribute forks Setuptools? It is said `for various reasons`,
but I can't get it.
> There's no need to send a mail here, because this?is done.
> If you send a mail here expect things become nasty.

7. But I want to know!
> No you don't.

8. Nooooo. I want!
> See. It is already starting..

9. But I want to know it. :-(
> Make sure to read the archives first, to understand why it was done.

10. Maan, that's too long, pydotorg archives suxx - may I have a summary?
> Well, does anybody want to post recent Shakespeare script here?

11. It is said that people may disagree that Debian, Ubuntu and Fedora
are using Distribute? But why??

12. BTW, is Setuptools still alive?

13. What are those Distribute, Setuptools and Distutils2 anyway?


After this FAQ it would be really nice to see editable draft of
Roadmap/Status document that people can get for an overview of the
current state and choose the tasks they feel most important for
further collaboration.


P.S. http://groups.google.com/group/the-fellowship-of-the-packaging is
more international than
http://groups.google.fr/group/the-fellowship-of-the-packaging


-- 
anatoly t.

From cournape at gmail.com  Fri Jul  2 15:04:23 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 22:04:23 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
Message-ID: <AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>

On Fri, Jul 2, 2010 at 9:09 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> Great post, Tarek. Following good old newsgroups/FIDOnet tradition it
> could be nice to see this transformed to Rules/FAQ document that will
> be reposted automatically here by a robot about once a month.
>
> Without such documents your proposal will be weakly supported, because
> people will still have questions, and you will need to answer them
> reasonably to eliminate the source of conflict for making
> collaboration moving into the right direction (which you also need to
> define).
>
> 1. Why the rules?
>> From time to time this mailing list is getting very unpleasant to work
>> in because some old disagreements, and because some people are
>> starting to get really nasty.
>
> 2. What are those 'disagreements' people can agree upon?

I think the following in uncontroversial:

distutils and setuptools are useful packaging solutions which have
significant shortcoming, both design and implementation-wise. Some
people believe the distutils/setuptools/distribute issues can be
solved by gradually deprecating code and adding new features, other
people (me, but I am not alone) believe it would be better and faster
to rewrite something from scratch because the distutils code is
unmanageable and too complicated.

> 11. It is said that people may disagree that Debian, Ubuntu and Fedora
> are using Distribute? But why??

Nobody disagrees about the use of distribute. That's open source, and
one of the point of open source is to let people do what they want,
and nobody should be prevented to use distribute because someone does
not like it. But that works both ways - if I do not want to use
distribute, I should not be forced to use it because someone else
decided it was good for me.

David

From ziade.tarek at gmail.com  Fri Jul  2 15:31:13 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 15:31:13 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
Message-ID: <AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>

2010/7/2 David Cournapeau <cournape at gmail.com>:
> On Fri, Jul 2, 2010 at 9:09 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>> Great post, Tarek. Following good old newsgroups/FIDOnet tradition it
>> could be nice to see this transformed to Rules/FAQ document that will
>> be reposted automatically here by a robot about once a month.
>>
>> Without such documents your proposal will be weakly supported, because
>> people will still have questions, and you will need to answer them
>> reasonably to eliminate the source of conflict for making
>> collaboration moving into the right direction (which you also need to
>> define).
>>
>> 1. Why the rules?
>>> From time to time this mailing list is getting very unpleasant to work
>>> in because some old disagreements, and because some people are
>>> starting to get really nasty.
>>
>> 2. What are those 'disagreements' people can agree upon?
>
> I think the following in uncontroversial:
>
> distutils and setuptools are useful packaging solutions which have
> significant shortcoming, both design and implementation-wise. Some
> people believe the distutils/setuptools/distribute issues can be
> solved by gradually deprecating code and adding new features, other
> people (me, but I am not alone) believe it would be better and faster
> to rewrite something from scratch because the distutils code is
> unmanageable and too complicated.

You keep saying that for years, but in the meantime, the code was cleaned.

And it's perfectly manageable. We have 5 GSOC students working on it
right now and they
don't seem to have so much problems in changing/reading the code.

And now, it's being rewritten in distutils2 in a backward incompatible way.
So if you don't like some things in the design, you can say it out loud
and make some constructive proposals if you want.


>> 11. It is said that people may disagree that Debian, Ubuntu and Fedora
>> are using Distribute? But why??
>
> Nobody disagrees about the use of distribute. That's open source, and
> one of the point of open source is to let people do what they want,
> and nobody should be prevented to use distribute because someone does
> not like it. But that works both ways - if I do not want to use
> distribute, I should not be forced to use it because someone else
> decided it was good for me.

If you use Ubuntu, they make some choices for you.

For instance Distutils is patched in Ubuntu, and you don't get the
same version that one you would get in a plain Python.  Package are
installed in a specific location etc.

So if you want to have the very same version for all packages in your
Linux, and have it behaving exactly like the initial author of each
package wanted, you should install a low-level distro like Linux From
Scratch, and build the environment you like.

So yes, it's open source: you can install a distro and adopt its
choices, or change it, or miltate to have other choices. Or you can
use another distro.

From cournape at gmail.com  Fri Jul  2 15:42:59 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 22:42:59 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
Message-ID: <AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>

On Fri, Jul 2, 2010 at 10:31 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> 2010/7/2 David Cournapeau <cournape at gmail.com>:
>> On Fri, Jul 2, 2010 at 9:09 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>>> Great post, Tarek. Following good old newsgroups/FIDOnet tradition it
>>> could be nice to see this transformed to Rules/FAQ document that will
>>> be reposted automatically here by a robot about once a month.
>>>
>>> Without such documents your proposal will be weakly supported, because
>>> people will still have questions, and you will need to answer them
>>> reasonably to eliminate the source of conflict for making
>>> collaboration moving into the right direction (which you also need to
>>> define).
>>>
>>> 1. Why the rules?
>>>> From time to time this mailing list is getting very unpleasant to work
>>>> in because some old disagreements, and because some people are
>>>> starting to get really nasty.
>>>
>>> 2. What are those 'disagreements' people can agree upon?
>>
>> I think the following in uncontroversial:
>>
>> distutils and setuptools are useful packaging solutions which have
>> significant shortcoming, both design and implementation-wise. Some
>> people believe the distutils/setuptools/distribute issues can be
>> solved by gradually deprecating code and adding new features, other
>> people (me, but I am not alone) believe it would be better and faster
>> to rewrite something from scratch because the distutils code is
>> unmanageable and too complicated.
>
> You keep saying that for years, but in the meantime, the code was cleaned.

I was just summarizing the situation to answer the original question
from the OP. There was absolutely no judgement in the text I have
written.

David

From pje at telecommunity.com  Fri Jul  2 16:00:02 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 02 Jul 2010 10:00:02 -0400
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.c
 om>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
Message-ID: <20100702135957.ED3433A4099@sparrow.telecommunity.com>

At 12:08 PM 7/2/2010 +0200, Tarek Ziad? wrote:
>Hello,
>
> From time to time this mailing list is getting very unpleasant to work
>in because some old disagreements,
>and because some people are starting to get really nasty.
>
>Here's a reminder of the current packaging situation, and a few rules
>I suggest, for the benefit of all
>
>1. Python <= 2.7 contains Distutils
>
>2. Distutils is frozen, and won't evolve anymore
>
>3. Setuptools is built on Distutils
>
>4. Distribute forks Setuptools for various reasons. If you disagree
>with this choice, there's no need to send a mail here, because this
>     is done. You can send me a private mail, but don't send a mail
>here because things are always getting nasty afterwards.
>     Make sure to read the archives first, to understand why it was done.
>
>5. Debian, Ubuntu and Fedora are using Distribute rather than
>Setuptools. If you find differences in the behavior, you can send
>     a mail in this list, so we can fix Distribute. If you disagree
>with the distros choice, there's no need to send a mail here,
>     because this is done. You can send *them* a mail, or tell them you
>disagree with this choice.
>     Of course, the most effective behavior would be to work on having
>Distribute fixed if you find an issue, but that's up to you.
>
>6. Distutils2 is being built, and has its own mailing list now.
>Distutils2 will replace Distutils in Python 3.2 or 3.3.
>     It' s built on the various PEPs that were accepted lately, and any
>help is welcome..
>     The list is here:
>http://groups.google.fr/group/the-fellowship-of-the-packaging, and is
>moderated.
>
>7. New members of the lists will not know the situation, so they won't
>be able to follow these rules of course. But people that
>     are hanging around here for years can apply them.
>
>Of course this is just a series of suggestion. You can disagree with
>all these rules if you want, but I think they need to be applied in
>this mailing-list for the benefit of all.

Isn't it interesting how these rules prohibit open disagreement or 
criticism (or even discussion!) of distribute and related matters, 
but *not* setuptools?

I mean, if I realized that as the maintainer of a package that people 
were openly criticizing here, I could just post a list of rules to 
the SIG and prohibit it, I might've done that five years 
ago.  ;-)  (Nah, not really.  But I'm certainly amused by how you've 
suddenly become concerned with "tone" in the SIG as soon as you get 
ONE person who's unhappy with distribute.)

On a separate note, I'm curious why discussion of Distutils2 
development is not in a formal Python SIG, such as the Distutils-SIG.


From ziade.tarek at gmail.com  Fri Jul  2 16:00:15 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 16:00:15 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
Message-ID: <AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>

On Fri, Jul 2, 2010 at 3:42 PM, David Cournapeau <cournape at gmail.com> wrote:
[..]
>>>
>>> I think the following in uncontroversial:
>>>
>>> distutils and setuptools are useful packaging solutions which have
>>> significant shortcoming, both design and implementation-wise. Some
>>> people believe the distutils/setuptools/distribute issues can be
>>> solved by gradually deprecating code and adding new features, other
>>> people (me, but I am not alone) believe it would be better and faster
>>> to rewrite something from scratch because the distutils code is
>>> unmanageable and too complicated.
>>
>> You keep saying that for years, but in the meantime, the code was cleaned.
>
> I was just summarizing the situation to answer the original question
> from the OP. There was absolutely no judgement in the text I have
> written.

You are judging that distutils code is unmanageable and too complicated,
and stating that this is an uncontroversial statement about the
current situation.

This would have perfectly answered to the question 3 years ago, but
this is not the reality
anymore. So I am just describing the situation as it is in reality, because I
know exactly the status of Distutils.

From cournape at gmail.com  Fri Jul  2 16:05:33 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 23:05:33 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
Message-ID: <AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>

On Fri, Jul 2, 2010 at 11:00 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 3:42 PM, David Cournapeau <cournape at gmail.com> wrote:
> [..]
>>>>
>>>> I think the following in uncontroversial:
>>>>
>>>> distutils and setuptools are useful packaging solutions which have
>>>> significant shortcoming, both design and implementation-wise. Some
>>>> people believe the distutils/setuptools/distribute issues can be
>>>> solved by gradually deprecating code and adding new features, other
>>>> people (me, but I am not alone) believe it would be better and faster
>>>> to rewrite something from scratch because the distutils code is
>>>> unmanageable and too complicated.
>>>
>>> You keep saying that for years, but in the meantime, the code was cleaned.
>>
>> I was just summarizing the situation to answer the original question
>> from the OP. There was absolutely no judgement in the text I have
>> written.
>
> You are judging that distutils code is unmanageable and too complicated,
> and stating that this is an uncontroversial statement about the
> current situation.

This is not what I said. The judgement you mention was clearly stated
as my own opinion, not as an uncontroversial point.

David

From cournape at gmail.com  Fri Jul  2 16:09:48 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 23:09:48 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <20100702135957.ED3433A4099@sparrow.telecommunity.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
Message-ID: <AANLkTikP8I0jtKZy2HpfOlW-5u0npbF3BiP1eA2UhZP1@mail.gmail.com>

On Fri, Jul 2, 2010 at 11:00 PM, P.J. Eby <pje at telecommunity.com> wrote:

>
> Isn't it interesting how these rules prohibit open disagreement or criticism
> (or even discussion!) of distribute and related matters, but *not*
> setuptools?

You noticed that too :)

David

From ziade.tarek at gmail.com  Fri Jul  2 16:13:27 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 16:13:27 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <20100702135957.ED3433A4099@sparrow.telecommunity.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
Message-ID: <AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>

On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje at telecommunity.com> wrote:
[..]
> Isn't it interesting how these rules prohibit open disagreement or criticism
> (or even discussion!) of distribute and related matters, but *not*
> setuptools?

There's a huge gap between criticism + discussion, and the habitual flame
of distribute vs setuptools. I think you know what I mean.

Feel free to propose some changes on these rules, because I think you would
be as happy as I would not to have to deal with flames like that.

>
> I mean, if I realized that as the maintainer of a package that people were
> openly criticizing here, I could just post a list of rules to the SIG and
> prohibit it, I might've done that five years ago. ?;-) ?(Nah, not really.
> ?But I'm certainly amused by how you've suddenly become concerned with
> "tone" in the SIG as soon as you get ONE person who's unhappy with
> distribute.)

I've posted now because Distutils-SIG for some time was a peaceful place again,
then a thread started a new unuseful flame again.

>
> On a separate note, I'm curious why discussion of Distutils2 development is
> not in a formal Python SIG, such as the Distutils-SIG.

To avoid such threads and flames. I am moderating the list over there
because I don't want
the ambiance to become as bad as distutils-SIG. I am not the
maintainer of Distutils-SIG, and I am just making some suggestions to
try to improve the situation.

I would like the GSOC student to work in a friendly environment and
not have them to deal with annoying threads. They are sending mails at
distutils-SIG from time to time, but the work happens there. Maybe the
list will disappear at some point if distutils-SIG become a friendlier
place.

You are welcome to join and work with us on distutils2 there,

From cournape at gmail.com  Fri Jul  2 16:18:52 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 2 Jul 2010 23:18:52 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
	<AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
Message-ID: <AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>

On Fri, Jul 2, 2010 at 11:16 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 4:05 PM, David Cournapeau <cournape at gmail.com> wrote:
>> On Fri, Jul 2, 2010 at 11:00 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> On Fri, Jul 2, 2010 at 3:42 PM, David Cournapeau <cournape at gmail.com> wrote:
>>> [..]
>>>>>>
>>>>>> I think the following in uncontroversial:
>>>>>>
>>>>>> distutils and setuptools are useful packaging solutions which have
>>>>>> significant shortcoming, both design and implementation-wise. Some
>>>>>> people believe the distutils/setuptools/distribute issues can be
>>>>>> solved by gradually deprecating code and adding new features, other
>>>>>> people (me, but I am not alone) believe it would be better and faster
>>>>>> to rewrite something from scratch because the distutils code is
>>>>>> unmanageable and too complicated.
>>>>>
>>>>> You keep saying that for years, but in the meantime, the code was cleaned.
>>>>
>>>> I was just summarizing the situation to answer the original question
>>>> from the OP. There was absolutely no judgement in the text I have
>>>> written.
>>>
>>> You are judging that distutils code is unmanageable and too complicated,
>>> and stating that this is an uncontroversial statement about the
>>> current situation.
>>
>> This is not what I said. The judgement you mention was clearly stated
>> as my own opinion, not as an uncontroversial point.
>
> maybe so, but we need an answer with facts that are not mixing opinions. e.g. :
>
> "distutils2 is built with distutils code in a backward incompatible way"

And how does this answer the question "what are the disagreements" ?
Short of saying what those are, I fail to see how to give a good
answer,

David

From ziade.tarek at gmail.com  Fri Jul  2 16:16:28 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 16:16:28 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
Message-ID: <AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>

On Fri, Jul 2, 2010 at 4:05 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 11:00 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Fri, Jul 2, 2010 at 3:42 PM, David Cournapeau <cournape at gmail.com> wrote:
>> [..]
>>>>>
>>>>> I think the following in uncontroversial:
>>>>>
>>>>> distutils and setuptools are useful packaging solutions which have
>>>>> significant shortcoming, both design and implementation-wise. Some
>>>>> people believe the distutils/setuptools/distribute issues can be
>>>>> solved by gradually deprecating code and adding new features, other
>>>>> people (me, but I am not alone) believe it would be better and faster
>>>>> to rewrite something from scratch because the distutils code is
>>>>> unmanageable and too complicated.
>>>>
>>>> You keep saying that for years, but in the meantime, the code was cleaned.
>>>
>>> I was just summarizing the situation to answer the original question
>>> from the OP. There was absolutely no judgement in the text I have
>>> written.
>>
>> You are judging that distutils code is unmanageable and too complicated,
>> and stating that this is an uncontroversial statement about the
>> current situation.
>
> This is not what I said. The judgement you mention was clearly stated
> as my own opinion, not as an uncontroversial point.

maybe so, but we need an answer with facts that are not mixing opinions. e.g. :

"distutils2 is built with distutils code in a backward incompatible way"

From ziade.tarek at gmail.com  Fri Jul  2 16:29:43 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 16:29:43 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
	<AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
	<AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>
Message-ID: <AANLkTimqQx174JDv0YU5M-nVIPxSRWlgBW9VAFzA1aiZ@mail.gmail.com>

On Fri, Jul 2, 2010 at 4:18 PM, David Cournapeau <cournape at gmail.com> wrote:
> And how does this answer the question "what are the disagreements" ?
> Short of saying what those are, I fail to see how to give a good
> answer,

I am not sure to understand your point here. You stated two years ago, IIRC,
that distutils code was unmanageable and too complicated, and that a
write from scracth
was better.

Since then, Guido has decided that the new distutils would be built in
a new namespace,
with no backward compatibility in the APIs.

I think that partially gives you what you wanted: we can break
everything in it for the new version. Last, the code was cleaned up,
pep8-fied, etc and 5 GSOC students are working in it.

So what is your disagreement on the distutils devenir precisely ?

Either you work on distutils2, and propose big changes etc. (we
welcome you, as I said manby times)

Either you work on your side, and propose an alternative solution, but
there's no point to criticize what the distutils team is doing

but let's not mix things, the disagreements between setuptools and
distribute is a different issue than what we are doing in distutils.

From merwok at netwok.org  Fri Jul  2 16:32:33 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 02 Jul 2010 16:32:33 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
Message-ID: <4C2DF881.2080204@netwok.org>

*puts linguist apprentice hat on*

David?s message was saying it was uncontroversial that there was a
controversy. So his judgment *was* stated as his own, but there was a
parsing ambiguity (is the part after ?because? a fact or still the
opinion?) that tripped Tarek.

*puts hat off*

Regards


From cournape at gmail.com  Fri Jul  2 17:05:01 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 3 Jul 2010 00:05:01 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimqQx174JDv0YU5M-nVIPxSRWlgBW9VAFzA1aiZ@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
	<AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
	<AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>
	<AANLkTimqQx174JDv0YU5M-nVIPxSRWlgBW9VAFzA1aiZ@mail.gmail.com>
Message-ID: <AANLkTikonlG664oUK_VygtPb5ls2tJMXCip9iEE3mksS@mail.gmail.com>

On Fri, Jul 2, 2010 at 11:29 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 4:18 PM, David Cournapeau <cournape at gmail.com> wrote:
>> And how does this answer the question "what are the disagreements" ?
>> Short of saying what those are, I fail to see how to give a good
>> answer,
>
> I am not sure to understand your point here. You stated two years ago, IIRC,
> that distutils code was unmanageable and too complicated, and that a
> write from scracth
> was better.

I am sorry if I gave the impression I wanted to start again this
discussion. I really do not want to, and I don't think anyone else
does either. Eric stated very cleary what was my intention.

As for where distutils2 is going, we (me and other scipy people) have
stated why we *believed* (and still do) it was a wrong way when Guido
asked about it in the context of scipy, and I don't remember having
mentioned my disagreement over this ever since. It is pretty obvious
you won't change your mind, and I won't change mine either.

You will notice that I have almost never mentioned my own project on
this mailing list to avoid giving the impression I wanted to
circumvent what you are doing, I explicitly requested not to send
email about it on this ML for that exact reason. And I still give what
I believe are useful advices from time to time for people using
distutils/setuptools on this ML (without telling them: use bento
instead).

David

From g.brandl at gmx.net  Fri Jul  2 17:44:07 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 02 Jul 2010 17:44:07 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
Message-ID: <i0l1jg$eq9$1@dough.gmane.org>

Am 02.07.2010 16:13, schrieb Tarek Ziad?:
> On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje at telecommunity.com> wrote:
> [..]
>> Isn't it interesting how these rules prohibit open disagreement or criticism
>> (or even discussion!) of distribute and related matters, but *not*
>> setuptools?
> 
> There's a huge gap between criticism + discussion, and the habitual flame
> of distribute vs setuptools. I think you know what I mean.
> 
> Feel free to propose some changes on these rules, because I think you would
> be as happy as I would not to have to deal with flames like that.

Tarek, as a more or less neutral observer, I have to agree that you seem
to react a bit sensitive to anything that could be construed as a flame
against distribute or the decision to fork.

I know the reasons for that decision, and I probably would have done the same,
but you need to be aware that there is always irritation in the community
when such a disruptive fork happens, and no small part of that irritation is
directed against the newcomer.  I would try to see this list as on-topic for
both distribute and setuptools, and let each maintainer/group handle the
discussion about his/their tool.

Trying to set up rules for this list isn't helpful; even if your rules don't
seem like rules, but facts to me.  In this case, Anatoly's suggestion to codify
them in a sort of FAQ document and post them on the web or regularly here seems
like a good one.

cheers,
Georg
-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From ziade.tarek at gmail.com  Fri Jul  2 17:54:27 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 17:54:27 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTikonlG664oUK_VygtPb5ls2tJMXCip9iEE3mksS@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
	<AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
	<AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>
	<AANLkTimqQx174JDv0YU5M-nVIPxSRWlgBW9VAFzA1aiZ@mail.gmail.com>
	<AANLkTikonlG664oUK_VygtPb5ls2tJMXCip9iEE3mksS@mail.gmail.com>
Message-ID: <AANLkTimdhsgesX8NjMY39oxlQU1EsftMmW3XjNeBAA1y@mail.gmail.com>

On Fri, Jul 2, 2010 at 5:05 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 11:29 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Fri, Jul 2, 2010 at 4:18 PM, David Cournapeau <cournape at gmail.com> wrote:
>>> And how does this answer the question "what are the disagreements" ?
>>> Short of saying what those are, I fail to see how to give a good
>>> answer,
>>
>> I am not sure to understand your point here. You stated two years ago, IIRC,
>> that distutils code was unmanageable and too complicated, and that a
>> write from scracth
>> was better.
>
> I am sorry if I gave the impression I wanted to start again this
> discussion. I really do not want to, and I don't think anyone else
> does either. Eric stated very cleary what was my intention.

Ok, I am also sorry if I understood it the wrong way.

> As for where distutils2 is going, we (me and other scipy people) have
> stated why we *believed* (and still do) it was a wrong way when Guido
> asked about it in the context of scipy, and I don't remember having
> mentioned my disagreement over this ever since. It is pretty obvious
> you won't change your mind, and I won't change mine either.

This is precisely where I don't understand.

When this happened, I've asked you what should be done to improve,
and you gave a few  ideas on the build system. We are building it
*now*, and *you* can
make distutils2 goes where you want it to go..

As a matter of fact there's a student (Eric) working on this, and it follows
your idea of separating the build configuration from other commands.
It would have been great to have your guidance in this.

Now if you want to work on a new project, that's perfectly fine, and
even more fun.
And that's good for distutils because at some point we could work on
the same standards.

But don't say it's because we disagree, because you could have what
you want in distutils2 today..

From ziade.tarek at gmail.com  Fri Jul  2 18:01:03 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 2 Jul 2010 18:01:03 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <i0l1jg$eq9$1@dough.gmane.org>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
Message-ID: <AANLkTillvXCqH9xCN9Adjieh1ADXZcXp4Q1BG-5lA_q7@mail.gmail.com>

On Fri, Jul 2, 2010 at 5:44 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 02.07.2010 16:13, schrieb Tarek Ziad?:
>> On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> [..]
>>> Isn't it interesting how these rules prohibit open disagreement or criticism
>>> (or even discussion!) of distribute and related matters, but *not*
>>> setuptools?
>>
>> There's a huge gap between criticism + discussion, and the habitual flame
>> of distribute vs setuptools. I think you know what I mean.
>>
>> Feel free to propose some changes on these rules, because I think you would
>> be as happy as I would not to have to deal with flames like that.
>
> Tarek, as a more or less neutral observer, I have to agree that you seem
> to react a bit sensitive to anything that could be construed as a flame
> against distribute or the decision to fork.

Probaly so, that's why I would like PJE to help building that FAQ, just to make
sure it's not biased.

Because you have to admit that the flames here, whether they are
directed to distribute or setuptools, are unnecessary pain, and higher
than in other lists.

My intent to make rules so Distutils-SIG is peaceful, is a benefit for
all parties.

>
> I know the reasons for that decision, and I probably would have done the same,
> but you need to be aware that there is always irritation in the community
> when such a disruptive fork happens, and no small part of that irritation is
> directed against the newcomer. ?I would try to see this list as on-topic for
> both distribute and setuptools, and let each maintainer/group handle the
> discussion about his/their tool.
>
> Trying to set up rules for this list isn't helpful; even if your rules don't
> seem like rules, but facts to me. ?In this case, Anatoly's suggestion to codify
> them in a sort of FAQ document and post them on the web or regularly here seems
> like a good one.

I agree, let's build this.

From g.brandl at gmx.net  Fri Jul  2 18:21:17 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 02 Jul 2010 18:21:17 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTillvXCqH9xCN9Adjieh1ADXZcXp4Q1BG-5lA_q7@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>	<20100702135957.ED3433A4099@sparrow.telecommunity.com>	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTillvXCqH9xCN9Adjieh1ADXZcXp4Q1BG-5lA_q7@mail.gmail.com>
Message-ID: <i0l3p5$n0s$1@dough.gmane.org>

Am 02.07.2010 18:01, schrieb Tarek Ziad?:
> On Fri, Jul 2, 2010 at 5:44 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>> Am 02.07.2010 16:13, schrieb Tarek Ziad?:
>>> On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje at telecommunity.com> wrote:
>>> [..]
>>>> Isn't it interesting how these rules prohibit open disagreement or criticism
>>>> (or even discussion!) of distribute and related matters, but *not*
>>>> setuptools?
>>>
>>> There's a huge gap between criticism + discussion, and the habitual flame
>>> of distribute vs setuptools. I think you know what I mean.
>>>
>>> Feel free to propose some changes on these rules, because I think you would
>>> be as happy as I would not to have to deal with flames like that.
>>
>> Tarek, as a more or less neutral observer, I have to agree that you seem
>> to react a bit sensitive to anything that could be construed as a flame
>> against distribute or the decision to fork.
> 
> Probaly so, that's why I would like PJE to help building that FAQ, just to make
> sure it's not biased.

That's a good idea!

> Because you have to admit that the flames here, whether they are
> directed to distribute or setuptools, are unnecessary pain, and higher
> than in other lists.

Well, every list has its own problem, look at python-dev...

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From pje at telecommunity.com  Fri Jul  2 19:52:07 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 02 Jul 2010 13:52:07 -0400
Subject: [Distutils] Packaging situation + mailing list rules
Message-ID: <20100702175158.AA1593A4099@sparrow.telecommunity.com>

At 04:13 PM 7/2/2010 +0200, Tarek Ziad? wrote:
>On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje at telecommunity.com> wrote:
>[..]
> > Isn't it interesting how these rules prohibit open disagreement 
> or criticism
> > (or even discussion!) of distribute and related matters, but *not*
> > setuptools?
>
>There's a huge gap between criticism + discussion, and the habitual flame
>of distribute vs setuptools. I think you know what I mean.

Since, as far as I can tell, David's are the first negative comments 
I've seen regarding distribute, the only "habitual" flame I'm aware 
of would be people spreading falsehoods about setuptools.

I personally don't consider mere criticism of setuptools' or 
distribute's code or policies to be flaming.


> > On a separate note, I'm curious why discussion of Distutils2 development is
> > not in a formal Python SIG, such as the Distutils-SIG.
>
>To avoid such threads and flames.

Vigorous discussion is a normal part of life in a Python SIG, or any 
standards-development process.  Lots of people have said plenty of 
mean and nasty things about setuptools here (and to a lesser extent, 
people said them about WSGI when I started that effort), but I have 
never called for them to be silenced.

The only thing I object to is people making statements that they know 
(or should know) are false, or to people speaking with flagrant 
disregard for the truth in an apparent effort to score political points.

There is *huge* difference to me between, "Hey PJ, I hate setuptools 
and it sucks!" and "Nobody should use setuptools because it is unmaintained."

Regarding the first one, I say, "Sorry to hear that, good luck to you 
with your future endeavors."  The second one, however, is FUD and an 
unnecessary smear tactic.

And I find it strange that many distribute supporters seem to prefer 
this approach over highlighting distribute's *actual* distinctions 
from setuptools, such as (not a complete list):

* It has more tests
* It runs on Python 3
* It supports 2.6+ "user" directories
* It is released more frequently
* We review patches more quickly
* It's available in Mercurial, so you can more easily track local 
changes and participate in development

(And even *I* agree that these are all benefits for many people.)

However, perhaps it's a reflection of the fact that these benefits 
are NOT universally salient -- for many people, not one of these 
improvements is important enough to merit switching.  So, if someone 
has other reasons than *user benefit* for wanting everyone else to 
switch, then perhaps they are forced to resort to FUD to motivate 
people to switch.

And THAT is what I find distasteful.  If you want people to switch 
because it is *actually* better for them, then more power to 
you.  However, trying to persuade people to switch for *political* 
reasons -- reasons that will not provide any actual *benefit* to the 
switchers -- that's just disgusting.

If people want to get creative in their presentations of the truth, 
please stick to exaggerating the advantages of distribute, rather 
than exaggerating the disadvantages of setuptools.  The former is to 
be expected, the latter is unnecessary nastiness...  especially since 
I bend over backwards *not* to say bad things about distribute, even 
when I'm more or less forced to comment on technical differences 
between the two.

Indeed, I take especial care to treat them as mere stylistic 
differences, even when I think that distribute's choices will 
actually lead to problems for a given user's use case, simply because 
I don't want to deal with the flaming that ensues any time I say 
something that can remotely be construed as a criticism of 
distribute.  (Consider the brouhaha that erupted the time I simply 
stated that if people wanted to upgrade to the latest setuptools, 
they would need to uninstall distribute first -- which is a mere 
technical fact caused by the way distribute operates!)


From tseaver at palladion.com  Fri Jul  2 20:29:20 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 02 Jul 2010 14:29:20 -0400
Subject: [Distutils] setuptools' "Feature" feature
Message-ID: <i0lb61$hao$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I haven't found any docs (outside the code) for the
setuptools.dist.Feature, or for how it operates with the rest of the
ecosystem.  Can somebody confirm or correct my understanding of them?

- - Feature instances represent optionally-included bits of the
  distribution.

- - Normally, features are disabled by default, and can be enabled
  by passing '--with-<featurename>' to setup.py.

- - Features declared as 'standard' are enabled by default, and can be
  disabled by passing '--without-<featurename>' to setup.py.

- - Features have an 'available' attribute, which can be set to False
  in setup.py to disable a feature based on runtime introspection
  (e.g., using sys.version_info or os.name).

- - It appears that it should be possible to pass an instance with
  a '__nonzero__' method as the 'available':  the code seems only
  to use it in boolean tests.

- - Features may depend on (force inclusion of) other features.

- - Enabled features do their actual work by adding **kwargs to
  the args passed directly to setup.py

- - Distributions created via an invocation to setup.py are not labeled
  in any way to indicate any '--with-<featurename>' (or '--without')
  passed to setup.py during their creation.

- - There is no way to enable / disable a feature when installing a
  distribution via easy_install.

The particular use case which led me to investigate Features was easing
packaging of projects with optional C extensions, such that they could
be installable on Jython, IronPython, Windows, or GAE.  It doesn't seem
possible to figure out whether a compiler actually exists:  jython's
distutils lies and creates a compiler which raises exceptions, for instance.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwuL/oACgkQ+gerLs4ltQ6gSACdHkbS6vic9+/ovRutN9c5Rue3
QBcAn176C4btyAU4j2AGlMsupviUxsTI
=KAKk
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Sat Jul  3 00:18:14 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 02 Jul 2010 18:18:14 -0400
Subject: [Distutils] setuptools' "Feature" feature
In-Reply-To: <i0lb61$hao$1@dough.gmane.org>
References: <i0lb61$hao$1@dough.gmane.org>
Message-ID: <20100702221808.5D0463A4099@sparrow.telecommunity.com>

At 02:29 PM 7/2/2010 -0400, Tres Seaver wrote:
>I haven't found any docs (outside the code) for the
>setuptools.dist.Feature,

That's because it's essentially deprecated - an experimental thing 
that turned out to be, well, a failed experiment.

The problem is that there really needed to be better ways to store 
the build state with respect to features, not to mention 
distribution-level information about them.  So, they only work 
correctly if you pass them to *every* setup.py command, while never 
changing them.  To really work right, there'd need to be a 
"configure" command, and some sort of option storage.

And, since most of the *other* use cases for the original features 
design were supplanted by "extras" and install_requires, it was 
pretty much left to optional C extensions, which might as well be 
handled by, well, optional C extensions.  ;-)

So, I haven't done anything with features in ages, and didn't 
document them because (AFAIK), they were only used by some ancient 
packages of my own, such as the original PEAK mega-distribution, 
PyProtocols, and RuleDispatch -- mostly to enable or disable various 
C extensions.


>- - Feature instances represent optionally-included bits of the
>   distribution.
>
>- - Normally, features are disabled by default, and can be enabled
>   by passing '--with-<featurename>' to setup.py.
>
>- - Features declared as 'standard' are enabled by default, and can be
>   disabled by passing '--without-<featurename>' to setup.py.
>
>- - Features have an 'available' attribute, which can be set to False
>   in setup.py to disable a feature based on runtime introspection
>   (e.g., using sys.version_info or os.name).
>
>- - It appears that it should be possible to pass an instance with
>   a '__nonzero__' method as the 'available':  the code seems only
>   to use it in boolean tests.
>
>- - Features may depend on (force inclusion of) other features.
>
>- - Enabled features do their actual work by adding **kwargs to
>   the args passed directly to setup.py
>
>- - Distributions created via an invocation to setup.py are not labeled
>   in any way to indicate any '--with-<featurename>' (or '--without')
>   passed to setup.py during their creation.
>
>- - There is no way to enable / disable a feature when installing a
>   distribution via easy_install.
>
>The particular use case which led me to investigate Features was easing
>packaging of projects with optional C extensions, such that they could
>be installable on Jython, IronPython, Windows, or GAE.  It doesn't seem
>possible to figure out whether a compiler actually exists:  jython's
>distutils lies and creates a compiler which raises exceptions, for instance.

Yeah, that's another reason why Features don't even do the optional 
compile thing that well.  Not Jython specifically, but rather, I 
never decided on a good way to handle optional C extensions, that 
doesn't involve trapping compilation errors.  (I hope distutils2 
allows you to declare extensions optional; it's such a common use case.)


From cournape at gmail.com  Sat Jul  3 02:13:33 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 3 Jul 2010 09:13:33 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimdhsgesX8NjMY39oxlQU1EsftMmW3XjNeBAA1y@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
	<AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
	<AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>
	<AANLkTimqQx174JDv0YU5M-nVIPxSRWlgBW9VAFzA1aiZ@mail.gmail.com>
	<AANLkTikonlG664oUK_VygtPb5ls2tJMXCip9iEE3mksS@mail.gmail.com>
	<AANLkTimdhsgesX8NjMY39oxlQU1EsftMmW3XjNeBAA1y@mail.gmail.com>
Message-ID: <AANLkTinSCqVoOVsu5PQAYeepMb3qft14IjIhETlcEelz@mail.gmail.com>

On Sat, Jul 3, 2010 at 12:54 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 5:05 PM, David Cournapeau <cournape at gmail.com> wrote:
>> On Fri, Jul 2, 2010 at 11:29 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> On Fri, Jul 2, 2010 at 4:18 PM, David Cournapeau <cournape at gmail.com> wrote:
>>>> And how does this answer the question "what are the disagreements" ?
>>>> Short of saying what those are, I fail to see how to give a good
>>>> answer,
>>>
>>> I am not sure to understand your point here. You stated two years ago, IIRC,
>>> that distutils code was unmanageable and too complicated, and that a
>>> write from scracth
>>> was better.
>>
>> I am sorry if I gave the impression I wanted to start again this
>> discussion. I really do not want to, and I don't think anyone else
>> does either. Eric stated very cleary what was my intention.
>
> Ok, I am also sorry if I understood it the wrong way.
>
>> As for where distutils2 is going, we (me and other scipy people) have
>> stated why we *believed* (and still do) it was a wrong way when Guido
>> asked about it in the context of scipy, and I don't remember having
>> mentioned my disagreement over this ever since. It is pretty obvious
>> you won't change your mind, and I won't change mine either.
>
> This is precisely where I don't understand.

Here is my understanding of what happened: as we   (we being at least
a couple of major maintainers in the numpy community) understood it 6
months ago in the "we want CPAN" thread started by Guido, the idea was
to gradually evolve from the existing code to whatever distutils2 aims
up to be. Because several attempts have been made to do so by
proeminent numpy developers in the last decade, we have the
*experience* that this could not work, at least for us.

Certainly, there was a failure from us to communicate what's wrong
with current distutils design, but the situation is still the same
today: absolutely none of the thing that distribute2 is working on is
an improvement for us. None of the recent PEP addresses any
significant issue for us. We don't care about pypi as is, we don't
care about complex requirement/versioning, we don't care about
uninstall, etc... We simply do not agree in any significant way on the
distutils issues. If you look at bento goals, they do not even attempt
to solve any issue raised in the recent PEP.

And again, I am not saying this to criticize your work (or anyone's
else). Surely, I cannot complain that you or someone's else is not
working on my issues. But I think it is a good reason to go on our
separate ways to implement a solution, at least for now.

David

From ziade.tarek at gmail.com  Sat Jul  3 02:53:30 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 3 Jul 2010 02:53:30 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTinSCqVoOVsu5PQAYeepMb3qft14IjIhETlcEelz@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
	<AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
	<AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>
	<AANLkTimqQx174JDv0YU5M-nVIPxSRWlgBW9VAFzA1aiZ@mail.gmail.com>
	<AANLkTikonlG664oUK_VygtPb5ls2tJMXCip9iEE3mksS@mail.gmail.com>
	<AANLkTimdhsgesX8NjMY39oxlQU1EsftMmW3XjNeBAA1y@mail.gmail.com>
	<AANLkTinSCqVoOVsu5PQAYeepMb3qft14IjIhETlcEelz@mail.gmail.com>
Message-ID: <AANLkTikvf5bqvLs8-nEsbDRjl_rcHrYbZ2ERE7ebWFRk@mail.gmail.com>

On Sat, Jul 3, 2010 at 2:13 AM, David Cournapeau <cournape at gmail.com> wrote:
[..]
>> This is precisely where I don't understand.
>
> Here is my understanding of what happened: as we ? (we being at least
> a couple of major maintainers in the numpy community) understood it 6
> months ago in the "we want CPAN" thread started by Guido, the idea was
> to gradually evolve from the existing code to whatever distutils2 aims
> up to be. Because several attempts have been made to do so by
> proeminent numpy developers in the last decade, we have the
> *experience* that this could not work, at least for us.

All these attempts were doomed to fail, because of the backward
compatibility issues.
I was hit by that too. But this barrier is gone, because we are
working on a new namespace. Which means that we can build whatever we
want now in distutils2.

And the build process is the part that can be entirely redone. But you
didn't answer on that. This was your main critic against distutils.
ISTM that this is precisely what we could improve wrt the usage of
distutils in sci

>
> Certainly, there was a failure from us to communicate what's wrong
> with current distutils design, but the situation is still the same
> today: absolutely none of the thing that distribute2 is working on is
> an improvement for us. None of the recent PEP addresses any
> significant issue for us. We don't care about pypi as is, we don't
> care about complex requirement/versioning, we don't care about
> uninstall, etc... We simply do not agree in any significant way on the
> distutils issues. If you look at bento goals, they do not even attempt
> to solve any issue raised in the recent PEP.

This is not entirely true, as far as I understand your work. For example,
we are currently removing setup.py in favor of 100% static definitions
using setup.cfg,
thanks to PEP 345 / 390. (Bento seems to have similar static files now)

Overall, I am curious to know what are your issues, if it not about
the building process and the definition of metadata.

>
> And again, I am not saying this to criticize your work (or anyone's
> else). Surely, I cannot complain that you or someone's else is not
> working on my issues. But I think it is a good reason to go on our
> separate ways to implement a solution, at least for now.

I know you want to work on your side, and I am not criticizing that.

I am just very skeptical that your issues are so different from the issues
we are working in distutils2.

From cournape at gmail.com  Sat Jul  3 03:33:29 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 3 Jul 2010 10:33:29 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTikvf5bqvLs8-nEsbDRjl_rcHrYbZ2ERE7ebWFRk@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<AANLkTik6HLW6P4XWdUzsA_a4Cq90NYYPEJfS_cziPwkY@mail.gmail.com>
	<AANLkTimNLieGjEdI2V1X97zdHjjfmMTk3ANNuuUI4D8V@mail.gmail.com>
	<AANLkTik-8kZieahR9Rlxcp8gzm9VLIKOvddI3G4hXo2d@mail.gmail.com>
	<AANLkTimqVQ2IEUrtVFIKg8oG0aeLv19qrJaXAFESlOnn@mail.gmail.com>
	<AANLkTim0c5mEn8FhvsNU-Fqli-YrUtXxtJe2F2kcAY7W@mail.gmail.com>
	<AANLkTikQGkjZbtIvBjDXB2rJq5virvY2b1RMxVqdkVdb@mail.gmail.com>
	<AANLkTikSM7BO6JmItUTfQX95-Kw-lyOgrUKiYHdej3TP@mail.gmail.com>
	<AANLkTinzcblZIKsTd8VMb1XqnNVN9FEGKnOWCLcn0CdE@mail.gmail.com>
	<AANLkTimqQx174JDv0YU5M-nVIPxSRWlgBW9VAFzA1aiZ@mail.gmail.com>
	<AANLkTikonlG664oUK_VygtPb5ls2tJMXCip9iEE3mksS@mail.gmail.com>
	<AANLkTimdhsgesX8NjMY39oxlQU1EsftMmW3XjNeBAA1y@mail.gmail.com>
	<AANLkTinSCqVoOVsu5PQAYeepMb3qft14IjIhETlcEelz@mail.gmail.com>
	<AANLkTikvf5bqvLs8-nEsbDRjl_rcHrYbZ2ERE7ebWFRk@mail.gmail.com>
Message-ID: <AANLkTiksoutj8N1VgMyqcFdRM8Jx109Eau731MNTvGbg@mail.gmail.com>

On Sat, Jul 3, 2010 at 9:53 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

>
> Overall, I am curious to know what are your issues, if it not about
> the building process and the definition of metadata.

Without going into the technical details, it really boils down to
separate the concerns of the different parts of a packaging solution,
and having clear interface between them.

For example, it is *possible* to integrate a new build system within
distutils. I know this for a fact because I have done so (numpy and
scipy can be entirely built with scons instead of distutils for the
C/C++/Fortran extensions). But it was an awful experience.

> I am just very skeptical that your issues are so different from the issues
> we are working in distutils2.

Yes, other people have stated this as well. On the other hand, what I
am doing with bento "feels" obvious within the numpy/scipy community
as far as I can tell. I think it mostly boils down to different
backgrounds and different concerns. If you were building/developing
complex C extensions daily, you would understand our issues much
better from experience, and I guess I would understand better what
distutils2 is about if I were doing web development.

There is also a strong disagreement on how to do deployment - it has
been stated that pypi current philosophy of not enforcing metadata
policy will stay in place, whereas I am absolutely convinced it is the
root of most pypi issues. On this, we will only ever be able to agree
on disagreeing I am afraid.

David

From greg.ewing at canterbury.ac.nz  Sat Jul  3 03:53:34 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 03 Jul 2010 13:53:34 +1200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
Message-ID: <4C2E981E.2070408@canterbury.ac.nz>

Tarek Ziad? wrote:

> 4. Distribute forks Setuptools for various reasons. If you disagree
> with this choice, there's no need to send a mail here

David isn't disagreeing with that choice, as far as I can
see. The *only* thing he's saying is that the fork should
have a different name, because it's a different thing.

I think he has a valid point.

-- 
Greg

From cournape at gmail.com  Sat Jul  3 07:29:00 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 3 Jul 2010 14:29:00 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <i0l1jg$eq9$1@dough.gmane.org>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
Message-ID: <AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>

On Sat, Jul 3, 2010 at 12:44 AM, Georg Brandl <g.brandl at gmx.net> wrote:

> I know the reasons for that decision, and I probably would have done the same

Shall I understand that the hijacking of setuptools by distribute
(instead of merely forking it under a new name, which I don't care
about) is sanctioned by python-dev ?

If so, it should be written somewhere, and justified, because it
impacts people who don't even use the software.

David

From suresh_vv at yahoo.com  Sat Jul  3 07:44:42 2010
From: suresh_vv at yahoo.com (Suresh V.)
Date: Sat, 03 Jul 2010 11:14:42 +0530
Subject: [Distutils] How to force installing setuptools instead of
	distribute ?
In-Reply-To: <20100701155107.999EA3A404D@sparrow.telecommunity.com>
References: <AANLkTimmBJ6SWEvFRCuFFwHlanxbnYBSsFYrsP5lqduz@mail.gmail.com>	<20100701022352.400C63A404D@sparrow.telecommunity.com>	<AANLkTil1gCc1RTgwP-9EFU24b1GpNCtsa4wqyup2iD0o@mail.gmail.com>	<20100701151805.CCDF43A404D@sparrow.telecommunity.com>	<AANLkTilRf3ArjIzusntAyqkPvDtavWngbX5lH0TYkhQn@mail.gmail.com>
	<AANLkTilRf3ArjIzusntAyqkPvDtavWngbX5lH0TYkhQn@mail.gmail.c om>
	<20100701155107.999EA3A404D@sparrow.telecommunity.com>
Message-ID: <4C2ECE4A.30305@yahoo.com>

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 <pje at 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


From merwok at netwok.org  Sat Jul  3 08:10:32 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 03 Jul 2010 08:10:32 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>	<20100702135957.ED3433A4099@sparrow.telecommunity.com>	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
Message-ID: <4C2ED458.50607@netwok.org>

[David Cournapeau]
> [Georg Brandl]> 
>> I know the reasons for that decision, and I probably would have done the same
> Shall I understand that the hijacking of setuptools by distribute
> (instead of merely forking it under a new name, which I don't care
> about) is sanctioned by python-dev ?

Setuptools is not a python-dev project, ergo python-dev has no official
position on it. Georg is speaking for himself, albeit with the credit of
his involvement in python-dev.

FTR, when some extreme distribute fans proposed that the PyPI setuptools
entry had to be given to distribute, people (including Guido if my
memory?s not failing) sternly replied that this was rude and unwelcome.

As already stated elsewhere more than once, the fact that distribute
provides the setuptools Python package is a technical requirement.

Regards


From cournape at gmail.com  Sat Jul  3 08:15:33 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 3 Jul 2010 15:15:33 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <4C2ED458.50607@netwok.org>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
Message-ID: <AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>

On Sat, Jul 3, 2010 at 3:10 PM, ?ric Araujo <merwok at netwok.org> wrote:

>
> FTR, when some extreme distribute fans proposed that the PyPI setuptools
> entry had to be given to distribute, people (including Guido if my
> memory?s not failing) sternly replied that this was rude and unwelcome.
>
> As already stated elsewhere more than once, the fact that distribute
> provides the setuptools Python package is a technical requirement.

Ah, sorry about that, I missed it. What is that technical requirement ?

David

From merwok at netwok.org  Sat Jul  3 08:24:10 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 03 Jul 2010 08:24:10 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>	<20100702135957.ED3433A4099@sparrow.telecommunity.com>	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>	<i0l1jg$eq9$1@dough.gmane.org>	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>	<4C2ED458.50607@netwok.org>
	<AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>
Message-ID: <4C2ED78A.3020708@netwok.org>

>> As already stated elsewhere more than once, the fact that distribute
>> provides the setuptools Python package is a technical requirement.
> Ah, sorry about that, I missed it. What is that technical requirement ?

Distribute is a fork of Setupools, so it wants to be a drop-in
replacement, i.e. to be used instead of setuptools with very few code
changes.

Regards


From cournape at gmail.com  Sat Jul  3 08:31:54 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 3 Jul 2010 15:31:54 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <4C2ED78A.3020708@netwok.org>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>
	<4C2ED78A.3020708@netwok.org>
Message-ID: <AANLkTil4BgUAzWNYS6KsroGvoFZNmZ0DxF6emFh2WtZe@mail.gmail.com>

On Sat, Jul 3, 2010 at 3:24 PM, ?ric Araujo <merwok at netwok.org> wrote:
>>> As already stated elsewhere more than once, the fact that distribute
>>> provides the setuptools Python package is a technical requirement.
>> Ah, sorry about that, I missed it. What is that technical requirement ?
>
> Distribute is a fork of Setupools, so it wants to be a drop-in
> replacement, i.e. to be used instead of setuptools with very few code
> changes.

That's not a technical requirement in any sense of the word.

David

From greg.ewing at canterbury.ac.nz  Sat Jul  3 09:32:27 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 03 Jul 2010 19:32:27 +1200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <4C2ED78A.3020708@netwok.org>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>
	<4C2ED78A.3020708@netwok.org>
Message-ID: <4C2EE78B.5030908@canterbury.ac.nz>

?ric Araujo wrote:

> Distribute is a fork of Setupools, so it wants to be a drop-in
> replacement, i.e. to be used instead of setuptools with very few code
> changes.

But is there a technical reason why it *has* to be a
drop-in replacement, as opposed to a different package
with a different name?

-- 
Greg

From ziade.tarek at gmail.com  Sat Jul  3 10:06:42 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 3 Jul 2010 10:06:42 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <4C2EE78B.5030908@canterbury.ac.nz>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>
	<4C2ED78A.3020708@netwok.org> <4C2EE78B.5030908@canterbury.ac.nz>
Message-ID: <AANLkTin-D7TmY_Qj5tNs4zmlw1WgpEwW0qG8yET7v_BL@mail.gmail.com>

On Sat, Jul 3, 2010 at 9:32 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> ?ric Araujo wrote:
>
>> Distribute is a fork of Setupools, so it wants to be a drop-in
>> replacement, i.e. to be used instead of setuptools with very few code
>> changes.
>
> But is there a technical reason why it *has* to be a
> drop-in replacement, as opposed to a different package
> with a different name?

This technical reason was already explained in this mailing list back
then, many times.
Maybe you could read back the relevant threads for more details.

From cournape at gmail.com  Sat Jul  3 12:29:42 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sat, 3 Jul 2010 19:29:42 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTin-D7TmY_Qj5tNs4zmlw1WgpEwW0qG8yET7v_BL@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>
	<4C2ED78A.3020708@netwok.org> <4C2EE78B.5030908@canterbury.ac.nz>
	<AANLkTin-D7TmY_Qj5tNs4zmlw1WgpEwW0qG8yET7v_BL@mail.gmail.com>
Message-ID: <AANLkTinPoIDXVg6bG0VKd_DIDh5QK1uqJekNLGfcNYPZ@mail.gmail.com>

On Sat, Jul 3, 2010 at 5:06 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

>
> This technical reason was already explained in this mailing list back
> then, many times.

Maybe a link would be useful, so that it could referenced somewhere on
distribute main page ?

David

From ziade.tarek at gmail.com  Sat Jul  3 13:07:49 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 3 Jul 2010 13:07:49 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTinPoIDXVg6bG0VKd_DIDh5QK1uqJekNLGfcNYPZ@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>
	<4C2ED78A.3020708@netwok.org> <4C2EE78B.5030908@canterbury.ac.nz>
	<AANLkTin-D7TmY_Qj5tNs4zmlw1WgpEwW0qG8yET7v_BL@mail.gmail.com>
	<AANLkTinPoIDXVg6bG0VKd_DIDh5QK1uqJekNLGfcNYPZ@mail.gmail.com>
Message-ID: <AANLkTilzSoodLr82KnPsZ-3_gVgoR7_CB4AqpA25YvXF@mail.gmail.com>

On Sat, Jul 3, 2010 at 12:29 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Sat, Jul 3, 2010 at 5:06 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>
>>
>> This technical reason was already explained in this mailing list back
>> then, many times.
>
> Maybe a link would be useful, so that it could referenced somewhere on
> distribute main page ?

Yes, as Anatoly suggested, I'll write a Packaging FAQ page, with this
point contained.
Probably in the HHG2P project

>
> David
>



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

From lukshuntim at gmail.com  Sat Jul  3 15:19:06 2010
From: lukshuntim at gmail.com (lukshuntim at gmail.com)
Date: Sat, 03 Jul 2010 21:19:06 +0800
Subject: [Distutils] stdeb- setting build-depends to python-dev
In-Reply-To: <4C2CBAD9.4070601@netwok.org>
References: <4C2C3A30.9040801@gmail.com> <4C2CB5DF.8020405@astraw.com>
	<4C2CBAD9.4070601@netwok.org>
Message-ID: <4C2F38CA.80909@gmail.com>

On 07/01/2010 11:57 PM, ?ric Araujo wrote:
>> (And this is the right place to ask questions about stdeb.)
> I?m sorry, I read the message too fast. stdeb does belong on this list,
> I hope I didn?t sound unfriendly when I made my hasty suggestion. Thanks
> Andrew.
>
> Regards

Hi Eric,

No, I don't mind, :-) and I'm happy to be able to contribute a very tiny 
bit even though I can't contribute code.

Thanks for the help from everybody,
ST
--


From cournape at gmail.com  Sat Jul  3 17:23:59 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 4 Jul 2010 00:23:59 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <4C2ED458.50607@netwok.org>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
Message-ID: <AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>

On Sat, Jul 3, 2010 at 3:10 PM, ?ric Araujo <merwok at netwok.org> wrote:
> [David Cournapeau]
>> [Georg Brandl]>
>>> I know the reasons for that decision, and I probably would have done the same
>> Shall I understand that the hijacking of setuptools by distribute
>> (instead of merely forking it under a new name, which I don't care
>> about) is sanctioned by python-dev ?
>
> Setuptools is not a python-dev project, ergo python-dev has no official
> position on it. Georg is speaking for himself, albeit with the credit of
> his involvement in python-dev.
>
> FTR, when some extreme distribute fans proposed that the PyPI setuptools
> entry had to be given to distribute, people (including Guido if my
> memory?s not failing) sternly replied that this was rude and unwelcome.

I fail to see the difference with the present situation. easy_install
setuptools gives distribute, yolk -T src -F gives distribute.
Distribute is the only fork I have seen in my entire life as an open
source contributor which does this. When the cython people forked
pyrex, they called their fork another name, and the script had another
name.

Besides the numerous technical issues, this is just basic decency. If
I were PJE, I would be very mad.

David

From ziade.tarek at gmail.com  Sat Jul  3 17:59:20 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 3 Jul 2010 17:59:20 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
Message-ID: <AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>

On Sat, Jul 3, 2010 at 5:23 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Sat, Jul 3, 2010 at 3:10 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> [David Cournapeau]
>>> [Georg Brandl]>
>>>> I know the reasons for that decision, and I probably would have done the same
>>> Shall I understand that the hijacking of setuptools by distribute
>>> (instead of merely forking it under a new name, which I don't care
>>> about) is sanctioned by python-dev ?
>>
>> Setuptools is not a python-dev project, ergo python-dev has no official
>> position on it. Georg is speaking for himself, albeit with the credit of
>> his involvement in python-dev.
>>
>> FTR, when some extreme distribute fans proposed that the PyPI setuptools
>> entry had to be given to distribute, people (including Guido if my
>> memory?s not failing) sternly replied that this was rude and unwelcome.
>
> I fail to see the difference with the present situation. easy_install
> setuptools gives distribute, yolk -T src -F gives distribute.
> Distribute is the only fork I have seen in my entire life as an open
> source contributor which does this. When the cython people forked
> pyrex, they called their fork another name, and the script had another
> name.
>
> Besides the numerous technical issues, this is just basic decency. If
> I were PJE, I would be very mad.

Could you stop this now ?  Obviously you didn't read back the threads,
and didn't try
to understand why we forked and the technicals details.

You are just feeding the troll for the heck of it here, so stop it.

From tseaver at palladion.com  Sat Jul  3 18:56:30 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 03 Jul 2010 12:56:30 -0400
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <4C2EE78B.5030908@canterbury.ac.nz>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>	<20100702135957.ED3433A4099@sparrow.telecommunity.com>	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>	<i0l1jg$eq9$1@dough.gmane.org>	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>	<4C2ED458.50607@netwok.org>	<AANLkTimbgrk8NkhDELCrSxOCMYHVCADQR3s3A6oGxNGx@mail.gmail.com>	<4C2ED78A.3020708@netwok.org>
	<4C2EE78B.5030908@canterbury.ac.nz>
Message-ID: <i0nq3v$gf5$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Ewing wrote:
> ?ric Araujo wrote:
> 
>> Distribute is a fork of Setupools, so it wants to be a drop-in
>> replacement, i.e. to be used instead of setuptools with very few code
>> changes.
> 
> But is there a technical reason why it *has* to be a
> drop-in replacement, as opposed to a different package
> with a different name?

The core issue is that distribute was intended to be useful for
installing the hundreds / thousands of distribtions on PyPI which
contain the line:

  from setuptools import setup

and do so because they express dependencies and other metadata which the
stock distutils version of setup() would choke on.  Unless the site
manager could arrange to have distribute install the 'setuptools'
*package* on sys.path, distribute would have been a pointless fork.

I can't comment on reasons why the project (*not* the package) might
grab the 'setuptools' *project* name, as I don't use distribute itself.
 I  don't know how much, if any, of the issue might be with the
particular Debuntu packaging, either, as I never use the system python
for my projects.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwva74ACgkQ+gerLs4ltQ4OnwCg0lRgCLTmbeBUZMFH7Bw/tXVz
GWkAn2twkgnfyqh0MUi1kZOMRPCufcZE
=sTyl
-----END PGP SIGNATURE-----


From ziade.tarek at gmail.com  Sat Jul  3 19:44:34 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 3 Jul 2010 19:44:34 +0200
Subject: [Distutils] Follow-up on bug #143 / distribute
Message-ID: <AANLkTimmwjhcGMIm4Aa8680dTUCkmBQkOO_ddrOk1f2A@mail.gmail.com>

Hello,

I've fixed the issue #143 in distribute, along with some minor other
points, and I will release 0.6.14 as soon as we check with Barry that
it works fine upstream on Ubuntu/Debian. Other distros will follow.

- Distribute issue: http://bitbucket.org/tarek/distribute/issue/142
- Ubuntu issue:
https://bugs.edge.launchpad.net/ubuntu/+source/python-setuptools/+bug/601040

IOW, this removes the founded regression Distribute had with the
latest setuptools release.

In the meantime, if you have any other issue you would like to see
addressed in this release, let me know.

Tarek

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

From pje at telecommunity.com  Sat Jul  3 20:03:15 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 03 Jul 2010 14:03:15 -0400
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.c
 om>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>
Message-ID: <20100703180309.827223A4099@sparrow.telecommunity.com>

At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
>  Besides the numerous technical issues, this is just basic decency. If
>  I were PJE, I would be very mad.

I'm not mad at it being provided with a compatible API.  However, I 
*am* very unhappy with the fact that the version of distribute that's 
being shipped with OS distributions is both packaged as (e.g.) 
"python-setuptools", AND prevents people from installing the real 
setuptools, even in a local directory!

So, David, I hope you've filed this as a bug report with both 
Distribute and Ubuntu, and that others will do the same for any other 
distribution that's shipping distribute under a misleading name and 
that has this behavior.

My understanding when this was discussed previously, was that 
distribute would *only* suppress the installation of setuptools 
versions released *before* the corresponding version of distribute.

Also, considering how widespread the "setuptools isn't being 
maintained" lie is at this point, I'm a bit concerned that some OS 
distributors may have been unduly influenced by it in their switching 
decisions.

My understanding (and I would guess, that of the OS distributors' as 
well) was *also* based on the premise that distribute was going to 
track with setuptools' feature additions and bug fixes, which it 
clearly has not.  The 0.6c11 release (last October) fixed a rather 
long list of bugs besides the one you reported; does anyone know if 
the rest are actually fixed in Distribute?


From cournape at gmail.com  Sat Jul  3 20:27:20 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 4 Jul 2010 03:27:20 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <20100703180309.827223A4099@sparrow.telecommunity.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>
	<20100703180309.827223A4099@sparrow.telecommunity.com>
Message-ID: <AANLkTimRJDkuD83ooCYxiUdZwO86S7iH8kB_q0IEp4-p@mail.gmail.com>

On Sun, Jul 4, 2010 at 3:03 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
>>
>> ?Besides the numerous technical issues, this is just basic decency. If
>> ?I were PJE, I would be very mad.
>
> I'm not mad at it being provided with a compatible API.

This is obviously fine.

> ?However, I *am*
> very unhappy with the fact that the version of distribute that's being
> shipped with OS distributions is both packaged as (e.g.)
> "python-setuptools", AND prevents people from installing the real
> setuptools, even in a local directory!
>
> So, David, I hope you've filed this as a bug report with both Distribute and
> Ubuntu, and that others will do the same for any other distribution that's
> shipping distribute under a misleading name and that has this behavior.

Barry did it for ubuntu, zooko did a few months ago for distribute and
I provided the patch for distribute (a few months ago as well). But I
did not realize a few months ago that I was forced to use distribute
without any fallback.

On the bright side, this gave me much more respect for you and
setuptools, and I admire your patience.

David

From ziade.tarek at gmail.com  Sat Jul  3 20:30:07 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 3 Jul 2010 20:30:07 +0200
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <20100703180309.827223A4099@sparrow.telecommunity.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>
	<20100703180309.827223A4099@sparrow.telecommunity.com>
Message-ID: <AANLkTimIc3fdo_Xsio5K6hRC-KphooqFokeEaxlyoe1i@mail.gmail.com>

On Sat, Jul 3, 2010 at 8:03 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
>>
>> ?Besides the numerous technical issues, this is just basic decency. If
>> ?I were PJE, I would be very mad.
>
> I'm not mad at it being provided with a compatible API. ?However, I *am*
> very unhappy with the fact that the version of distribute that's being
> shipped with OS distributions is both packaged as (e.g.)
> "python-setuptools", AND prevents people from installing the real
> setuptools, even in a local directory!

That's not the intent. You can install setuptools if you want,
globally, by removing distribute.
You can install also a local setuptools.

If you can't do it, and your issue is not in #143, you can fill a bug
in the distribute tracker.

>
> So, David, I hope you've filed this as a bug report with both Distribute and
> Ubuntu, and that others will do the same for any other distribution that's
> shipping distribute under a misleading name and that has this behavior.

This is now fixed in distribute and is getting fixed in distributions
that use distribute,
because we work TOGETHER.

>
> My understanding when this was discussed previously, was that distribute
> would *only* suppress the installation of setuptools versions released
> *before* the corresponding version of distribute.
>
> Also, considering how widespread the "setuptools isn't being maintained" lie
> is at this point, I'm a bit concerned that some OS distributors may have
> been unduly influenced by it in their switching decisions.

Setuptools has not been maintained over the last two years. You just
have made a
few changes lately, in reaction of the fork. Don't worry about the OS
distributors, they are aware of the situation/

Again, a simple svn log in your repository when the fork happened and
when OS distributions have switched, is enough to see that setuptools
was not maintained.

If you are back on track and want to maintain it again, great ! maybe
the fork will dissapear, for the very same reason it appeared: to
avoid being locked by your 'glacial pace' (that's your words)


>
> My understanding (and I would guess, that of the OS distributors' as well)
> was *also* based on the premise that distribute was going to track with
> setuptools' feature additions and bug fixes, which it clearly has not. ?The
> 0.6c11 release (last October) fixed a rather long list of bugs besides the
> one you reported; does anyone know if the rest are actually fixed in
> Distribute?

I have tracked that one single huge commit, and tried to backport everything.
Obvisouly I missed something,. But I will double check again before I
release 0.6.14,
to avoid any flames here.

From cournape at gmail.com  Sat Jul  3 20:33:55 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 4 Jul 2010 03:33:55 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimIc3fdo_Xsio5K6hRC-KphooqFokeEaxlyoe1i@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>
	<20100703180309.827223A4099@sparrow.telecommunity.com>
	<AANLkTimIc3fdo_Xsio5K6hRC-KphooqFokeEaxlyoe1i@mail.gmail.com>
Message-ID: <AANLkTikTo8rT1EKHPDGEJXWE8b64Eitu1oaS68O0HK49@mail.gmail.com>

On Sun, Jul 4, 2010 at 3:30 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Sat, Jul 3, 2010 at 8:03 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
>>>
>>> ?Besides the numerous technical issues, this is just basic decency. If
>>> ?I were PJE, I would be very mad.
>>
>> I'm not mad at it being provided with a compatible API. ?However, I *am*
>> very unhappy with the fact that the version of distribute that's being
>> shipped with OS distributions is both packaged as (e.g.)
>> "python-setuptools", AND prevents people from installing the real
>> setuptools, even in a local directory!
>
> That's not the intent. You can install setuptools if you want,
> globally, by removing distribute.

Right, because remove python-setuptools (which is distribute)  is not
impractical at all on ubuntu.

David

From cournape at gmail.com  Sat Jul  3 20:41:27 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 4 Jul 2010 03:41:27 +0900
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <20100703180309.827223A4099@sparrow.telecommunity.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>
	<20100703180309.827223A4099@sparrow.telecommunity.com>
Message-ID: <AANLkTil-QXNxGyibEQlqFMeS3-dgjVS3G74op0aFyqjR@mail.gmail.com>

On Sun, Jul 4, 2010 at 3:03 AM, P.J. Eby <pje at telecommunity.com> wrote:

>
> My understanding (and I would guess, that of the OS distributors' as well)
> was *also* based on the premise that distribute was going to track with
> setuptools' feature additions and bug fixes, which it clearly has not. ?The
> 0.6c11 release (last October) fixed a rather long list of bugs besides the
> one you reported; does anyone know if the rest are actually fixed in
> Distribute?

There is another potential issue with the edit mode, but I have not
been able to track it down yet, and as such have not reported it (nor
checked if it was already reported). Basically, easy_install -eNb
somedir somepackage does not always work, with some strange error. I
cannot always reproduce it.

David

From tseaver at palladion.com  Sat Jul  3 21:23:29 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 03 Jul 2010 15:23:29 -0400
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <AANLkTimIc3fdo_Xsio5K6hRC-KphooqFokeEaxlyoe1i@mail.gmail.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>	<20100702135957.ED3433A4099@sparrow.telecommunity.com>	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>	<i0l1jg$eq9$1@dough.gmane.org>	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>	<4C2ED458.50607@netwok.org>	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>	<20100703180309.827223A4099@sparrow.telecommunity.com>
	<AANLkTimIc3fdo_Xsio5K6hRC-KphooqFokeEaxlyoe1i@mail.gmail.com>
Message-ID: <i0o2nh$6lr$2@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:
> On Sat, Jul 3, 2010 at 8:03 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 07:29 PM 7/3/2010 +0900, David Cournapeau wrote:
>>>  Besides the numerous technical issues, this is just basic decency. If
>>>  I were PJE, I would be very mad.
>> I'm not mad at it being provided with a compatible API.  However, I *am*
>> very unhappy with the fact that the version of distribute that's being
>> shipped with OS distributions is both packaged as (e.g.)
>> "python-setuptools", AND prevents people from installing the real
>> setuptools, even in a local directory!
> 
> That's not the intent. You can install setuptools if you want,
> globally, by removing distribute.
> You can install also a local setuptools.
> 
> If you can't do it, and your issue is not in #143, you can fill a bug
> in the distribute tracker.
> 
>> So, David, I hope you've filed this as a bug report with both Distribute and
>> Ubuntu, and that others will do the same for any other distribution that's
>> shipping distribute under a misleading name and that has this behavior.
> 
> This is now fixed in distribute and is getting fixed in distributions
> that use distribute,
> because we work TOGETHER.
> 
>> My understanding when this was discussed previously, was that distribute
>> would *only* suppress the installation of setuptools versions released
>> *before* the corresponding version of distribute.
>>
>> Also, considering how widespread the "setuptools isn't being maintained" lie
>> is at this point, I'm a bit concerned that some OS distributors may have
>> been unduly influenced by it in their switching decisions.
> 
> Setuptools has not been maintained over the last two years. You just
> have made a
> few changes lately, in reaction of the fork. Don't worry about the OS
> distributors, they are aware of the situation/
> 
> Again, a simple svn log in your repository when the fork happened and
> when OS distributions have switched, is enough to see that setuptools
> was not maintained.
> 
> If you are back on track and want to maintain it again, great ! maybe
> the fork will dissapear, for the very same reason it appeared: to
> avoid being locked by your 'glacial pace' (that's your words)
> 
> 
>> My understanding (and I would guess, that of the OS distributors' as well)
>> was *also* based on the premise that distribute was going to track with
>> setuptools' feature additions and bug fixes, which it clearly has not.  The
>> 0.6c11 release (last October) fixed a rather long list of bugs besides the
>> one you reported; does anyone know if the rest are actually fixed in
>> Distribute?
> 
> I have tracked that one single huge commit, and tried to backport everything.
> Obvisouly I missed something,. But I will double check again before I
> release 0.6.14,
> to avoid any flames here.

In that spirit, Tarek, you need to stop saying "setuptools is
unmaintained for the last 2 years":  PJE objects to it as unfactual, as
do I.  THe release last October makes that statement untrue on its face.

Please note as well that nothing about this is criticism of the choice
to fork, or any work you and others have done on distrbute, the PEPs,
distutils2, etc.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwvjjEACgkQ+gerLs4ltQ7CDACcDhcinnL2WzzH75KIeQrmNFcB
sg0An205oYtcSFH+eTh0h3craZTgcpgo
=9zjC
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Sat Jul  3 23:40:55 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 03 Jul 2010 17:40:55 -0400
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <i0o2nh$6lr$2@dough.gmane.org>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>
	<20100703180309.827223A4099@sparrow.telecommunity.com>
	<AANLkTimIc3fdo_Xsio5K6hRC-KphooqFokeEaxlyoe1i@mail.gmail.com>
	<i0o2nh$6lr$2@dough.gmane.org>
Message-ID: <20100703214049.33DFA3A4099@sparrow.telecommunity.com>

At 03:23 PM 7/3/2010 -0400, Tres Seaver wrote:
>In that spirit, Tarek, you need to stop saying "setuptools is
>unmaintained for the last 2 years":  PJE objects to it as unfactual, as
>do I.  THe release last October makes that statement untrue on its face.

Additionally, I would like to have some reassurance that when I begin 
releasing 0.7 alpha versions, that the distribute community is not 
going to start accusing me (as Tarek just did) of doing things "in 
reaction" to them, or to sabotage them, or say that I'm trying to 
force people to switch back to setuptools...

And ideally, I would like them to refrain from implementing 
technological measures to interfere with setuptools' normal upgrade process.

Since last September, the current release of setuptools has been 
downloaded from PyPI more times than all releases of distribute 
*combined*.  I am therefore much more concerned with providing normal 
updates to the setuptools user base, than I am with interfering with 
people who really *want* to use distribute, for whatever reason.

However, by the same token, it also means that I have no wish to 
spend a lot of time trying to figure out how to work *around* 
distribute!  I would much prefer to advise people who wish to upgrade 
setuptools, to simply uninstall distribute before upgrading, rather 
than to have to implement technological measures to address the situation.

But the last time that I advised that people upgrading setuptools 
needed to uninstall distribute first, I received accusations that I 
was trying to undermine distribute and spread FUD by telling people 
to uninstall it.

(My time for working on open source development these days is 
limited, and tends to come in chunks, especially around 
holidays.  There were at least two such opportunities earlier this 
year where I considered tackling some of my smaller planned features 
for 0.7, and then thought about the likely hassle of actually 
*releasing* any of that work, and then promptly turned my attention 
to other, less-controversial projects.)


From ben+python at benfinney.id.au  Sun Jul  4 00:51:34 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 04 Jul 2010 08:51:34 +1000
Subject: [Distutils] setuptools' "Feature" feature
References: <i0lb61$hao$1@dough.gmane.org>
	<20100702221808.5D0463A4099@sparrow.telecommunity.com>
Message-ID: <87wrtcfabt.fsf@benfinney.id.au>

"P.J. Eby" <pje at telecommunity.com> writes:

> That's because it's essentially deprecated - an experimental thing
> that turned out to be, well, a failed experiment.

An experiment that produces a reliable result is a success. If you can
reliably say that the feature is not worth it, that's a successful
experiment :-)

-- 
 \         ?In economics, hope and faith coexist with great scientific |
  `\      pretension and also a deep desire for respectability.? ?John |
_o__)                                    Kenneth Galbraith, 1970-06-07 |
Ben Finney


From merwok at netwok.org  Sun Jul  4 01:08:20 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 04 Jul 2010 01:08:20 +0200
Subject: [Distutils] setuptools' "Feature" feature
In-Reply-To: <20100702221808.5D0463A4099@sparrow.telecommunity.com>
References: <i0lb61$hao$1@dough.gmane.org>
	<20100702221808.5D0463A4099@sparrow.telecommunity.com>
Message-ID: <4C2FC2E4.7030206@netwok.org>

[P.J. Eby]
> I hope distutils2 allows you to declare extensions optional;
> it's such a common use case.

I thought this was already in distutils, but it is actually in
distutils2. Thanks for asking that, it would have been bad to lack it.

Regards



From xordoquy at linovia.com  Mon Jul  5 17:30:50 2010
From: xordoquy at linovia.com (Xavier Ordoquy)
Date: Mon, 5 Jul 2010 17:30:50 +0200
Subject: [Distutils] buildout and issues with dependencies and patch.
Message-ID: <7BA0A3A9-1149-41FB-AA37-974AF2D4BE2B@linovia.com>

Hi,

I am currently trying to get buildout as my default deploy system however, I'm facing two issues for which I don't understand buildout well enough and for which I haven't found answers on the net.

My first issue is I need to get both numpy and matplotlib installed.
So I added both to the eggs section of buildout.
numpy seems to get downloaded and installed fine, however, matplotlib won't. The latest complains numpy isn't installed.
At this point, my guesses - after investigations - are that  matplotlib checks numpy availability by importing it. However, as buildout has not set the numpy egg in the path, matplotlib fails and ends.
I have noticed there's a way to set headers  and library path for compilers but I can't find a way to set the numpy's egg path, even when I move matplotlib to a section with the egg receipe.

Does someone know a way to get numpy eggs prepend to the paths so that matplotlib can detect it ?


My second question is, I also want to install pysvn. This package needs a patch to be setuptool friendly. I would like to know if there's a simple way within the buildout.cfg file to apply a patch to a package before it gets eggified ?

Regards,
Xavier.

From jim at zope.com  Tue Jul  6 15:21:32 2010
From: jim at zope.com (Jim Fulton)
Date: Tue, 6 Jul 2010 09:21:32 -0400
Subject: [Distutils] buildout and issues with dependencies and patch.
In-Reply-To: <7BA0A3A9-1149-41FB-AA37-974AF2D4BE2B@linovia.com>
References: <7BA0A3A9-1149-41FB-AA37-974AF2D4BE2B@linovia.com>
Message-ID: <AANLkTingccelEkjoe9KeDGtEJ3BulI9RB0CYfts4-Czc@mail.gmail.com>

On Mon, Jul 5, 2010 at 11:30 AM, Xavier Ordoquy <xordoquy at linovia.com> wrote:
> Hi,
>
> I am currently trying to get buildout as my default deploy system however, I'm facing two issues for which I don't understand buildout well enough and for which I haven't found answers on the net.
>
> My first issue is I need to get both numpy and matplotlib installed.
> So I added both to the eggs section of buildout.
> numpy seems to get downloaded and installed fine, however, matplotlib won't. The latest complains numpy isn't installed.
> At this point, my guesses - after investigations - are that ?matplotlib checks numpy availability by importing it. However, as buildout has not set the numpy egg in the path, matplotlib fails and ends.
> I have noticed there's a way to set headers ?and library path for compilers but I can't find a way to set the numpy's egg path, even when I move matplotlib to a section with the egg receipe.
>
> Does someone know a way to get numpy eggs prepend to the paths so
that matplotlib can detect it ?

matplotlib is problematic for buildout due to the introspection it
does.  I haven't found a good solution.  What I've done in the past is
to make a not-so-clean Python (or virtualenv) that has numpy installed
and then use buildout with that to install matplotlib.

(Another work-around occurs to me, which I will try and report back. :)


> My second question is, I also want to install pysvn. This package
  needs a patch to be setuptool friendly. I would like to know if
  there's a simple way within the buildout.cfg file to apply a patch
  to a package before it gets eggified ?

I think there are some recipes that apply patches. I haven't tried
them myself.

  http://pypi.python.org/pypi?%3Aaction=search&term=buildout+recipe+patch

Jim

--
Jim Fulton

From zooko at zooko.com  Tue Jul  6 16:15:26 2010
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Tue, 6 Jul 2010 08:15:26 -0600
Subject: [Distutils] Packaging situation + mailing list rules
In-Reply-To: <20100703214049.33DFA3A4099@sparrow.telecommunity.com>
References: <AANLkTilMpgcrpajKims2yLgix3UAdgJUXnF6qNFvijQb@mail.gmail.com>
	<20100702135957.ED3433A4099@sparrow.telecommunity.com>
	<AANLkTikP_DpcJ42OigptK5h4Ef5lKSN3VgzfvU626oda@mail.gmail.com>
	<i0l1jg$eq9$1@dough.gmane.org>
	<AANLkTimqMbsb56oTa0f78Ne1EBXHIH_2rzStOybn-6ej@mail.gmail.com>
	<4C2ED458.50607@netwok.org>
	<AANLkTinI2k20f9UCHNT4rm7BhsaUVj7QVoy48V6yikyf@mail.gmail.com>
	<AANLkTilSLBIvn7kdkjJezcczZ2WnnUYlu9deS2UIaXx9@mail.gmail.com>
	<20100703180309.827223A4099@sparrow.telecommunity.com>
	<AANLkTimIc3fdo_Xsio5K6hRC-KphooqFokeEaxlyoe1i@mail.gmail.com>
	<i0o2nh$6lr$2@dough.gmane.org>
	<20100703214049.33DFA3A4099@sparrow.telecommunity.com>
Message-ID: <AANLkTil2xf577t4241Lp2WShaJwyn4CFbAHPYk75haLP@mail.gmail.com>

I don't want to be inflammatory, but I am a user of setuptools and
distribute and I think I have a valid concern that this list should
note.

The fact that Debian and Ubuntu made the "python-setuptools" .deb
install Distribute instead of setuptools, and that Distribute has some
bugs that setuptools doesn't, has caused major headaches for me who is
trying to distribute some software and wants it to work on Debian and
Ubuntu as well as other platforms.

https://bitbucket.org/tarek/distribute/issue/142/easy_install-will-install-a-package-that-is-already

Oh, look! Two days ago Tarek wrote a unit test for my problem! Joy!

(Dear Tarek: I'm sorry I never wrote that unit test. Now you don't
have to wear a Tahoe-LAFS t-shirt.)

So, just to be clear: I'm not contributing to this discussion to say
that the Distribute project or Tarek are bad, or that they are worse
than the Setuptools project or PJE. (Indeed, the fact that Tarek has
written a unit test for this bug is very, very good.)

But I *am* saying that swapping in a large, complicated, buggy piece
of software as a replacement for another large, complicated, buggy
piece of software is a sensitive operation that should only be done
with care and with a good plan to revert to the earlier version. The
fact that Debian and Ubuntu did this without informing their users and
without providing any way to undo this (within the context of the
Debian/Ubuntu packaging system) is a major bungle.

I plead with the members of this list:

1. Please respect the fact that some of your users will sometimes
employ another tool than the tool you are working on. They have their
own reasons, even if it is only "The Devil (bugs) you know is better
than the Devil (bugs) you don't know.". They may have values or
preferences that you don't understand or don't share. Just be
respectful in word and in deed.

2. Be extremely careful when automating such disruptive changes.
Please provide documentation warning users about the change and a
method to revert. This is primarily the job of Debian/Ubuntu in this
case, of course, but distutils-sig and python-dev can probably help by
making it clear to everyone that distribute and setuptools are two
separate, actively developed tools with different strengths and
weaknesses.

3. If you are positioning your tool as an "upgrade" or a "drop-in
replacement" then any regression that a user experiences when they
upgrade is a high-priority issue. Even if Tarek's unit test is right
and the bug fix fixes my problems, then I have to try to get Ubuntu to
patch their version of Distribute which they ship in Ubuntu 10.04
Lucid and then wait for my users to upgrade. Some step in that chain
is probably not going to work for all users, so I will probably be
having to work-around this problem for years to come. In addition, I
have had to change the source code of my own tools to include
work-arounds for this bug, so now I will be supporting my own
work-arounds for months or years.

Thanks for listening, folks. I hope we as a community will make it
easier for people to use these tools in the future. The vast majority
of the users are probably completely unaware of the flamewars on this
list, and that's for the best. :-) Hopefully they will eventually get
better tools and release processes from us and they will be grateful.

Regards,

Zooko

From techtonik at gmail.com  Wed Jul  7 08:31:55 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 7 Jul 2010 09:31:55 +0300
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <94bdd2611003290852q45927cf0v33b0b437c9eaa76f@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
	<94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com>
	<d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
	<94bdd2611003290852q45927cf0v33b0b437c9eaa76f@mail.gmail.com>
Message-ID: <AANLkTikZryAsZO3byLG-PfNhNWK5eSBKa-l-T6GYdbNb@mail.gmail.com>

On Mon, Mar 29, 2010 at 6:52 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> [..]
>>>
>>> Sounds like a simple installation instruction, I can't see the benefit
>>> of adding a script for that.
>>
>> Of course! Because you are a developer. You need to be a user or at
>> least QA engineer to see it. =)
>>
>> For now in its simplest minimal form that is possible to create in a
>> day for 2.7 it is an simple text instruction. This will surely can be
>> ready for 2.7. But in future distributions, i.e. in Python 2.7
>> non-beta, it may be able to download required package management tool
>> automatically if user agrees, unpack it to %TEMP% and execute
>> "setup.py install".
>
> You are completely right about the fact that our tools and guide are
> aiming to developers.
>
> The CPython distribution comes with the stdlib, no more no less. So
> there's no point to launch the installation of a third party project
> when you install CPython.

Not when you (as a user) install, but when you try to execute `python
-m easy_install` or `python -m pip` or `python -m distribute`, i.e. as
advised in Packaging Guide.

> And until the stdlib contains what it takes
> to have a full-feature package manager, you will need to do an extra
> manual installation to get one, or use another Python distribution
> that contains one already.

That's suxx that I need to prepend every simple tutorial for users of
my packages with an obligatory notice how to install setuptools
instead of just writing:

> python -m easy_install review

With installing easy_install it is not as easy to install as it could be.
-- 
anatoly t.

From techtonik at gmail.com  Wed Jul  7 08:45:17 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 7 Jul 2010 09:45:17 +0300
Subject: [Distutils] [Python-Dev] Bootstrap script for package
	management tool in Python 2.7 (Was: Re: At least one package
	management tool for 2.7)
In-Reply-To: <b654cd2e1003291445w1dfcc63sa35043499613185e@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<4BB0E2AD.6020407@hastings.org>
	<b654cd2e1003291445w1dfcc63sa35043499613185e@mail.gmail.com>
Message-ID: <AANLkTik6Hr4KX5t3jpfJ1Qx6j12eRfv3siz8JRFBMh-1@mail.gmail.com>

On Tue, Mar 30, 2010 at 12:45 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Mon, Mar 29, 2010 at 11:26 AM, Larry Hastings <larry at hastings.org> wrote:
>>
>> anatoly techtonik wrote:
>>>
>>> So, there won't be any package management tool shipped with Python 2.7
>>> and users will have to download and install `setuptools` manually as
>>> before:
>>>
>>> ?"search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
>>> setup.py install"
>>>
>>>
>>> Therefore I still propose shipping bootstrap package that instruct
>>> user how to download and install an actual package ?management tool
>>> when users tries to use it.
>>
>> For what it's worth, Guido prototyped something similar in March of 2008,
>> but his was an actual bootstrapping tool for package management:
>>
>> ? http://mail.python.org/pipermail/python-dev/2008-March/077837.html
>>
>> His tool knew how to download a tar file, untar it, and run "python
>> setup.py install" on it. ?No version numbers, no dependency management,
>> simple enough that it should be easy to get right. ?Only appropriate for
>> bootstrapping into a real package management tool.
>>
>> The thread ends with him saying "I don't have time to deal with this
>> further this week", and I dunno, maybe it just fell off the radar? ?I'd been
>> thinking about resurrecting the discussion but I didn't have time either.
>
>
> I would consider this bootstrap to be quite workable, though I would add
> that any extra option to the bootstrap script should be passed to setup.py
> install, and the download should be cached (so you can do -h and not have to
> re-download the package once you figure out the extra options -- at least a
> --user option is reasonable here for people without root).? Specifically
> targeting this bootstrap for tools like pip and virtualenv is no problem.
>
> I think looking around PyPI etc is kind of more than I'd bother with.? Those
> things change, this bootstrap code won't change, it could cause unnecessary
> future pain.? Maybe (*maybe*) it could look in
> http://pypi.python.org/well-known-packages/PACKAGE_NAME and so we can have
> it install a certain small number of things quickly that way -- if the URL
> it looks to is targeted only for the bootstrap script itself then we don't
> have to worry about compatibility problems as much.
>
> Oh... then i can think of a half dozen other options it could take, and then
> it becomes an installer.? Blech.? OK, I'd be willing to cut off the options
> at --user (which I think is a minimum... maybe --prefix too), and maybe some
> simple package detection so people could write "python -m boostrap
> Setuptools --user" -- entirely based on some well-known URL baked into
> bootstrap.py, where the URL is independent of any other service (and so is
> least likely to cause future problems or ambiguities).
>
> An advantage to this kind of bootstrapper is that as future packaging
> systems are developed there's a clear way to get started with them, without
> prematurely baking anything in to Python.

The bootstrap should only be a temporary package that will propose
user to automatically install package management tool user is trying
to use if he doesn't have any. It is not Ubuntu-like "missing package
autodetection" - only few most popular non-conflicting packaging
solutions should be bootstrapped in this way:

> python -m easy_install review
`easy_install` is not installed on this system. Do you want to fetch
it to proceed (Y/n)?

Think of it as of one used oriented "1-Click" technology.
-- 
anatoly t.

From agroszer at gmail.com  Wed Jul  7 13:18:46 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Wed, 7 Jul 2010 13:18:46 +0200
Subject: [Distutils] trying to do a buildbot for zc.buildout on windows
In-Reply-To: <1437101279.20100629135853@gmail.com>
References: <1437101279.20100629135853@gmail.com>
Message-ID: <854046071.20100707131846@gmail.com>

Hello,

Running it with -vvvvv gives also no clues:
http://winbot.zope.org/builders/zc_buildout_dev%20py_254_win32/builds/14/steps/buildout/logs/stdio

Does anyone have any idea why it would NOT upgrade when running under
buildbot?

Tuesday, June 29, 2010, 1:58:53 PM, you wrote:

AG> Hello,

AG> I'm trying to make a buildbot for zc.buildout on various windows
AG> platforms.
AG> The problem is that bin/buildout acts weird when it's run by the
AG> buildbot process:
AG> http://winbot.zope.org/builders/zc_buildout_dev%20py_254_win32/builds/3/steps/buildout/logs/stdio

AG> OTOH, it's fine when running it manually (same credentials):
AG> C:\buildslave\zc_buildout_dev_py_254_win32\build>bin\buildout.exe

AG> C:\buildslave\zc_buildout_dev_py_254_win32\build>Upgraded:
AG>   zc.buildout version 1.5.0dev;
AG> restarting.
AG> Generated script
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\buildout'.
AG> Develop:
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\zc.recipe.egg_'
AG> Develop:
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\z3c.recipe.scripts_'
AG> Develop: 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\.'
AG> Installing test.
AG> Generated script
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\test'.
AG> Installing oltest.
AG> Generated script
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\oltest'.
AG> Installing py.
AG> Generated script
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\buildout'.
AG> Generated script
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\zope-testrunner'.
AG> Generated interpreter
AG> 'C:\\buildslave\\zc_buildout_dev_py_254_win32\\build\\bin\\py'.

AG> Does anyone know why this could happen?



-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
Real pain can alone cure us of imaginary ills. 
- Jonathan Edwards 


From hltbra at gmail.com  Wed Jul  7 14:55:39 2010
From: hltbra at gmail.com (Hugo Lopes Tavares)
Date: Wed, 7 Jul 2010 09:55:39 -0300
Subject: [Distutils] Python 2.7 is out and ez_setup.py does not work
Message-ID: <AANLkTillFUO5DV-dHda16cmi3ZaOx2Y77YKOlFhD03Wn@mail.gmail.com>

Hi guys,
Python 2.7 was released in July 3, and until now we don't have
ez_setup.py working for that. It looks for an egg for each python
version, and nobody has uploaded that.

There was a guy here last month with problems to install seutptools in
his Windows, for a similar reason.
Is there so much problem to release bdists for Python 2.7?

And if you come and say to download the tarball and later install, I
was trying to use virtualenv + Python2.7 and virtualenv uses
ez_setup.py to create virtual environments.

Could someone upload the bdists and update ez_setup.py?

From agroszer at gmail.com  Wed Jul  7 15:08:24 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Wed, 7 Jul 2010 15:08:24 +0200
Subject: [Distutils] Python 2.7 is out and ez_setup.py does not work
In-Reply-To: <AANLkTillFUO5DV-dHda16cmi3ZaOx2Y77YKOlFhD03Wn@mail.gmail.com>
References: <AANLkTillFUO5DV-dHda16cmi3ZaOx2Y77YKOlFhD03Wn@mail.gmail.com>
Message-ID: <1502874328.20100707150824@gmail.com>

Yup, buildout's newbootstrap.py fails too on the same:

http://winbot.zope.org/builders/zc_buildout_dev%20py_270_win32/builds/0/steps/bootstrap/logs/stdio

Wednesday, July 7, 2010, 2:55:39 PM, you wrote:

HLT> Hi guys,
HLT> Python 2.7 was released in July 3, and until now we don't have
HLT> ez_setup.py working for that. It looks for an egg for each python
HLT> version, and nobody has uploaded that.

HLT> There was a guy here last month with problems to install seutptools in
HLT> his Windows, for a similar reason.
HLT> Is there so much problem to release bdists for Python 2.7?

HLT> And if you come and say to download the tarball and later install, I
HLT> was trying to use virtualenv + Python2.7 and virtualenv uses
HLT> ez_setup.py to create virtual environments.

HLT> Could someone upload the bdists and update ez_setup.py?
HLT> _______________________________________________
HLT> Distutils-SIG maillist  -  Distutils-SIG at python.org
HLT> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
Do not clog intellect's sluices with bits of knowledge of questionable uses.


From jbaker at zeomega.com  Wed Jul  7 15:24:39 2010
From: jbaker at zeomega.com (Jason Baker)
Date: Wed, 7 Jul 2010 08:24:39 -0500
Subject: [Distutils] What are non-active development eggs?
Message-ID: <AANLkTilwS0k0iV5LAp_E5ny_b32unIjTvjzAiYv2b7ET@mail.gmail.com>

I've posted this question to Stackoverflow[1], but didn't get a response
there so I thought I'd ask here.  (This is simply a copy and paste of that
question)

For whatever reason, my build system isn't installing one of my packages
properly.  When I use yolk (from within a virtualenv), I get the following:

    bin/yolk -l elig
    elig            - 3.1.2.dev    - non-active development
(/home/jason/src/interface_dev/elig)

How exactly does a package go from active development to non-active
development?

[1]
http://stackoverflow.com/questions/3187496/what-does-it-mean-when-a-package-is-installed-as-non-active-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100707/04512b2d/attachment.html>

From pje at telecommunity.com  Thu Jul  8 02:11:44 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 07 Jul 2010 20:11:44 -0400
Subject: [Distutils] Python 2.7 is out and ez_setup.py does not work
In-Reply-To: <AANLkTillFUO5DV-dHda16cmi3ZaOx2Y77YKOlFhD03Wn@mail.gmail.c
 om>
References: <AANLkTillFUO5DV-dHda16cmi3ZaOx2Y77YKOlFhD03Wn@mail.gmail.com>
Message-ID: <20100708001152.6C6C73A403A@sparrow.telecommunity.com>

At 09:55 AM 7/7/2010 -0300, Hugo Lopes Tavares wrote:
>Hi guys,
>Python 2.7 was released in July 3, and until now we don't have
>ez_setup.py working for that. It looks for an egg for each python
>version, and nobody has uploaded that.
>
>There was a guy here last month with problems to install seutptools in
>his Windows, for a similar reason.
>Is there so much problem to release bdists for Python 2.7?
>
>And if you come and say to download the tarball and later install, I
>was trying to use virtualenv + Python2.7 and virtualenv uses
>ez_setup.py to create virtual environments.
>
>Could someone upload the bdists and update ez_setup.py?

I'm still getting a proper 2.7 built and packaged for my deployment 
machine.  The new egg will be up soon.


From pje at telecommunity.com  Thu Jul  8 02:37:53 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 07 Jul 2010 20:37:53 -0400
Subject: [Distutils] Python 2.7 is out and ez_setup.py does not work
In-Reply-To: <AANLkTillFUO5DV-dHda16cmi3ZaOx2Y77YKOlFhD03Wn@mail.gmail.c
 om>
References: <AANLkTillFUO5DV-dHda16cmi3ZaOx2Y77YKOlFhD03Wn@mail.gmail.com>
Message-ID: <20100708003750.284993A403A@sparrow.telecommunity.com>

At 09:55 AM 7/7/2010 -0300, Hugo Lopes Tavares wrote:
>Hi guys,
>Python 2.7 was released in July 3, and until now we don't have
>ez_setup.py working for that. It looks for an egg for each python
>version, and nobody has uploaded that.
>
>There was a guy here last month with problems to install seutptools in
>his Windows, for a similar reason.
>Is there so much problem to release bdists for Python 2.7?
>
>And if you come and say to download the tarball and later install, I
>was trying to use virtualenv + Python2.7 and virtualenv uses
>ez_setup.py to create virtual environments.
>
>Could someone upload the bdists and update ez_setup.py?

The bdists are done now; there was a bit of a problem with a 
distutils.command.upload bug introduced here:

http://svn.python.org/view/python/trunk/Lib/distutils/command/upload.py?view=diff&r1=70888&r2=70889

(I'm not sure if this bug is also in 2.6 or not, but for 2.7 I worked 
around it by having setuptools still use its own upload 
command.  This is a temporary workaround, of course, until 2.7.1 
rolls out I suppose.)


From faassen at startifact.com  Thu Jul  8 15:28:35 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 08 Jul 2010 15:28:35 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
Message-ID: <i14jq4$2ce$2@dough.gmane.org>

Hi there,

I've been waiting for years for a release of buildout that contains
proper isolation from Python's site-packages. The non-isolation is a
major flaw in buildout that makes it SO much harder to write proper
installation instructions for software such as Grok.

We need to wrap Grok's buildout installation using virtualenv
--no-site-packages. I just discovered that this installation actually
fails if I use an ubuntu-installed virtualenv (or setuptools)! It works
with a manually installed version of either, and I'm sure the problem is 
somewhere in z3c.autoinclude too, but it's still an issue.

Last year in september I hacked up some code that would do the
isolation. I was then informed that Gary Poster was working on a branch
instead, and indeed the branch I saw then looked much improved in
features. So I waited. I saw new versions of the branch come and go and
I'm not sure what's going on, but I waited.

I noticed that in april there was a beta release of buildout that
featured such improvements. This release was then withdrawn and
overridden with 1.50b2 with the message:

"This is a re-release of 1.4.3 to hide the brown-bag release of 1.5.0b1.
The changes in 1.5.0b1 will reappear as 1.5.0 soon, when the additional
reported problems have been addressed."

It is now july, so I'm starting to get my doubts about the word "soon".
Have the reported problems been addressed? Is there any hope I can get a 
buildout that actually provides proper isolation sometime? Can I help?

Regards,

Martijn


From agroszer at gmail.com  Thu Jul  8 16:33:50 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Thu, 8 Jul 2010 16:33:50 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <i14jq4$2ce$2@dough.gmane.org>
References: <i14jq4$2ce$2@dough.gmane.org>
Message-ID: <125219683.20100708163350@gmail.com>

Hello Martijn,


Thursday, July 8, 2010, 3:28:35 PM, you wrote:

MF> It is now july, so I'm starting to get my doubts about the word "soon".
MF> Have the reported problems been addressed? Is there any hope I can get a
MF> buildout that actually provides proper isolation sometime? Can I help?

Right now I even cannot get the buildout trunk bin/buildout'ed on
ubuntu. Does it work for you?

-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
So live that after the minister has ended his remarks, those present will not think they have attended the wrong funeral. 
- Anonymous 


From fdrake at acm.org  Thu Jul  8 16:45:47 2010
From: fdrake at acm.org (Fred Drake)
Date: Thu, 8 Jul 2010 10:45:47 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <125219683.20100708163350@gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
Message-ID: <AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>

On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER <agroszer at gmail.com> wrote:
> Right now I even cannot get the buildout trunk bin/buildout'ed on
> ubuntu. Does it work for you?

It builds for me (Python 2.6 w/ distribute; haven't tried with
setuptools), but the tests aren't passing because someone added a
dependency on zope.testing, but hasn't fixed the declared
dependencies.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"A storm broke loose in my mind."  --Albert Einstein

From barry at python.org  Thu Jul  8 17:11:30 2010
From: barry at python.org (Barry Warsaw)
Date: Thu, 8 Jul 2010 11:11:30 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
Message-ID: <20100708111130.45ce6862@heresy>

On Jul 08, 2010, at 10:45 AM, Fred Drake wrote:

>On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER <agroszer at gmail.com>
>wrote:
>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>> ubuntu. Does it work for you?
>
>It builds for me (Python 2.6 w/ distribute; haven't tried with
>setuptools), but the tests aren't passing because someone added a
>dependency on zope.testing, but hasn't fixed the declared
>dependencies.

Last time I tried with the Mailman 3 code base, it was broken, but I think
that was mainly due to API changes in zope.testing.  I now have this in my
setup.py:

    install_requires = [
        'argparse',
        'flufl.enum',
        'flufl.i18n',
        'httplib2',
        'lazr.config',
        'lazr.smtptest',
        'locknix',
        'restish',
        'storm',
        'zc.buildout',
        'zope.component',
        'zope.configuration',
        'zope.interface',
        'zope.testing<4',
        ],

Note the last line.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100708/2b9ac604/attachment.pgp>

From agroszer at gmail.com  Thu Jul  8 17:15:02 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Thu, 8 Jul 2010 17:15:02 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
Message-ID: <128034701.20100708171502@gmail.com>

Hello Fred,

w/ python2.5 and setuptools 0.6c11...
Output is, after a clean slate:

adi at ubvm:~/zopefix/zc.buildout/trunk$ svn up
Restored '.bzrignore'
Restored 'todo.txt'
Restored 'buildout.cfg'
Restored 'DEVELOPERS.txt'
Restored 'CHANGES.txt'
Restored 'setup.py'
Restored 'test_all_pythons.cfg'
Restored 'dev.py'
Restored 'README.txt'
A    zc.recipe.egg_
A    zc.recipe.egg_/CHANGES.txt
A    zc.recipe.egg_/setup.py
A    zc.recipe.egg_/src
A    zc.recipe.egg_/src/zc
A    zc.recipe.egg_/src/zc/__init__.py
A    zc.recipe.egg_/src/zc/recipe
A    zc.recipe.egg_/src/zc/recipe/egg
A    zc.recipe.egg_/src/zc/recipe/egg/custom.py
A    zc.recipe.egg_/src/zc/recipe/egg/__init__.py
A    zc.recipe.egg_/src/zc/recipe/egg/api.txt
A    zc.recipe.egg_/src/zc/recipe/egg/custom.txt
A    zc.recipe.egg_/src/zc/recipe/egg/egg.py
A    zc.recipe.egg_/src/zc/recipe/egg/tests.py
A    zc.recipe.egg_/src/zc/recipe/egg/selecting-python.txt
A    zc.recipe.egg_/src/zc/recipe/egg/README.txt
A    zc.recipe.egg_/src/zc/recipe/__init__.py
A    zc.recipe.egg_/README.txt
A    specifications
A    specifications/repeatable.txt
A    specifications/README.txt
A    doc
A    doc/tutorial.txt
A    doc/tutorial.fr.txt
A    src
A    src/zc
A    src/zc/__init__.py
A    src/zc/buildout
A    src/zc/buildout/testrecipes.py
A    src/zc/buildout/repeatable.txt
A    src/zc/buildout/unzip.txt
A    src/zc/buildout/download.txt
A    src/zc/buildout/rmtree.py
A    src/zc/buildout/__init__.py
A    src/zc/buildout/tests.py
A    src/zc/buildout/extends-cache.txt
A    src/zc/buildout/testing.txt
A    src/zc/buildout/bootstrap.txt
A    src/zc/buildout/upgrading_distribute.txt
A    src/zc/buildout/distribute.txt
A    src/zc/buildout/dependencylinks.txt
A    src/zc/buildout/download.py
A    src/zc/buildout/testing_bugfix.txt
A    src/zc/buildout/update.txt
A    src/zc/buildout/runsetup.txt
A    src/zc/buildout/testing.py
A    src/zc/buildout/easy_install.txt
A    src/zc/buildout/buildout.txt
A    src/zc/buildout/testselectingpython.py
A    src/zc/buildout/windows.txt
A    src/zc/buildout/downloadcache.txt
A    src/zc/buildout/debugging.txt
A    src/zc/buildout/allowhosts.txt
A    src/zc/buildout/easy_install.py
A    src/zc/buildout/buildout.py
A    src/zc/buildout/setup.txt
A    z3c.recipe.scripts_
A    z3c.recipe.scripts_/CHANGES.txt
A    z3c.recipe.scripts_/setup.py
A    z3c.recipe.scripts_/src
A    z3c.recipe.scripts_/src/z3c
A    z3c.recipe.scripts_/src/z3c/__init__.py
A    z3c.recipe.scripts_/src/z3c/recipe
A    z3c.recipe.scripts_/src/z3c/recipe/__init__.py
A    z3c.recipe.scripts_/src/z3c/recipe/scripts
A    z3c.recipe.scripts_/src/z3c/recipe/scripts/__init__.py
A    z3c.recipe.scripts_/src/z3c/recipe/scripts/tests.py
A    z3c.recipe.scripts_/src/z3c/recipe/scripts/README.txt
A    z3c.recipe.scripts_/src/z3c/recipe/scripts/scripts.py
A    z3c.recipe.scripts_/README.txt
A    bootstrap
A    bootstrap/bootstrap.py
A    bootstrap/newbootstrap.py
Updated to revision 114336.
adi at ubvm:~/zopefix/zc.buildout/trunk$ python2.5 bootstrap/newbootstrap.py 
Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c11-py2.5.egg
Creating directory '/home/adi/zopefix/zc.buildout/trunk/bin'.
Creating directory '/home/adi/zopefix/zc.buildout/trunk/parts'.
Creating directory '/home/adi/zopefix/zc.buildout/trunk/develop-eggs'.
Generated script '/home/adi/zopefix/zc.buildout/trunk/bin/buildout'.
adi at ubvm:~/zopefix/zc.buildout/trunk$ bin/buildout -t 2
Setting socket time out to 2 seconds
Develop: '/home/adi/zopefix/zc.buildout/trunk/zc.recipe.egg_'
Develop: '/home/adi/zopefix/zc.buildout/trunk/z3c.recipe.scripts_'
Develop: '/home/adi/zopefix/zc.buildout/trunk/.'
While:
  Installing.
  Getting section test.
  Initializing part test.
Error: Missing option: buildout:find-links

Weird is that it works for the second time:

adi at ubvm:~/zopefix/zc.buildout/trunk$ bin/buildout -t 2
Setting socket time out to 2 seconds
Upgraded:
  zc.buildout version 1.5.0dev;
restarting.
Generated script '/home/adi/zopefix/zc.buildout/trunk/bin/buildout'.
Setting socket time out to 2 seconds
Develop: '/home/adi/zopefix/zc.buildout/trunk/zc.recipe.egg_'
Develop: '/home/adi/zopefix/zc.buildout/trunk/z3c.recipe.scripts_'
Develop: '/home/adi/zopefix/zc.buildout/trunk/.'
Installing test.
Generated script '/home/adi/zopefix/zc.buildout/trunk/bin/test'.
Installing oltest.
Generated script '/home/adi/zopefix/zc.buildout/trunk/bin/oltest'.
Installing py.
Generated script '/home/adi/zopefix/zc.buildout/trunk/bin/buildout'.
Generated script '/home/adi/zopefix/zc.buildout/trunk/bin/zope-testrunner'.
Generated interpreter '/home/adi/zopefix/zc.buildout/trunk/bin/py'.


Thursday, July 8, 2010, 4:45:47 PM, you wrote:

FD> On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER <agroszer at gmail.com> wrote:
>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>> ubuntu. Does it work for you?

FD> It builds for me (Python 2.6 w/ distribute; haven't tried with
FD> setuptools), but the tests aren't passing because someone added a
FD> dependency on zope.testing, but hasn't fixed the declared
FD> dependencies.


FD>   -Fred



-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
As sure as God puts His children in the furnace of affliction, He will be with them in it. 
- Charles Haddon Spurgeon 


From faassen at startifact.com  Thu Jul  8 17:43:27 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 08 Jul 2010 17:43:27 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <128034701.20100708171502@gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org>
	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
Message-ID: <i14rn0$1j9$2@dough.gmane.org>

Hey,

On 07/08/2010 05:15 PM, Adam GROSZER wrote:
[snip]
> While:
>    Installing.
>    Getting section test.
>    Initializing part test.
> Error: Missing option: buildout:find-links

I can reproduce that error. It also worked the second time for me, 
though in my case I added an '-n' option to make sure it got the newest 
versions of all dependencies.

Regards,

Martijn


From faassen at startifact.com  Thu Jul  8 17:45:47 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 08 Jul 2010 17:45:47 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
Message-ID: <i14rrd$1j9$3@dough.gmane.org>

On 07/08/2010 04:45 PM, Fred Drake wrote:
> On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER<agroszer at gmail.com>  wrote:
>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>> ubuntu. Does it work for you?
>
> It builds for me (Python 2.6 w/ distribute; haven't tried with
> setuptools), but the tests aren't passing because someone added a
> dependency on zope.testing, but hasn't fixed the declared
> dependencies.

I got it to build too (Python 2.6 with distribute too), and had test 
failures too due to a missing zope.testing. I added a 'zope.testing' 
dependency but I still get a lot of errors, including 
MissingDistribution errors involving distribute.

Regards,

Martijn


From gary.poster at canonical.com  Thu Jul  8 17:58:34 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 11:58:34 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <128034701.20100708171502@gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
Message-ID: <5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>

My apologies.

There is a branch that addresses all reported issues (as reported here and in Launchpad) except one: svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/ (or browse in http://svn.zope.org/zc.buildout/branches/gary-betafix/).

Most notably, virtualenv users will have the pre-1.5 behavior.  The automated tests for this are ugly, but exist.

The remaining reported bug is from Lennart Regebro.  I will include his original message at the end of the email.

Once that is done, I would prefer another beta release.  The problems after the last beta release affected many people.  As Tarek mentioned, we do not have a real way to make a beta release, given the current bootstrap.py *and* how it is often used as an svn external.  Some people also do not specify a buildout version, so changing PyPI will immediately affect them.  I have not seen a solution that I believe will actually both provide isolation and encourage people to try the beta out easily.

This situation has been a demotivator for me.  I can't even merge my branch without effect, because it will force some people to change their bootstrap.py scripts.  I don't want to do that until I have some time in my schedule cleared out to deal with possible fallout.

That, combined with being very busy, is all my excuse, for what it is worth.

In any case, to repeat and sum, the following remains:

- Identify and fix the problem reported by Lennart (below).
- Ideally, encourage people to try out the code in a controlled environment.  In order for this to not be a "release" in any way, people will have to manually use the new bootstrap if they want the new isolation, because I can't merge to trunk without effect; and will have to somehow get a new buildout distribution.  I've toyed with allowing it for download on Launchpad, or with putting it in PyPI with a b0 designation.
- Make a release
- (Deal with any remaining fallout)

If someone helped with Lennart's bug, that would be great.

If several someones volunteered to help test some kind of manual "beta" release, that would be great.

Gary



On Apr 30, 2010, at 3:46 PM, Lennart Regebro wrote:

Another bug:

In code like this:

def setUp(test):
   zc.buildout.testing.buildoutSetUp(test)
   zc.buildout.testing.install_develop('zc.recipe.testrunner', test)
   zc.buildout.testing.install_develop('zc.recipe.egg', test)
   zc.buildout.testing.install('zope.testing', test)
   zc.buildout.testing.install('zope.testrunner', test)
   zc.buildout.testing.install('zope.interface', test)
   zc.buildout.testing.install('zope.exceptions', test)

You get the following error:

Traceback (most recent call last):
 File "/opt/python26/lib/python2.6/doctest.py", line 2120, in setUp
   self._dt_setUp(test)
 File "/home/projects/zc.recipe.testrunner/trunk/src/zc/recipe/testrunner/tests.py",
line 25, in setUp
   zc.buildout.testing.buildoutSetUp(test)
 File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/testing.py",
line 332, in buildoutSetUp
   make_buildout()
 File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/testing.py",
line 272, in make_buildout
   ).bootstrap([])
 File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/buildout.py",
line 373, in bootstrap
   include_site_packages=False,
 File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/easy_install.py",
line 1030, in install
   return installer.install(specs, working_set)
 File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/easy_install.py",
line 843, in install
   for dist in self._get_dist(requirement, ws, self._always_unzip):
 File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/easy_install.py",
line 678, in _get_dist
   raise MissingDistribution(requirement, ws)
MissingDistribution: Couldn't find a distribution for 'distribute'.


Going back to 1.4.3 (and zc.recipe.egg 1.2.2 solves the problem.

From gary.poster at canonical.com  Thu Jul  8 18:00:57 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 12:00:57 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <128034701.20100708171502@gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
Message-ID: <D9B8B72E-5C4A-40D4-9F50-8CD32125B0B7@canonical.com>

> 
> 
> FD> On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER <agroszer at gmail.com> wrote:
>>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>>> ubuntu. Does it work for you?
> 
> FD> It builds for me (Python 2.6 w/ distribute; haven't tried with
> FD> setuptools), but the tests aren't passing because someone added a
> FD> dependency on zope.testing, but hasn't fixed the declared
> FD> dependencies.

Note that dev.py continues to be the supported way to build buildout's trunk, rather than using bootstrap.

Gary

From gary.poster at canonical.com  Thu Jul  8 18:05:29 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 12:05:29 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <i14rn0$1j9$2@dough.gmane.org>
References: <i14jq4$2ce$2@dough.gmane.org>
	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com> <i14rn0$1j9$2@dough.gmane.org>
Message-ID: <DED099AF-1314-4D42-BD8D-0C65105AC9A0@canonical.com>


On Jul 8, 2010, at 11:43 AM, Martijn Faassen wrote:

> Hey,
> 
> On 07/08/2010 05:15 PM, Adam GROSZER wrote:
> [snip]
>> While:
>>   Installing.
>>   Getting section test.
>>   Initializing part test.
>> Error: Missing option: buildout:find-links
> 
> I can reproduce that error. It also worked the second time for me, though in my case I added an '-n' option to make sure it got the newest versions of all dependencies.

I believe this is because of the re-release confusion.  dev.py on my branch does not have this behavior.  I suspect that this is, at most, an indication of a need to specify new dependencies given the re-release of zc.buildout and zc.recipe.egg.


From fdrake at acm.org  Thu Jul  8 18:06:38 2010
From: fdrake at acm.org (Fred Drake)
Date: Thu, 8 Jul 2010 12:06:38 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <D9B8B72E-5C4A-40D4-9F50-8CD32125B0B7@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org>
	<125219683.20100708163350@gmail.com> 
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com> 
	<128034701.20100708171502@gmail.com>
	<D9B8B72E-5C4A-40D4-9F50-8CD32125B0B7@canonical.com>
Message-ID: <AANLkTin47ZAUtXfcDENKuJ0watfueqeV5RPcc3H0c3nG@mail.gmail.com>

On Thu, Jul 8, 2010 at 12:00 PM, Gary Poster <gary.poster at canonical.com> wrote:
> Note that dev.py continues to be the supported way to build buildout's trunk, rather than using bootstrap.

I get the same errors using that, with either setuptools or
distribute.  All the errors relate to zope.testing references.

zope.testing is not mentioned in setup.py.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"A storm broke loose in my mind."  --Albert Einstein

From agroszer at gmail.com  Thu Jul  8 18:07:25 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Thu, 8 Jul 2010 18:07:25 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <D9B8B72E-5C4A-40D4-9F50-8CD32125B0B7@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<D9B8B72E-5C4A-40D4-9F50-8CD32125B0B7@canonical.com>
Message-ID: <965653550.20100708180725@gmail.com>

Hello Gary,

You mean I should do:
python2.5 dev.py
bin/buildout

then

bin/test

?

Thursday, July 8, 2010, 6:00:57 PM, you wrote:

>> 
>> 
>> FD> On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER <agroszer at gmail.com> wrote:
>>>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>>>> ubuntu. Does it work for you?
>> 
>> FD> It builds for me (Python 2.6 w/ distribute; haven't tried with
>> FD> setuptools), but the tests aren't passing because someone added a
>> FD> dependency on zope.testing, but hasn't fixed the declared
>> FD> dependencies.

GP> Note that dev.py continues to be the supported way to build
GP> buildout's trunk, rather than using
GP> bootstrap.

GP> Gary


-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
Like a good chess player, Satan is always trying to manoeuvre you into a position where you can save your castle only by losing your bishop. 
- C.S. Lewis 


From gary.poster at canonical.com  Thu Jul  8 18:08:10 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 12:08:10 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTin47ZAUtXfcDENKuJ0watfueqeV5RPcc3H0c3nG@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<D9B8B72E-5C4A-40D4-9F50-8CD32125B0B7@canonical.com>
	<AANLkTin47ZAUtXfcDENKuJ0watfueqeV5RPcc3H0c3nG@mail.gmail.com>
Message-ID: <A8859B5F-B2AF-44B3-948B-911CBB275CB2@canonical.com>


On Jul 8, 2010, at 12:06 PM, Fred Drake wrote:

> On Thu, Jul 8, 2010 at 12:00 PM, Gary Poster <gary.poster at canonical.com> wrote:
>> Note that dev.py continues to be the supported way to build buildout's trunk, rather than using bootstrap.
> 
> I get the same errors using that, with either setuptools or
> distribute.  All the errors relate to zope.testing references.
> 
> zope.testing is not mentioned in setup.py.

That is true.  This actually doesn't have anything to do with my changes but because of zope.testing changes.  Please try the branch I mentioned: it fixes this, among other things.

Gary


From gary.poster at canonical.com  Thu Jul  8 18:08:22 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 12:08:22 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <i14rrd$1j9$3@dough.gmane.org>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
Message-ID: <DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>


On Jul 8, 2010, at 11:45 AM, Martijn Faassen wrote:

> On 07/08/2010 04:45 PM, Fred Drake wrote:
>> On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER<agroszer at gmail.com>  wrote:
>>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>>> ubuntu. Does it work for you?
>> 
>> It builds for me (Python 2.6 w/ distribute; haven't tried with
>> setuptools), but the tests aren't passing because someone added a
>> dependency on zope.testing, but hasn't fixed the declared
>> dependencies.
> 
> I got it to build too (Python 2.6 with distribute too), and had test failures too due to a missing zope.testing. I added a 'zope.testing' dependency but I still get a lot of errors, including MissingDistribution errors involving distribute.


Please try my branch, with dev.py, as mentioned.


From gary.poster at canonical.com  Thu Jul  8 18:11:25 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 12:11:25 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <965653550.20100708180725@gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<D9B8B72E-5C4A-40D4-9F50-8CD32125B0B7@canonical.com>
	<965653550.20100708180725@gmail.com>
Message-ID: <B762B58D-E217-4065-889E-5ECC5DCABA25@canonical.com>


On Jul 8, 2010, at 12:07 PM, Adam GROSZER wrote:

> Hello Gary,
> 
> You mean I should do:
> python2.5 dev.py
> bin/buildout
> 
> then
> 
> bin/test
> 
> ?

Using the branch I mentioned, you should do

[python2.5 or 2.6 or even 2.4] dev.py
bin/test

IOW, dev.py runs bin/buildout, and you should use my branch if you don't want test failures.

To my knowledge, the test failures on trunk come from two sources: zope.testing changes and my inclusion of the old bootstrap so that virtualenv users who use svn externals to include bootstrap are OK.

If there are other test failures on my branch, they are new, and presumably related to dependency changes.

Gary


> 
> Thursday, July 8, 2010, 6:00:57 PM, you wrote:
> 
>>> 
>>> 
>>> FD> On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER <agroszer at gmail.com> wrote:
>>>>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>>>>> ubuntu. Does it work for you?
>>> 
>>> FD> It builds for me (Python 2.6 w/ distribute; haven't tried with
>>> FD> setuptools), but the tests aren't passing because someone added a
>>> FD> dependency on zope.testing, but hasn't fixed the declared
>>> FD> dependencies.
> 
> GP> Note that dev.py continues to be the supported way to build
> GP> buildout's trunk, rather than using
> GP> bootstrap.
> 
> GP> Gary
> 
> 
> -- 
> Best regards,
> Adam GROSZER                            mailto:agroszer at gmail.com
> --
> Quote of the day:
> Like a good chess player, Satan is always trying to manoeuvre you into a position where you can save your castle only by losing your bishop. 
> - C.S. Lewis 
> 


From faassen at startifact.com  Thu Jul  8 18:14:39 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 08 Jul 2010 18:14:39 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org>
	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>	<128034701.20100708171502@gmail.com>
	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
Message-ID: <i14thh$9n2$1@dough.gmane.org>

Hi there,

On 07/08/2010 05:58 PM, Gary Poster wrote:
> If several someones volunteered to help test some kind of manual "beta" release, that would be great.

I'd be happy to try such a beta release with Grok and report back.

Regards,

Martijn


From agroszer at gmail.com  Thu Jul  8 18:27:42 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Thu, 8 Jul 2010 18:27:42 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
Message-ID: <1056877359.20100708182742@gmail.com>

Hello Gary,

Just in case you find time, I adjusted the winbot to do
python dev.py. It should test then the trunk for you.

Thursday, July 8, 2010, 5:58:34 PM, you wrote:

<snip>
-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
Love doesn't just sit there like a stone, it has to be made, like bread; remade all the time, made new. 
- Ursula K. LeGuin 


From gary.poster at canonical.com  Thu Jul  8 18:52:15 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 12:52:15 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
Message-ID: <BAB1175F-399A-4433-BDC0-79954531ED5E@canonical.com>


On Jul 8, 2010, at 12:13 PM, Martijn Faassen wrote:

> Hi there,

Hi.

> 
> Trying the beta-fix branch on python 2.6.5 with distribute (0.6.13)  I
> get the following error when bootstrapping:

...

(Thank you for your offer to try out the new release!  I'll take you up on it.)

For clarity and speed, I resort to copy and paste below this message for my answer.  The sum is, it works if you spell it the expected way.

Since the discussion has arisen, I also ran tests.

Note that, to run all tests, you continue to need to run with something like.

env PYTHON2.4=/path/to/clean/Python2.4 bin/test

Note also that there is a preexisting race-condition bug of some sort--a file does not get deleted sometimes, at least in some operating systems--that I did not address.  When it bites in a doctest, it pollutes the rest of the output of that doctest.

In any case, here are the test results I saw.

With setuptools (that is, when dev,py is not started with -d), in a fresh checkout, there is a single failure to one test (zc.buildout.tests.handle_sys_path_version_hack).  That passes in an existing local branch I have, so the failure is a surprise to me, but hopefully that will be trivial to fix.

With distribute, it looks like distribute has changed since I ran the tests with it last.  I keep seeing new instances of messages like "install_dir /sample-buildout/develop-eggs/tmpXNNXoGbuild".  This is causing a lot of trivial test failures that I can squelch with a regex or something.  Other than that, it looks fine on a quick glance.

Gary




[In this example, 26python is a clean Python.  While buildout now supports a system Python, I did not make that effort for buildout's development itself.]

$ svn co svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/
...
Checked out revision 114336.

$ cd gary-betafix/

$ 26python -V
Python 2.6.5

$ 26python dev.py --help
Usage: [DESIRED PYTHON FOR DEVELOPING BUILDOUT] dev.py [options]

Bootstraps buildout itself for development.

This is different from a normal bootstrapping process because the
buildout egg itself is installed as a develop egg.


Options:
  -h, --help        show this help message and exit
  -d, --distribute  Use Distribute rather than Setuptools.

$ 26python dev.py -d
...
(it succeeds)

From faassen at startifact.com  Thu Jul  8 18:57:19 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 08 Jul 2010 18:57:19 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org>
	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
Message-ID: <i1501h$j8r$1@dough.gmane.org>

On 07/08/2010 06:08 PM, Gary Poster wrote:
>
> Please try my branch, with dev.py, as mentioned.

Oops, forgot to try it with dev.py.

Regards,

Martijn


From faassen at startifact.com  Thu Jul  8 18:13:53 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 8 Jul 2010 18:13:53 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
Message-ID: <AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>

Hi there,

Trying the beta-fix branch on python 2.6.5 with distribute (0.6.13)  I
get the following error when bootstrapping:

Downloading http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 1712, in main

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 1700, in with_ei_usage

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 1716, in <lambda>

  File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
    cmd_obj.run()
  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 211, in run

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 446, in easy_install

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 476, in install_item

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 655, in install_eggs

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 930, in build_and_install

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py",
line 919, in run_setup

  File "/tmp/tmpLZNcjQ/setuptools-0.6c11-py2.6.egg/setuptools/sandbox.py",
line 52, in run_setup
AttributeError: 'module' object has no attribute '__getstate__'
An error occured when trying to install zc.buildout. Look above this
message for any errors that were output by easy_install.

What strikes me as peculiar is why setuptools is downloaded while I
have distribute installed, but that might be normal, I don't know.

Regards,

Martijn

From faassen at startifact.com  Thu Jul  8 18:58:37 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 8 Jul 2010 18:58:37 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
Message-ID: <AANLkTilmK_AW48flC-R4B1bUQAeRvt0fLMlPgMhGJueQ@mail.gmail.com>

Hey,

On Thu, Jul 8, 2010 at 6:13 PM, Martijn Faassen <faassen at startifact.com> wrote:
> Trying the beta-fix branch on python 2.6.5 with distribute (0.6.13) ?I
> get the following error when bootstrapping:

Oops, I realized I should use dev.py instead. That does work, but the
tests fail with a lot of MissingDistribution: Couldn't find a
distribution for 'distribute'.

Regards,

Martijn

From gary.poster at canonical.com  Thu Jul  8 19:04:39 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 13:04:39 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTilmK_AW48flC-R4B1bUQAeRvt0fLMlPgMhGJueQ@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
	<AANLkTilmK_AW48flC-R4B1bUQAeRvt0fLMlPgMhGJueQ@mail.gmail.com>
Message-ID: <E8B659E9-6995-4354-8129-C350FD65570B@canonical.com>


On Jul 8, 2010, at 12:58 PM, Martijn Faassen wrote:

> Hey,
> 
> On Thu, Jul 8, 2010 at 6:13 PM, Martijn Faassen <faassen at startifact.com> wrote:
>> Trying the beta-fix branch on python 2.6.5 with distribute (0.6.13)  I
>> get the following error when bootstrapping:
> 
> Oops, I realized I should use dev.py instead. That does work, but the
> tests fail with a lot of MissingDistribution: Couldn't find a
> distribution for 'distribute'.

Hm, I don't get those at all--only what I reported.

Was this a clean Python?

Gary

From faassen at startifact.com  Thu Jul  8 19:05:40 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 8 Jul 2010 19:05:40 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <BAB1175F-399A-4433-BDC0-79954531ED5E@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
	<BAB1175F-399A-4433-BDC0-79954531ED5E@canonical.com>
Message-ID: <AANLkTin7IhgOCkVrDN5mjlqN9ZtqmfOYEopyVv5aa04P@mail.gmail.com>

Hi there,

Some more detailed feedback about failures (with dev.py this time). My
failures at first glance all seem to look like this:

Error in test /home/faassen/projects/buildout-betafix/src/zc/buildout/buildout.txt
Traceback (most recent call last):
  File "/usr/lib/python2.6/unittest.py", line 270, in run
    self.setUp()
  File "/home/faassen/.buildout/eggs/zope.testing-3.9.5-py2.6.egg/zope/testing/doctest/__init__.py",
line 2206, in setUp
    self._dt_setUp(test)
  File "/home/faassen/projects/buildout-betafix/src/zc/buildout/testing.py",
line 332, in buildoutSetUp
    make_buildout()
  File "/home/faassen/projects/buildout-betafix/src/zc/buildout/testing.py",
line 272, in make_buildout
    ).bootstrap([])
  File "/home/faassen/projects/buildout-betafix/src/zc/buildout/buildout.py",
line 377, in bootstrap
    include_site_packages=_sys_executable_has_broken_dash_S,
  File "/home/faassen/projects/buildout-betafix/src/zc/buildout/easy_install.py",
line 1069, in install
    return installer.install(specs, working_set)
  File "/home/faassen/projects/buildout-betafix/src/zc/buildout/easy_install.py",
line 876, in install
    for dist in self._get_dist(requirement, ws, self._always_unzip):
  File "/home/faassen/projects/buildout-betafix/src/zc/buildout/easy_install.py",
line 711, in _get_dist
    raise MissingDistribution(requirement, ws)
MissingDistribution: Couldn't find a distribution for 'distribute'.

Couldn't find index page for 'distribute' (maybe misspelled?)

I have 87 errors, and 1 failures, which appears to be a bunch of
problems in testing_bugfix.txt. I have these errors both if I run
dev.py with -d as well as without.

Regards,

Martijn

From faassen at startifact.com  Thu Jul  8 19:11:04 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 8 Jul 2010 19:11:04 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <E8B659E9-6995-4354-8129-C350FD65570B@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
	<AANLkTilmK_AW48flC-R4B1bUQAeRvt0fLMlPgMhGJueQ@mail.gmail.com>
	<E8B659E9-6995-4354-8129-C350FD65570B@canonical.com>
Message-ID: <AANLkTimL4RmP2nVoJKe3ZOpW5KJ_dVF0YJbwMJvE6uWL@mail.gmail.com>

On Thu, Jul 8, 2010 at 7:04 PM, Gary Poster <gary.poster at canonical.com> wrote:
>
> On Jul 8, 2010, at 12:58 PM, Martijn Faassen wrote:
>
>> Hey,
>>
>> On Thu, Jul 8, 2010 at 6:13 PM, Martijn Faassen <faassen at startifact.com> wrote:
>>> Trying the beta-fix branch on python 2.6.5 with distribute (0.6.13) ?I
>>> get the following error when bootstrapping:
>>
>> Oops, I realized I should use dev.py instead. That does work, but the
>> tests fail with a lot of MissingDistribution: Couldn't find a
>> distribution for 'distribute'.
>
> Hm, I don't get those at all--only what I reported.
>
> Was this a clean Python?

This is an Ubuntu python (with distribute already installed), so not
clean at all, my apologies for missing that. I tried to run it with a
2.6 virtualenv (with --no-site-packages) I have set up, but I get this
error:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named ConfigParser

and then this message:

/home/faassen/projects/buildout-betafix/src/zc/buildout/easy_install.py:1232:
UserWarning: Buildout has been asked to exclude or limit site-packages
so that builds can be repeatable when using a system Python.  However,
the chosen Python executable has a broken implementation of -S (see
https://bugs.launchpad.net/virtualenv/+bug/572545 for an example
problem) and this breaks buildout's ability to isolate site-packages.
If the executable already has a clean site-packages (e.g., using
virtualenv's ``--no-site-packages`` option) you may be getting
equivalent repeatability.  To silence this warning, use the -s
argument to the buildout script.  Alternatively, use a Python
executable with a working -S (such as a standard Python binary).
  warnings.warn(BROKEN_DASH_S_WARNING)
Upgraded:
  setuptools version 0.6c11;
restarting

In the virtualenv I get the tests running more slowly (so they're
doing more), and a ton of test failures; most do look shallow, such as
when this extra message is emitted in the output:

    Upgraded:
      setuptools version 0.6c11;
    restarting.
    Generated script '/sample-bootstrap/bin/buildout'.

Looks like I should try installing a fresh Python and try again.

Regards,

Martijn

From gary.poster at canonical.com  Thu Jul  8 19:12:26 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 13:12:26 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTimL4RmP2nVoJKe3ZOpW5KJ_dVF0YJbwMJvE6uWL@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
	<AANLkTilmK_AW48flC-R4B1bUQAeRvt0fLMlPgMhGJueQ@mail.gmail.com>
	<E8B659E9-6995-4354-8129-C350FD65570B@canonical.com>
	<AANLkTimL4RmP2nVoJKe3ZOpW5KJ_dVF0YJbwMJvE6uWL@mail.gmail.com>
Message-ID: <6D3FCF62-D65B-49FE-B471-59B0C86C8BDE@canonical.com>


On Jul 8, 2010, at 1:11 PM, Martijn Faassen wrote:
> 
> 
> Looks like I should try installing a fresh Python and try again.

Right.

Gary


From faassen at startifact.com  Thu Jul  8 20:04:36 2010
From: faassen at startifact.com (Martijn Faassen)
Date: Thu, 8 Jul 2010 20:04:36 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <BAB1175F-399A-4433-BDC0-79954531ED5E@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
	<BAB1175F-399A-4433-BDC0-79954531ED5E@canonical.com>
Message-ID: <AANLkTillRfW1ppX56uhDWYi628Cp6PDTo9932CtMiM_-@mail.gmail.com>

Hey again,

Sorry for the confusion earlier on; I am new to testing buildout
itself and I assumed it was easier than it inevitably is.

Now I'm trying to understand how in the world I'm to set an
environment variable with a period in it (PYTHON2.4, and I assume,
PYTHON2.5); it doesn't seem possible in bash.

Regards,

Martijn

From gary.poster at canonical.com  Thu Jul  8 22:08:01 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 8 Jul 2010 16:08:01 -0400
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTillRfW1ppX56uhDWYi628Cp6PDTo9932CtMiM_-@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<i14rrd$1j9$3@dough.gmane.org>
	<DA37838B-D999-4BA2-B979-3F034FBB85D9@canonical.com>
	<AANLkTilHVD7Wp07iD_kMMUNM_fmhaYA3LiF_TI7Mc3M3@mail.gmail.com>
	<BAB1175F-399A-4433-BDC0-79954531ED5E@canonical.com>
	<AANLkTillRfW1ppX56uhDWYi628Cp6PDTo9932CtMiM_-@mail.gmail.com>
Message-ID: <4E4C279A-726E-456B-B314-68F5D67CDE21@canonical.com>


On Jul 8, 2010, at 2:04 PM, Martijn Faassen wrote:

> Hey again,
> 
> Sorry for the confusion earlier on; I am new to testing buildout
> itself and I assumed it was easier than it inevitably is.
> 
> Now I'm trying to understand how in the world I'm to set an
> environment variable with a period in it (PYTHON2.4, and I assume,
> PYTHON2.5); it doesn't seem possible in bash.

This should work

env PYTHON2.4=foo bin/test

Gary

From gotcha at bubblenet.be  Fri Jul  9 09:06:34 2010
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Fri, 09 Jul 2010 09:06:34 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org>
	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>	<128034701.20100708171502@gmail.com>
	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
Message-ID: <4C36CA7A.3090301@bubblenet.be>

Le 08/07/10 17:58, Gary Poster a ?crit :
> My apologies.
>
> There is a branch that addresses all reported issues (as reported here and in Launchpad) except one: svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/ (or browse in http://svn.zope.org/zc.buildout/branches/gary-betafix/).

I have an opened branch with small fix to zc.recipe.egg.

http://svn.zope.org/zc.buildout/branches/gotcha-scripts-warning/

It adds a warning when a script name passed in 'scripts' argument of 
easy_install.scripts is not defined in egg entry points.

Is it ok to merge it into gary-betafix so that it gets included in next 
release ?

<snip>

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be


From h.goebel at goebel-consult.de  Fri Jul  9 17:43:18 2010
From: h.goebel at goebel-consult.de (Hartmut Goebel)
Date: Fri, 09 Jul 2010 17:43:18 +0200
Subject: [Distutils] Can't get "development mode" work as I like it
Message-ID: <4C374396.7050103@goebel-consult.de>

Hi,

I'm used to develop and test from within a single project-directory,
without any staging area, etc. As long as I did use scripts, this worked
very well. But when switching to pkg_resources entry-points, I get
problems: Now I need to ask easy_install (or setup.py develop ...) to
create the "scripts" for me.

Running

  python setup.py develop --install-dir . --script-dir .

gives an "error: bad install directory or PYTHONPATH" since the current
directory is not in PYTHONPATH.

I tried other options, too, eg. adding "--editable -b . -N", but with no
success. (This very one works as expected, but creates a
*.egg-link file which will make the next install recurse until dead.)

How can I make easy_install/distribute to generate only the scripts in
the current directory?

A typical setup for me looks like this:

project-a/
  setup.py
  README
  my_package/
     __init__.py
     ... more stuff ...

And I'm working like this:

cd project-a
# edit my_package/__init__.py
./my-script


-- 
Sch?nen Gru? - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP

Goebel Consult
Spezialist f?r IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4732 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100709/da94a4c6/attachment.bin>

From pje at telecommunity.com  Fri Jul  9 19:13:49 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 09 Jul 2010 13:13:49 -0400
Subject: [Distutils] Can't get "development mode" work as I like it
In-Reply-To: <4C374396.7050103@goebel-consult.de>
References: <4C374396.7050103@goebel-consult.de>
Message-ID: <20100709171340.596EF3A404D@sparrow.telecommunity.com>

At 05:43 PM 7/9/2010 +0200, Hartmut Goebel wrote:
>Hi,
>
>I'm used to develop and test from within a single project-directory,
>without any staging area, etc. As long as I did use scripts, this worked
>very well. But when switching to pkg_resources entry-points, I get
>problems: Now I need to ask easy_install (or setup.py develop ...) to
>create the "scripts" for me.
>
>Running
>
>   python setup.py develop --install-dir . --script-dir .
>
>gives an "error: bad install directory or PYTHONPATH" since the current
>directory is not in PYTHONPATH.

Installation to the current directory isn't supported, as it's rather 
a bad idea (for one thing, you could accidentally overwrite something).

My suggestion would be:

    mkdir bin
    python setup.py develop -md bin
    bin/scriptname (to run a script)

Notice that the use of the -m flag means that the 'bin' directory 
doesn't have to be on PYTHONPATH for this to work.  There will simply 
be an .egg-link file placed there, along with your scripts.


From gotcha at bubblenet.be  Sat Jul 10 10:52:48 2010
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Sat, 10 Jul 2010 10:52:48 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <4C36CA7A.3090301@bubblenet.be>
References: <i14jq4$2ce$2@dough.gmane.org>	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>	<128034701.20100708171502@gmail.com>	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
	<4C36CA7A.3090301@bubblenet.be>
Message-ID: <4C3834E0.3070400@bubblenet.be>

Le 09/07/10 09:06, Godefroid Chapelle a ?crit :
> Le 08/07/10 17:58, Gary Poster a ?crit :
>> My apologies.
>>
>> There is a branch that addresses all reported issues (as reported here
>> and in Launchpad) except one:
>> svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/
>> (or browse in http://svn.zope.org/zc.buildout/branches/gary-betafix/).
>
> I have an opened branch with small fix to zc.recipe.egg.
>
> http://svn.zope.org/zc.buildout/branches/gotcha-scripts-warning/
>
> It adds a warning when a script name passed in 'scripts' argument of
> easy_install.scripts is not defined in egg entry points.
>
> Is it ok to merge it into gary-betafix so that it gets included in next
> release ?
>
> <snip>
>

There is another branch waiting for a long time :

http://svn.zope.org/zc.buildout/branches/gotcha-timeout-cfg/

It allows configuration of socket timeout from cfg files.

Please lemme know when to merge it and where; I'd be disappointed that 
next buildout release comes without it.

Regards

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From gotcha at bubblenet.be  Sat Jul 10 10:52:48 2010
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Sat, 10 Jul 2010 10:52:48 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <4C36CA7A.3090301@bubblenet.be>
References: <i14jq4$2ce$2@dough.gmane.org>	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>	<128034701.20100708171502@gmail.com>	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
	<4C36CA7A.3090301@bubblenet.be>
Message-ID: <4C3834E0.3070400@bubblenet.be>

Le 09/07/10 09:06, Godefroid Chapelle a ?crit :
> Le 08/07/10 17:58, Gary Poster a ?crit :
>> My apologies.
>>
>> There is a branch that addresses all reported issues (as reported here
>> and in Launchpad) except one:
>> svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/
>> (or browse in http://svn.zope.org/zc.buildout/branches/gary-betafix/).
>
> I have an opened branch with small fix to zc.recipe.egg.
>
> http://svn.zope.org/zc.buildout/branches/gotcha-scripts-warning/
>
> It adds a warning when a script name passed in 'scripts' argument of
> easy_install.scripts is not defined in egg entry points.
>
> Is it ok to merge it into gary-betafix so that it gets included in next
> release ?
>
> <snip>
>

There is another branch waiting for a long time :

http://svn.zope.org/zc.buildout/branches/gotcha-timeout-cfg/

It allows configuration of socket timeout from cfg files.

Please lemme know when to merge it and where; I'd be disappointed that 
next buildout release comes without it.

Regards

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be


From shimizukawa at gmail.com  Sun Jul 11 10:47:44 2010
From: shimizukawa at gmail.com (Takayuki Shimizukawa)
Date: Sun, 11 Jul 2010 17:47:44 +0900
Subject: [Distutils] `setup.py register` can't create PyPI account.
Message-ID: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>

Hi.

I wasn't able to make an account in PyPI using `setup.py register`.

http://pypi.python.org/pypi?:action=register_form require 'I agree'
checkbox, but `distutils/command/register.py` doesn't seem to send
a 'agree' form key/value to the PyPI server.

This problem occurs in the major python versions (include 2.7).

This introduced for PyPI site by
https://svn.python.org/packages/trunk/pypi/webui.py rev-690.

regards.
--
Takayuki SHIMIZUKAWA

From fdrake at acm.org  Sun Jul 11 19:29:36 2010
From: fdrake at acm.org (Fred Drake)
Date: Sun, 11 Jul 2010 13:29:36 -0400
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
Message-ID: <AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>

On Sun, Jul 11, 2010 at 4:47 AM, Takayuki Shimizukawa
<shimizukawa at gmail.com> wrote:
> I wasn't able to make an account in PyPI using `setup.py register`.

The name of the "register" command is a little confusing.  It's
purpose is *not* to allow you to register yourself with PyPI, but to
register package information with the site.

You need to use the web interface to create your account.  When using
"setup.py register", you'll be asked to authenticate using the account
you created via the web.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"A storm broke loose in my mind."  --Albert Einstein

From john at industromatic.com  Sun Jul 11 21:18:40 2010
From: john at industromatic.com (John Griessen)
Date: Sun, 11 Jul 2010 14:18:40 -0500
Subject: [Distutils] buildout dependencies trouble
Message-ID: <4C3A1910.9010903@industromatic.com>

I've been making a buildout.cfg for deploying web sites and hit some snags.

django-page-cms is a package I want, and getting it via buildout
found eggs for other apps, but needed source for django-page-cms.
 From there, some requirements, (don't know where they are in the code),
pulled in packages django-haystack, django-messages, whoosh, django-mptt-2,
and coverage.

I think to build the source only absolutely requires django-mptt-2.

whoosh and coverage have had problems.  buildout found whoosh as
a zipped egg and left it zipped even though putting it in the common eggs
directory where all others are unzipped and a python path points to them
for use when code runs.  To get a complete build, I manually unzipped.
I'm not moving eggs and downloads to my server, so buildout on the
server needed the same treatment.

coverage was found OK from my local machine, but not from the server.
I'm not sure yet why.

I'll try using bin/buidout -D  (Debug errors.)  soon.

Any other suggestions?

John

From shimizukawa at gmail.com  Mon Jul 12 13:07:57 2010
From: shimizukawa at gmail.com (Takayuki Shimizukawa)
Date: Mon, 12 Jul 2010 20:07:57 +0900
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com> 
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
Message-ID: <AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>

Hi Fred,

2010/7/12 Fred Drake <fdrake at acm.org>:
> On Sun, Jul 11, 2010 at 4:47 AM, Takayuki Shimizukawa
> <shimizukawa at gmail.com> wrote:
>> I wasn't able to make an account in PyPI using `setup.py register`.
-snip-
> You need to use the web interface to create your account. ?When using
> "setup.py register", you'll be asked to authenticate using the account
> you created via the web.

ok, I was able to make an account via the web interface.

However, the usage of the register command is written on a
manual (http://docs.python.org/distutils/packageindex.html), and
many people will meet with the same problem by using the method.

I think it is necessary to correct command/register.py or PyPI site.

regards.
-- 
Takayuki SHIMIZUKAWA

From merwok at netwok.org  Mon Jul 12 13:33:18 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 12 Jul 2010 13:33:18 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
Message-ID: <4C3AFD7E.4060408@netwok.org>

> The name of the "register" command is a little confusing.  [Its]
> purpose is *not* to allow you to register yourself with PyPI, but to
> register package information with the site.

According to the doc pointed to by Takayuki, it?s both. I?ll open a bug
report against distutils and PyPI (if I find where to do that) if noone
does it sooner.

Regards


From fdrake at acm.org  Mon Jul 12 14:43:46 2010
From: fdrake at acm.org (Fred Drake)
Date: Mon, 12 Jul 2010 08:43:46 -0400
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com> 
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com> 
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
Message-ID: <AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>

On Mon, Jul 12, 2010 at 7:07 AM, Takayuki Shimizukawa
<shimizukawa at gmail.com> wrote:
> However, the usage of the register command is written on a
> manual (http://docs.python.org/distutils/packageindex.html), and
> many people will meet with the same problem by using the method.

I guess it's been a long time since I've seen that menu!

This does indicate a bug, which should be fixed.  Part of the fix
should include a test for PyPI that an account can be created using
the interface invoked by distutils.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"A storm broke loose in my mind."  --Albert Einstein

From jim at zope.com  Mon Jul 12 16:33:21 2010
From: jim at zope.com (Jim Fulton)
Date: Mon, 12 Jul 2010 10:33:21 -0400
Subject: [Distutils] buildout dependencies trouble
In-Reply-To: <4C3A1910.9010903@industromatic.com>
References: <4C3A1910.9010903@industromatic.com>
Message-ID: <AANLkTikO4l3O9CfXmGvh_5gArGt6nVUzrE6xDbUyxVFE@mail.gmail.com>

On Sun, Jul 11, 2010 at 3:18 PM, John Griessen <john at industromatic.com> wrote:
> I've been making a buildout.cfg for deploying web sites and hit some snags.
>
> django-page-cms is a package I want, and getting it via buildout
> found eggs for other apps, but needed source for django-page-cms.

I don't know what this means.

> From there, some requirements, (don't know where they are in the code),
> pulled in packages django-haystack, django-messages, whoosh, django-mptt-2,
> and coverage.
>
> I think to build the source only absolutely requires django-mptt-2.

Buildout pulls in the run-time requirements, as defined in the
packages install_requires.

>
> whoosh and coverage have had problems. ?buildout found whoosh as
> a zipped egg and left it zipped even though putting it in the common eggs
> directory where all others are unzipped and a python path points to them
> for use when code runs. ?To get a complete build, I manually unzipped.

Include:

  unzip = true

in the buildout section of your buildout.

...

> coverage was found OK from my local machine, but not from the server.
> I'm not sure yet why.
>
> I'll try using bin/buidout -D ?(Debug errors.) ?soon.
>
> Any other suggestions?

Try running with -v (verbode) or -vv (debug/very verbose)

Jim

-- 
Jim Fulton

From mailing at franzoni.eu  Mon Jul 12 18:19:20 2010
From: mailing at franzoni.eu (Alan Franzoni)
Date: Mon, 12 Jul 2010 18:19:20 +0200
Subject: [Distutils] zc.buildout - multiple 'cascading' buildout.cfg files
Message-ID: <4C3B4088.7030208@franzoni.eu>

Hello,
I'm wondering if there's a way to have something like "local"
buildout.cfg files overriding a "master" one; e.g.

if buildout.cfg is something like

[buildout]
parts = one
	two

[one]
...

[two]

...

I'd like to have something like buildout.cfg.local and insert something like

[one]
*****


And have the "one" section of buildout.cfg.local override what's set in
buildout.cfg, so that buildout acts like


[buildout]
parts = one
	two

[one]
*****

[two]

...


had been found.


This would be useful because in our projects we usually share one
per-project buildout.cfg which every team member uses and it's stored on
our VCS, and it's used all around including along our CI server, and we
don't want to change it if a real configuration change is unneeded, but
often I need to tinker with it (e.g. I want to use one additional
development egg, or change a dep, or run a different recipe).

Hence I'd like to have the chance to read a buildout.cfg.local - which I
could add into the ignore list of our VCS, be it svn, hg or whatever -
and leave the master buildout.cfg untouched.

Can I do it? If I can't right now, I'll be happy to code and submit a
patch. Any thoughts on what's the right approach? e.g. convention-based
naming (buildout.cfg.local.001 in the same dir as buildout.cfg, etc).

Thank you!


-- 
Alan Franzoni
contact me at public@[mysurname].eu

From chris at simplistix.co.uk  Mon Jul 12 20:19:24 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 12 Jul 2010 19:19:24 +0100
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <4C36CA7A.3090301@bubblenet.be>
References: <i14jq4$2ce$2@dough.gmane.org>	<125219683.20100708163350@gmail.com>	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>	<128034701.20100708171502@gmail.com>	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
	<4C36CA7A.3090301@bubblenet.be>
Message-ID: <4C3B5CAC.50308@simplistix.co.uk>

Godefroid Chapelle wrote:
> I have an opened branch with small fix to zc.recipe.egg.
> 
> http://svn.zope.org/zc.buildout/branches/gotcha-scripts-warning/
> 
> It adds a warning when a script name passed in 'scripts' argument of 
> easy_install.scripts is not defined in egg entry points.

Does this warning show if the entry point if defined in the .cfg rather 
than in the egg?

If so, it needs to be fixed ;-)

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From merwok at netwok.org  Mon Jul 12 22:19:36 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 12 Jul 2010 22:19:36 +0200
Subject: [Distutils] buildout dependencies trouble
In-Reply-To: <AANLkTikO4l3O9CfXmGvh_5gArGt6nVUzrE6xDbUyxVFE@mail.gmail.com>
References: <4C3A1910.9010903@industromatic.com>
	<AANLkTikO4l3O9CfXmGvh_5gArGt6nVUzrE6xDbUyxVFE@mail.gmail.com>
Message-ID: <4C3B78D8.2040004@netwok.org>

[Jim Fulton]
>[John Griessen]
>> I've been making a buildout.cfg for deploying web sites and hit some snags.
>>
>> django-page-cms is a package I want, and getting it via buildout
>> found eggs for other apps, but needed source for django-page-cms.
> 
> I don't know what this means.

I understood it so: I want to download django-page-cms with buildout,
which finds distributions in the form of eggs for some other projects
(probably dependencies of this one, or maybe unrelated django packages
just quoted as example), but buildout downloaded the source dist for
django-page-cms, not an egg.

Hope this helps. Regards


From martin at v.loewis.de  Mon Jul 12 23:22:56 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 12 Jul 2010 23:22:56 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
Message-ID: <4C3B87B0.4010905@v.loewis.de>

Am 12.07.2010 14:43, schrieb Fred Drake:
> On Mon, Jul 12, 2010 at 7:07 AM, Takayuki Shimizukawa
> <shimizukawa at gmail.com> wrote:
>> However, the usage of the register command is written on a
>> manual (http://docs.python.org/distutils/packageindex.html), and
>> many people will meet with the same problem by using the method.
> 
> I guess it's been a long time since I've seen that menu!
> 
> This does indicate a bug, which should be fixed.  Part of the fix
> should include a test for PyPI that an account can be created using
> the interface invoked by distutils.

That is not feasible. It might be necessary to break distutils again,
for whatever reason. So I'd rather suggest to remove the "register user"
functionality from distutils, and direct users to web signup.

Regards,
Martin

From ziade.tarek at gmail.com  Mon Jul 12 23:56:16 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 12 Jul 2010 23:56:16 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3B87B0.4010905@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
Message-ID: <AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>

On Mon, Jul 12, 2010 at 11:22 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 12.07.2010 14:43, schrieb Fred Drake:
>> On Mon, Jul 12, 2010 at 7:07 AM, Takayuki Shimizukawa
>> <shimizukawa at gmail.com> wrote:
>>> However, the usage of the register command is written on a
>>> manual (http://docs.python.org/distutils/packageindex.html), and
>>> many people will meet with the same problem by using the method.
>>
>> I guess it's been a long time since I've seen that menu!
>>
>> This does indicate a bug, which should be fixed. ?Part of the fix
>> should include a test for PyPI that an account can be created using
>> the interface invoked by distutils.
>
> That is not feasible. It might be necessary to break distutils again,
> for whatever reason. So I'd rather suggest to remove the "register user"
> functionality from distutils, and direct users to web signup.r

Why is that ? This used to work, IIRC. This is a regression on PyPI
side (checkbox added afaik), and needs  to be fixed.

We could think about deprecating it maybe, but we cannot break all
existing python versions with a change in the PyPI UI like that...

Regards
Tarek

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

From martin at v.loewis.de  Tue Jul 13 00:09:06 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Jul 2010 00:09:06 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
Message-ID: <4C3B9282.9050700@v.loewis.de>

> Why is that ? This used to work, IIRC. This is a regression on PyPI
> side (checkbox added afaik), and needs  to be fixed.

How would you propose to fix this?

> We could think about deprecating it maybe, but we cannot break all
> existing python versions with a change in the PyPI UI like that...

This happened several months ago, and nobody complained so far. So
I don't consider it a serious problem.

Regards,
Martin

From ziade.tarek at gmail.com  Tue Jul 13 00:15:26 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 13 Jul 2010 00:15:26 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3B9282.9050700@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
Message-ID: <AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>

2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
>> Why is that ? This used to work, IIRC. This is a regression on PyPI
>> side (checkbox added afaik), and needs ?to be fixed.
>
> How would you propose to fix this?

A quick hack is to look at the user agent (urllib2) and remove your
checkbox in this case.
A cleaner step would be to remove this and create a new UI page to
register the users
from within the web version, and change the human links in your web app.

>> We could think about deprecating it maybe, but we cannot break all
>> existing python versions with a change in the PyPI UI like that...
>
> This happened several months ago, and nobody complained so far. So
> I don't consider it a serious problem.

We have one complaint now, and I am complaining too. You cannot break
existing software then say you don't consider this a "serious" problem
because it's not widely used.

Are you really expecting me to remove silently this feature from all
python versions documentation and tell people it's not a serious
problem ?


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

From martin at v.loewis.de  Tue Jul 13 00:23:10 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Jul 2010 00:23:10 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
Message-ID: <4C3B95CE.8090606@v.loewis.de>

Am 13.07.2010 00:15, schrieb Tarek Ziad?:
> 2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
>>> Why is that ? This used to work, IIRC. This is a regression on PyPI
>>> side (checkbox added afaik), and needs  to be fixed.
>>
>> How would you propose to fix this?
> 
> A quick hack is to look at the user agent (urllib2) and remove your
> checkbox in this case.

That would be unacceptable, because the question is then not being
asked. Our legal counsel advised us that we must have such a checkbox,
and offering a way to bypass it defeats its purpose.

> A cleaner step would be to remove this and create a new UI page to
> register the users
> from within the web version, and change the human links in your web app.

This I don't understand. Is this essentially the same proposal: you
don't get asked the question if you register through distutils?

> We have one complaint now, and I am complaining too. You cannot break
> existing software then say you don't consider this a "serious" problem
> because it's not widely used.

Sure I can. If the PSF legal counsel tells me to make a change to PyPI,
I don't question that order, not even if complying means to break some code.

> Are you really expecting me to remove silently this feature from all
> python versions documentation and tell people it's not a serious
> problem ?

I think the whole notion of distutils being able to perform user
registration is flawed. This already is clear when you consider that
it actually *doesn't* register the user, but only initiates registration
so that the user has to complete registration over the
web. We might as well tell him to do the entire registration over the web.

Regards,
Martin

From ziade.tarek at gmail.com  Tue Jul 13 00:34:15 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 13 Jul 2010 00:34:15 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3B95CE.8090606@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
	<4C3B95CE.8090606@v.loewis.de>
Message-ID: <AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>

2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
> Am 13.07.2010 00:15, schrieb Tarek Ziad?:
>> 2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
>>>> Why is that ? This used to work, IIRC. This is a regression on PyPI
>>>> side (checkbox added afaik), and needs ?to be fixed.
>>>
>>> How would you propose to fix this?
>>
>> A quick hack is to look at the user agent (urllib2) and remove your
>> checkbox in this case.
>
> That would be unacceptable, because the question is then not being
> asked. Our legal counsel advised us that we must have such a checkbox,
> and offering a way to bypass it defeats its purpose.

There's a difference between a legal decision and a technical backward
compatibility issue.
Your change in the PyPI UI has broken the register command in
Distutils for Python 2.5 and onward.

If this legal issue is to be applied to *all* existing Python version
*immediatly*, we should create a security patch for all versions.


>> A cleaner step would be to remove this and create a new UI page to
>> register the users
>> from within the web version, and change the human links in your web app.
>
> This I don't understand. Is this essentially the same proposal: you
> don't get asked the question if you register through distutils?

No, because this is how it works in Python 2.5, 2.6, 2.7, 3.1
Again, the command is now broken because you have added a checkbox in PyPI.

This change is not a bad thing, don't get me wrong. But if you enforce
it for all Python versions, you basically break this feature.

The urllib2 user agent has the Python version in it. I suggest that
you bypass this change,
for all existing Python versions, and introduce it for Python 3.2


>
>> We have one complaint now, and I am complaining too. You cannot break
>> existing software then say you don't consider this a "serious" problem
>> because it's not widely used.
>
> Sure I can. If the PSF legal counsel tells me to make a change to PyPI,
> I don't question that order, not even if complying means to break some code.

But the PSF didn't tell you to break existing Python versions. I think
we need to find a better solution here.


>
>> Are you really expecting me to remove silently this feature from all
>> python versions documentation and tell people it's not a serious
>> problem ?
>
> I think the whole notion of distutils being able to perform user
> registration is flawed. This already is clear when you consider that
> it actually *doesn't* register the user, but only initiates registration
> so that the user has to complete registration over the
> web. We might as well tell him to do the entire registration over the web.

Again, maybe it's flawed, and maybe we should remove it. But you cannot
break this feature in Python 2.5, 26 etc.. because you find it flawed today.

Regards
Tarek
-- 
Tarek Ziad? | http://ziade.org

From martin at v.loewis.de  Tue Jul 13 00:47:37 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Jul 2010 00:47:37 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>	<4C3B9282.9050700@v.loewis.de>	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
Message-ID: <4C3B9B89.4090602@v.loewis.de>

> Your change in the PyPI UI has broken the register command in
> Distutils for Python 2.5 and onward.

Correct. Actually, older versions are also broken, back to 2.3.

> If this legal issue is to be applied to *all* existing Python version
> *immediatly*, we should create a security patch for all versions.

I disagree - that's not a security threat.

> No, because this is how it works in Python 2.5, 2.6, 2.7, 3.1
> Again, the command is now broken because you have added a checkbox in PyPI.

I fully understand that. However, changing PyPI to remove that checkbox
under certain conditions is not an option.

> This change is not a bad thing, don't get me wrong. But if you enforce
> it for all Python versions, you basically break this feature.

Correct.

> The urllib2 user agent has the Python version in it. I suggest that
> you bypass this change,
> for all existing Python versions, and introduce it for Python 3.2

Unfortunately, that's just not acceptable.

> But the PSF didn't tell you to break existing Python versions. I think
> we need to find a better solution here.

Sure. However, bypassing the checkbox is not an option.

How about this: we issue a 401 error response, telling users to register
over the web? IIUC, distutils will display this message.

> Again, maybe it's flawed, and maybe we should remove it. But you cannot
> break this feature in Python 2.5, 26 etc.. because you find it flawed today.

And it's not the reason that I broke it. Instead, the reason is that the
PSF required me to make the change. I didn't even remember that this
would break distutils. Now that I think about it, I think it's distutils
that needs to get fixed going forward. For backwards compatibility, I'm
willing to accept solutions as long as they don't allow users to bypass
that checkbox.

Regards,
Martin

From ziade.tarek at gmail.com  Tue Jul 13 01:02:04 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 13 Jul 2010 01:02:04 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3B9B89.4090602@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
	<4C3B9B89.4090602@v.loewis.de>
Message-ID: <AANLkTimZhSnn2m29lqmyd4V5FjfVE9d5sQSNtD_oXBh9@mail.gmail.com>

2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
...
>
>> Again, maybe it's flawed, and maybe we should remove it. But you cannot
>> break this feature in Python 2.5, 26 etc.. because you find it flawed today.
>
> And it's not the reason that I broke it. Instead, the reason is that the
> PSF required me to make the change. I didn't even remember that this
> would break distutils. Now that I think about it, I think it's distutils
> that needs to get fixed going forward. For backwards compatibility, I'm
> willing to accept solutions as long as they don't allow users to bypass
> that checkbox.

I understand why you did that change, and I understand the reasons.
We also agree that Distutils needs to be fixed, and this is being
worked out in Distutils2.

But I strongly disagree that its better to break existing Python
versions to comply with the PSF legal policy. I think this is a
mistake, and I think it's acceptable to bypass that policy in
distutils. That policy didn't exist back then, so it makes perfectly
sense not to have it in Distutils.

Furthermore, I would like if possible, that all changes in PyPI that
may impact existing software, to be discussed, so we can be aware of
such problems.

(I am sending a mail to the PSF list, because I would like to defend
my opinion for the legal aspect)

Regards
Tarek


>
> Regards,
> Martin
>



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

From jeremy.kloth at gmail.com  Tue Jul 13 01:09:56 2010
From: jeremy.kloth at gmail.com (Jeremy Kloth)
Date: Mon, 12 Jul 2010 17:09:56 -0600
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
Message-ID: <201007121709.57011.jeremy.kloth@gmail.com>

On Monday, July 12, 2010 04:15:26 pm Tarek Ziad? wrote:
> 2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
> >> Why is that ? This used to work, IIRC. This is a regression on PyPI
> >> side (checkbox added afaik), and needs  to be fixed.
> > 
> > How would you propose to fix this?
> 
> A quick hack is to look at the user agent (urllib2) and remove your
> checkbox in this case.
> A cleaner step would be to remove this and create a new UI page to
> register the users
> from within the web version, and change the human links in your web app.

There is the problem, then, of updating the client software (distutils) to 
perform the function for why the checkbox was added in the first place.

It is possible that the checkbox was added in response to legal issues (just 
guessing, as it happened around the same time as other legal questions).  
Then, IMO, it is required to break (or update) existing client code.

> >> We could think about deprecating it maybe, but we cannot break all
> >> existing python versions with a change in the PyPI UI like that...

You need to know the reason for the addition before coming to conclusions.

> Are you really expecting me to remove silently this feature from all
> python versions documentation and tell people it's not a serious
> problem ?

If lawyers are involved, there is little to be done.

Jeremy Kloth

From dave at krondo.com  Tue Jul 13 01:59:54 2010
From: dave at krondo.com (Dave Peticolas)
Date: Mon, 12 Jul 2010 16:59:54 -0700
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
Message-ID: <AANLkTin84m8k4eR5Le84FkRxuRGXx_a_231KbUzhftPr@mail.gmail.com>

On Thu, Jul 8, 2010 at 8:58 AM, Gary Poster <gary.poster at canonical.com>wrote:

> My apologies.
>
> There is a branch that addresses all reported issues (as reported here and
> in Launchpad) except one: svn+ssh://
> svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/ (or browse in
> http://svn.zope.org/zc.buildout/branches/gary-betafix/).
>
> Most notably, virtualenv users will have the pre-1.5 behavior.  The
> automated tests for this are ugly, but exist.
>
> The remaining reported bug is from Lennart Regebro.  I will include his
> original message at the end of the email.
>
> Once that is done, I would prefer another beta release.  The problems after
> the last beta release affected many people.  As Tarek mentioned, we do not
> have a real way to make a beta release, given the current bootstrap.py *and*
> how it is often used as an svn external.  Some people also do not specify a
> buildout version, so changing PyPI will immediately affect them.  I have not
> seen a solution that I believe will actually both provide isolation and
> encourage people to try the beta out easily.
>
> This situation has been a demotivator for me.  I can't even merge my branch
> without effect, because it will force some people to change their
> bootstrap.py scripts.  I don't want to do that until I have some time in my
> schedule cleared out to deal with possible fallout.
>
> That, combined with being very busy, is all my excuse, for what it is
> worth.
>
> In any case, to repeat and sum, the following remains:
>
> - Identify and fix the problem reported by Lennart (below).
> - Ideally, encourage people to try out the code in a controlled
> environment.  In order for this to not be a "release" in any way, people
> will have to manually use the new bootstrap if they want the new isolation,
> because I can't merge to trunk without effect; and will have to somehow get
> a new buildout distribution.  I've toyed with allowing it for download on
> Launchpad, or with putting it in PyPI with a b0 designation.
> - Make a release
> - (Deal with any remaining fallout)
>
> If someone helped with Lennart's bug, that would be great.
>
> If several someones volunteered to help test some kind of manual "beta"
> release, that would be great.
>

I'm testing out the beta branch and running into a problem. I'm running
buildout from a virtualenv,
and when I try to install the 'superlance' package, I get this:

  The required version of setuptools (>=0.6c9) is not available, and
  can't be installed while this script is running. Please install
  a more recent version first, using 'easy_install -U setuptools'.

  (Currently using setuptools 0.6c8 (/usr/lib/python2.5/site-packages))
  error: Setup script exited with 2

This is despite the fact that I have 0.6c11 installed in the virtualenv.
This seems to be caused
by the fact that the buildout bin script has this:

  import sys
  sys.path[0:0] = [
      '/tmp/ve/eggs/zc.buildout-1.5.0b2-py2.5.egg',
      '/usr/lib/python2.5/site-packages',
      ]

And thus picks up the older version of setuptools in /usr/lib/python2.5. I
tried removing those lines,
but buildout seems to be re-creating that file when I run it.

Any suggestions?

thanks,
dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100712/d6bfd605/attachment-0001.html>

From tseaver at palladion.com  Tue Jul 13 02:32:07 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 12 Jul 2010 20:32:07 -0400
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTimZhSnn2m29lqmyd4V5FjfVE9d5sQSNtD_oXBh9@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>	<4C3B9282.9050700@v.loewis.de>	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>	<4C3B95CE.8090606@v.loewis.de>	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>	<4C3B9B89.4090602@v.loewis.de>
	<AANLkTimZhSnn2m29lqmyd4V5FjfVE9d5sQSNtD_oXBh9@mail.gmail.com>
Message-ID: <i1gc67$9qs$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:
> 2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
> ...
>>> Again, maybe it's flawed, and maybe we should remove it. But you cannot
>>> break this feature in Python 2.5, 26 etc.. because you find it flawed today.
>> And it's not the reason that I broke it. Instead, the reason is that the
>> PSF required me to make the change. I didn't even remember that this
>> would break distutils. Now that I think about it, I think it's distutils
>> that needs to get fixed going forward. For backwards compatibility, I'm
>> willing to accept solutions as long as they don't allow users to bypass
>> that checkbox.
> 
> I understand why you did that change, and I understand the reasons.
> We also agree that Distutils needs to be fixed, and this is being
> worked out in Distutils2.
> 
> But I strongly disagree that its better to break existing Python
> versions to comply with the PSF legal policy. I think this is a
> mistake, and I think it's acceptable to bypass that policy in
> distutils. That policy didn't exist back then, so it makes perfectly
> sense not to have it in Distutils.

The breakage you are talking about here is only for an *extremely rare*
case:  a user rund 'setup.py register' without having first created an
account through the web UI.  I think Martin is right, and that the fact
that it used to work was an undocumented misfeature (even a security hole).

Forcing people to register through the web in order to keep the usage
license enforced is a valid requirement:  you can't just wish it away by
saying "We didn't use to have to do that."


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkw7tAEACgkQ+gerLs4ltQ6NKgCgsE7+kOdMghuqSiI38Voq3cUH
WW4AoKyx35Cbr+zEtZZ1JPYSHvSJA8Ir
=yPiO
-----END PGP SIGNATURE-----


From greg.ewing at canterbury.ac.nz  Tue Jul 13 03:23:40 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 13 Jul 2010 13:23:40 +1200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3B9B89.4090602@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
	<4C3B9B89.4090602@v.loewis.de>
Message-ID: <4C3BC01C.7060100@canterbury.ac.nz>

Martin v. L?wis wrote:

>  For backwards compatibility, I'm
> willing to accept solutions as long as they don't allow users to bypass
> that checkbox.

If the user is required to visit a web page to complete
the registration, could you put the check box on *that*
page instead?

-- 
Greg

From hltbra at gmail.com  Tue Jul 13 03:21:50 2010
From: hltbra at gmail.com (Hugo Lopes Tavares)
Date: Mon, 12 Jul 2010 22:21:50 -0300
Subject: [Distutils] Distribute and Python 3
Message-ID: <AANLkTinZ5M3m4vCrJq6thb0mEYDkEytO9RPvuWEQxWV3@mail.gmail.com>

I am using distribute and python 3.2a0 while I add py3k support to pip
this GSoC and I got a problem using distribute:

from distutils.sysconfig import _config_vars
ImportError: cannot import name _config_vars

Well, in Python 3 the distutils.sysconfig pops a DeprecationWarning,
because now Python has sysconfig module.
As _config_vars is very specific and 2to3 can't convert it, I suggest
using some kind of try/except in the source code, like:

try:
    from distutils.sysconfig import _config_vars
except ImportError:
    from sysconfig import _CONFIG_VARS as _config_vars


I forked distribute project in bitbucket and added this bugfix, check
it here: http://bitbucket.org/hltbra/distribute/changeset/002cccf004e6
I would like to use distribute with this bugfix asap, so, please,
upload it to PyPI :)

From martin at v.loewis.de  Tue Jul 13 08:37:06 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 13 Jul 2010 08:37:06 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3BC01C.7060100@canterbury.ac.nz>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>	<4C3B9282.9050700@v.loewis.de>	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>	<4C3B95CE.8090606@v.loewis.de>	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>	<4C3B9B89.4090602@v.loewis.de>
	<4C3BC01C.7060100@canterbury.ac.nz>
Message-ID: <4C3C0992.7030002@v.loewis.de>

Am 13.07.2010 03:23, schrieb Greg Ewing:
> Martin v. L?wis wrote:
> 
>>  For backwards compatibility, I'm
>> willing to accept solutions as long as they don't allow users to bypass
>> that checkbox.
> 
> If the user is required to visit a web page to complete
> the registration, could you put the check box on *that*
> page instead?

That might also work; I'd have to check with the lawyer whether there
are any problems with such a change.

Regards,
Martin

From ziade.tarek at gmail.com  Tue Jul 13 09:53:54 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 13 Jul 2010 09:53:54 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <i1gc67$9qs$1@dough.gmane.org>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
	<4C3B9B89.4090602@v.loewis.de>
	<AANLkTimZhSnn2m29lqmyd4V5FjfVE9d5sQSNtD_oXBh9@mail.gmail.com>
	<i1gc67$9qs$1@dough.gmane.org>
Message-ID: <AANLkTilxLNH0jX1fWWYXelBxZ3rqXKPE2vx47H4BMBPb@mail.gmail.com>

On Tue, Jul 13, 2010 at 2:32 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>> 2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
>> ...
>>>> Again, maybe it's flawed, and maybe we should remove it. But you cannot
>>>> break this feature in Python 2.5, 26 etc.. because you find it flawed today.
>>> And it's not the reason that I broke it. Instead, the reason is that the
>>> PSF required me to make the change. I didn't even remember that this
>>> would break distutils. Now that I think about it, I think it's distutils
>>> that needs to get fixed going forward. For backwards compatibility, I'm
>>> willing to accept solutions as long as they don't allow users to bypass
>>> that checkbox.
>>
>> I understand why you did that change, and I understand the reasons.
>> We also agree that Distutils needs to be fixed, and this is being
>> worked out in Distutils2.
>>
>> But I strongly disagree that its better to break existing Python
>> versions to comply with the PSF legal policy. I think this is a
>> mistake, and I think it's acceptable to bypass that policy in
>> distutils. That policy didn't exist back then, so it makes perfectly
>> sense not to have it in Distutils.
>
> The breakage you are talking about here is only for an *extremely rare*
> case: ?a user rund 'setup.py register' without having first created an
> account through the web UI. ?I think Martin is right, and that the fact
> that it used to work was an undocumented misfeature (even a security hole).

It's not extremely rare. You do it just once that is. I've documented
that feature in several
books, as the first step when you do your first package registration.

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

From ziade.tarek at gmail.com  Tue Jul 13 09:56:14 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 13 Jul 2010 09:56:14 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3C0992.7030002@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
	<4C3B9B89.4090602@v.loewis.de> <4C3BC01C.7060100@canterbury.ac.nz>
	<4C3C0992.7030002@v.loewis.de>
Message-ID: <AANLkTimWp5E4jSWZ5ujbh37KzdFkDHiCLhCNOw7Q_bDu@mail.gmail.com>

On Tue, Jul 13, 2010 at 8:37 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Am 13.07.2010 03:23, schrieb Greg Ewing:
>> Martin v. L?wis wrote:
>>
>>> ?For backwards compatibility, I'm
>>> willing to accept solutions as long as they don't allow users to bypass
>>> that checkbox.
>>
>> If the user is required to visit a web page to complete
>> the registration, could you put the check box on *that*
>> page instead?
>
> That might also work; I'd have to check with the lawyer whether there
> are any problems with such a change.

Great !

Can you point me to the discussion that took place, to set up this feature ?

I cannot find it in the archives,

>
> Regards,
> Martin
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From ziade.tarek at gmail.com  Tue Jul 13 09:58:30 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 13 Jul 2010 09:58:30 +0200
Subject: [Distutils] Distribute and Python 3
In-Reply-To: <AANLkTinZ5M3m4vCrJq6thb0mEYDkEytO9RPvuWEQxWV3@mail.gmail.com>
References: <AANLkTinZ5M3m4vCrJq6thb0mEYDkEytO9RPvuWEQxWV3@mail.gmail.com>
Message-ID: <AANLkTinGeLj-Pi6tbFjL0JhQATQzcID3ebNtIzBBSZrs@mail.gmail.com>

On Tue, Jul 13, 2010 at 3:21 AM, Hugo Lopes Tavares <hltbra at gmail.com> wrote:
> I am using distribute and python 3.2a0 while I add py3k support to pip
> this GSoC and I got a problem using distribute:

This is a known issue that will be fixed very soon, by reverting
changes in the 3.2 branch of Python, so that it's back in the same
state than 3.1.x.

Expect this to happen this week,

Regards
Tarek

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

From merwok at netwok.org  Tue Jul 13 10:10:53 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 13 Jul 2010 10:10:53 +0200
Subject: [Distutils] Distribute and Python 3
In-Reply-To: <AANLkTinGeLj-Pi6tbFjL0JhQATQzcID3ebNtIzBBSZrs@mail.gmail.com>
References: <AANLkTinZ5M3m4vCrJq6thb0mEYDkEytO9RPvuWEQxWV3@mail.gmail.com>
	<AANLkTinGeLj-Pi6tbFjL0JhQATQzcID3ebNtIzBBSZrs@mail.gmail.com>
Message-ID: <4C3C1F8D.4000804@netwok.org>

> On Tue, Jul 13, 2010 at 3:21 AM, Hugo Lopes Tavares <hltbra at gmail.com> wrote:
> I am using distribute and python 3.2a0 while I add py3k support to pip
> this GSoC and I got a problem using distribute:

Note that in CPython, 3.2a0 means 3.2-dev, i.e. the development version,
not a release. As such, it should not be generally used. 3.1 is the
stable 3.x release.

Regards


From gary.poster at canonical.com  Tue Jul 13 11:53:55 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Tue, 13 Jul 2010 11:53:55 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTin84m8k4eR5Le84FkRxuRGXx_a_231KbUzhftPr@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
	<AANLkTin84m8k4eR5Le84FkRxuRGXx_a_231KbUzhftPr@mail.gmail.com>
Message-ID: <4D0FC70D-CBCD-4E8D-9ED7-AA4E4A4277B9@canonical.com>


On Jul 13, 2010, at 1:59 AM, Dave Peticolas wrote:

...

> 
> I'm testing out the beta branch

Thank you!

> and running into a problem. I'm running buildout from a virtualenv,
> and when I try to install the 'superlance' package, I get this:
> 
>   The required version of setuptools (>=0.6c9) is not available, and
>   can't be installed while this script is running. Please install
>   a more recent version first, using 'easy_install -U setuptools'.
> 
>   (Currently using setuptools 0.6c8 (/usr/lib/python2.5/site-packages))
>   error: Setup script exited with 2
> 
> This is despite the fact that I have 0.6c11 installed in the virtualenv. This seems to be caused
> by the fact that the buildout bin script has this:
> 
>   import sys
>   sys.path[0:0] = [
>       '/tmp/ve/eggs/zc.buildout-1.5.0b2-py2.5.egg',
>       '/usr/lib/python2.5/site-packages',
>       ]
> 
> And thus picks up the older version of setuptools in /usr/lib/python2.5. I tried removing those lines,
> but buildout seems to be re-creating that file when I run it.
> 
> Any suggestions?

(1) This may be unrelated to your problem, but I have *not* added support for using a virtualenv without --no-site-packages, and AFAIK it was never supported.  It looks like you are not using --no-site-packages in your virtualenv, so I  don't support that.

(2) It looks like you are using an old bootstrap.  In addition to using the code from the svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/ branch (I guess you made your own release?), you also need to make sure you are using the bootstrap if you want to use the new feature without virtualenv.

That said, the old bootstrap should still work with virtualenv + the new release, and if it doesn't that's a reasonable backwards-compatibility bug.  I'll look into that later to see if that's the case.

Gary

From m.van.rees at zestsoftware.nl  Tue Jul 13 13:50:03 2010
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 13 Jul 2010 13:50:03 +0200
Subject: [Distutils] zc.buildout - multiple 'cascading' buildout.cfg
	files
In-Reply-To: <4C3B4088.7030208@franzoni.eu>
References: <4C3B4088.7030208@franzoni.eu>
Message-ID: <i1hjtb$oj0$1@dough.gmane.org>

Op 12-07-10 18:19, Alan Franzoni schreef:
> Hello,
> I'm wondering if there's a way to have something like "local"
> buildout.cfg files overriding a "master" one; e.g.
(...)
> This would be useful because in our projects we usually share one
> per-project buildout.cfg which every team member uses and it's stored on
> our VCS, and it's used all around including along our CI server, and we
> don't want to change it if a real configuration change is unneeded, but
> often I need to tinker with it (e.g. I want to use one additional
> development egg, or change a dep, or run a different recipe).

First, no I don't know a way to do this like you propose.

Second, what me and my colleagues at Zest Software do, is to not have a 
buildout.cfg in our VCS.  Instead we have a devel.cfg for development 
and a production.cfg for the live site (and possibly a preview.cfg) in VCS.

When working on the project on my laptop, I make a symbolic link from 
buildout.cfg to devel.cfg (e.g. 'ln -s devel.cfg buildout.cfg').  If I 
want to make more local changes, then instead of creating a symbolic 
link, I create a buildout.cfg file like this:

[buildout]
extends = devel.cfg

[one]
# changes go here

The buildout.cfg file is ignored by the VCS.

-- 
Maurits van Rees
Programmer, Zest Software


From mailing at franzoni.eu  Tue Jul 13 14:30:44 2010
From: mailing at franzoni.eu (Alan Franzoni)
Date: Tue, 13 Jul 2010 14:30:44 +0200
Subject: [Distutils] zc.buildout - multiple 'cascading' buildout.cfg
	files
In-Reply-To: <i1hjtb$oj0$1@dough.gmane.org>
References: <4C3B4088.7030208@franzoni.eu> <i1hjtb$oj0$1@dough.gmane.org>
Message-ID: <4C3C5C74.9040508@franzoni.eu>

On 7/13/10 1:50 PM, Maurits van Rees wrote:
> [buildout]
> extends = devel.cfg

I had no idea about the "extends" config option in zc.buildout. That'll
work perfectly right for us.

Thank you!


-- 
Alan Franzoni
contact me at public@[mysurname].eu

From shimizukawa at gmail.com  Tue Jul 13 15:35:28 2010
From: shimizukawa at gmail.com (Takayuki Shimizukawa)
Date: Tue, 13 Jul 2010 22:35:28 +0900
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3C0992.7030002@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com> 
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com> 
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com> 
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com> 
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com> 
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com> 
	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com> 
	<4C3B9B89.4090602@v.loewis.de> <4C3BC01C.7060100@canterbury.ac.nz> 
	<4C3C0992.7030002@v.loewis.de>
Message-ID: <AANLkTikyVARfkfFezEvuSA2-1v48h-vJMda9KiRsszjZ@mail.gmail.com>

2010/7/13 "Martin v. L?wis" <martin at v.loewis.de>:
> Am 13.07.2010 03:23, schrieb Greg Ewing:
>> Martin v. L?wis wrote:
>>
>>> ?For backwards compatibility, I'm
>>> willing to accept solutions as long as they don't allow users to bypass
>>> that checkbox.
>>
>> If the user is required to visit a web page to complete
>> the registration, could you put the check box on *that*
>> page instead?
>
> That might also work; I'd have to check with the lawyer whether there
> are any problems with such a change.

It's a good news!

If this problem will be solved by that policy, I come to be able to
teach the developers Distutils according to current documents.

> Regards,
> Martin

Regards,
--
Takayuki SHIMIZUKAWA

From dave at krondo.com  Tue Jul 13 18:52:00 2010
From: dave at krondo.com (Dave Peticolas)
Date: Tue, 13 Jul 2010 09:52:00 -0700
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <4D0FC70D-CBCD-4E8D-9ED7-AA4E4A4277B9@canonical.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
	<AANLkTin84m8k4eR5Le84FkRxuRGXx_a_231KbUzhftPr@mail.gmail.com>
	<4D0FC70D-CBCD-4E8D-9ED7-AA4E4A4277B9@canonical.com>
Message-ID: <AANLkTik1czuqRVffYhV4JKXk9dUD8N0G_A0uacDVTuGC@mail.gmail.com>

On Tue, Jul 13, 2010 at 2:53 AM, Gary Poster <gary.poster at canonical.com>wrote:

>
> On Jul 13, 2010, at 1:59 AM, Dave Peticolas wrote:
>
> ...
>
> >
> > I'm testing out the beta branch
>
> Thank you!
>
> > and running into a problem. I'm running buildout from a virtualenv,
> > and when I try to install the 'superlance' package, I get this:
> >
> >   The required version of setuptools (>=0.6c9) is not available, and
> >   can't be installed while this script is running. Please install
> >   a more recent version first, using 'easy_install -U setuptools'.
> >
> >   (Currently using setuptools 0.6c8 (/usr/lib/python2.5/site-packages))
> >   error: Setup script exited with 2
> >
> > This is despite the fact that I have 0.6c11 installed in the virtualenv.
> This seems to be caused
> > by the fact that the buildout bin script has this:
> >
> >   import sys
> >   sys.path[0:0] = [
> >       '/tmp/ve/eggs/zc.buildout-1.5.0b2-py2.5.egg',
> >       '/usr/lib/python2.5/site-packages',
> >       ]
> >
> > And thus picks up the older version of setuptools in /usr/lib/python2.5.
> I tried removing those lines,
> > but buildout seems to be re-creating that file when I run it.
> >
> > Any suggestions?
>
> (1) This may be unrelated to your problem, but I have *not* added support
> for using a virtualenv without --no-site-packages, and AFAIK it was never
> supported.  It looks like you are not using --no-site-packages in your
> virtualenv, so I  don't support that.
>

Gotcha. And adding --no-site-packages does seem to have cleared up my
problem. Thank you!



> (2) It looks like you are using an old bootstrap.  In addition to using the
> code from the svn+ssh://
> svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/ branch (I guess
> you made your own release?), you also need to make sure you are using the
> bootstrap if you want to use the new feature without virtualenv.
>

I pretty much always use buildout in a virtualenv. In my test, I'm creating
the virtualenv, and then using easy_install to install buildout from a
checkout
of your branch. Is there a better way to run the test?



> That said, the old bootstrap should still work with virtualenv + the new
> release, and if it doesn't that's a reasonable backwards-compatibility bug.
>  I'll look into that later to see if that's the case.
>
> Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100713/deb3b4ed/attachment.html>

From setuptools at bugs.python.org  Tue Jul 13 21:06:55 2010
From: setuptools at bugs.python.org (Erik Hahn)
Date: Tue, 13 Jul 2010 19:06:55 +0000
Subject: [Distutils] [issue111] Windows: easy_install tries to download X11
	PyQT
In-Reply-To: <1279048015.81.0.739964873207.issue111@psf.upfronthosting.co.za>
Message-ID: <1279048015.81.0.739964873207.issue111@psf.upfronthosting.co.za>


New submission from Erik Hahn <erik_hahn at gmx.de>:

On Windows, easy_install tries to install the X11 version of PyQT:

D:\code>c:\Python26\Scripts\easy_install.exe pyqt
install_dir C:\Python26\Lib\site-packages\
Searching for pyqt
Reading http://pypi.python.org/simple/pyqt/
Reading http://www.riverbankcomputing.com/software/pyqt/
Reading http://www.riverbankcomputing.com/software/pyqt/download
Best match: PyQt x11-gpl-4.7.4
Downloading http://www.riverbankcomputing.com/static/Downloads/PyQt4/PyQt-x11-gp
l-4.7.4.tar.gz
Processing PyQt-x11-gpl-4.7.4.tar.gz
error: Couldn't find a setup script in c:\dokume~1\erik\lokale~1\temp\easy_insta
ll-qycl5v\PyQt-x11-gpl-4.7.4.tar.gz

----------
messages: 526
nosy: erik_hahn
priority: bug
status: unread
title: Windows: easy_install tries to download X11 PyQT

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue111>
_______________________________________________

From martin at v.loewis.de  Tue Jul 13 22:36:01 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Jul 2010 22:36:01 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTimWp5E4jSWZ5ujbh37KzdFkDHiCLhCNOw7Q_bDu@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>	<4C3B9282.9050700@v.loewis.de>	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>	<4C3B95CE.8090606@v.loewis.de>	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>	<4C3B9B89.4090602@v.loewis.de>	<4C3BC01C.7060100@canterbury.ac.nz>	<4C3C0992.7030002@v.loewis.de>
	<AANLkTimWp5E4jSWZ5ujbh37KzdFkDHiCLhCNOw7Q_bDu@mail.gmail.com>
Message-ID: <4C3CCE31.60206@v.loewis.de>

> Can you point me to the discussion that took place, to set up this feature ?

No; I don't think there are any public archives of that discussion. Nor
was it really a discussion. Marc-Andre Lemburg voiced a concern, I asked
the lawyer, the lawyer told me what to do.

Regards,
Martin


From martin at v.loewis.de  Tue Jul 13 22:39:30 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 13 Jul 2010 22:39:30 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTikyVARfkfFezEvuSA2-1v48h-vJMda9KiRsszjZ@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
	<4C3B9B89.4090602@v.loewis.de> <4C3BC01C.7060100@canterbury.ac.nz>
	<4C3C0992.7030002@v.loewis.de>
	<AANLkTikyVARfkfFezEvuSA2-1v48h-vJMda9KiRsszjZ@mail.gmail.com>
Message-ID: <4C3CCF02.3070703@v.loewis.de>

>> That might also work; I'd have to check with the lawyer whether there
>> are any problems with such a change.
> 
> It's a good news!
> 
> If this problem will be solved by that policy, I come to be able to
> teach the developers Distutils according to current documents.

Please teach them to use a web browser to register instead.

Regards,
Martin

From pje at telecommunity.com  Wed Jul 14 00:04:24 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 13 Jul 2010 18:04:24 -0400
Subject: [Distutils] [issue111] Windows: easy_install tries to download
 X11 PyQT
In-Reply-To: <1279048015.81.0.739964873207.issue111@psf.upfronthosting.c o.za>
References: <1279048015.81.0.739964873207.issue111@psf.upfronthosting.co.za>
	<1279048015.81.0.739964873207.issue111@psf.upfronthosting.co.za>
Message-ID: <20100713220424.822853A404D@sparrow.telecommunity.com>

FYI, PyQT can't be easy_installed, period, because it's not a 
distutils-based package.  Even if you downloaded the correct version 
(either manually or by giving the exact URL to easy_install), it 
still wouldn't work, and there's nothing that can be done about it on 
the easy_install side.  Sorry.

At 07:06 PM 7/13/2010 +0000, Erik Hahn wrote:
>On Windows, easy_install tries to install the X11 version of PyQT:
>
>D:\code>c:\Python26\Scripts\easy_install.exe pyqt
>install_dir C:\Python26\Lib\site-packages\
>Searching for pyqt
>Reading http://pypi.python.org/simple/pyqt/
>Reading http://www.riverbankcomputing.com/software/pyqt/
>Reading http://www.riverbankcomputing.com/software/pyqt/download
>Best match: PyQt x11-gpl-4.7.4
>Downloading 
>http://www.riverbankcomputing.com/static/Downloads/PyQt4/PyQt-x11-gp
>l-4.7.4.tar.gz
>Processing PyQt-x11-gpl-4.7.4.tar.gz
>error: Couldn't find a setup script in 
>c:\dokume~1\erik\lokale~1\temp\easy_insta
>ll-qycl5v\PyQt-x11-gpl-4.7.4.tar.gz


From fuzzyman at voidspace.org.uk  Wed Jul 14 00:56:26 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 13 Jul 2010 23:56:26 +0100
Subject: [Distutils] Installing distribute with Python 3.0 / 3.1
Message-ID: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>

I get the following error attempting to install distribute 0.6.13 with
Python 3.0 / 3.1:

python3.0 setup.py install
creating build
creating build/src
creating build/src/docs
creating build/src/docs/_templates
creating build/src/docs/_theme
creating build/src/docs/_theme/nature
creating build/src/docs/_theme/nature/static
creating build/src/setuptools
creating build/src/setuptools/command
creating build/src/setuptools/tests
creating build/src/tests
creating build/src/tests/shlib_test
copying setuptools/__init__.py -> build/src/setuptools
copying setuptools/archive_util.py -> build/src/setuptools
copying setuptools/depends.py -> build/src/setuptools
copying setuptools/dist.py -> build/src/setuptools
copying setuptools/extension.py -> build/src/setuptools
copying setuptools/package_index.py -> build/src/setuptools
copying setuptools/sandbox.py -> build/src/setuptools
copying setuptools/tests/__init__.py -> build/src/setuptools/tests
copying setuptools/tests/doctest.py -> build/src/setuptools/tests
copying setuptools/tests/server.py -> build/src/setuptools/tests
copying setuptools/tests/test_build_ext.py -> build/src/setuptools/tests
copying setuptools/tests/test_develop.py -> build/src/setuptools/tests
copying setuptools/tests/test_easy_install.py -> build/src/setuptools/tests
copying setuptools/tests/test_packageindex.py -> build/src/setuptools/tests
copying setuptools/tests/test_resources.py -> build/src/setuptools/tests
copying setuptools/tests/test_sandbox.py -> build/src/setuptools/tests
copying setuptools/tests/test_upload_docs.py -> build/src/setuptools/tests
copying setuptools/command/__init__.py -> build/src/setuptools/command
copying setuptools/command/alias.py -> build/src/setuptools/command
copying setuptools/command/bdist_egg.py -> build/src/setuptools/command
copying setuptools/command/bdist_rpm.py -> build/src/setuptools/command
copying setuptools/command/bdist_wininst.py -> build/src/setuptools/command
copying setuptools/command/build_ext.py -> build/src/setuptools/command
copying setuptools/command/build_py.py -> build/src/setuptools/command
copying setuptools/command/develop.py -> build/src/setuptools/command
copying setuptools/command/easy_install.py -> build/src/setuptools/command
copying setuptools/command/easy_install2.py -> build/src/setuptools/command
copying setuptools/command/egg_info.py -> build/src/setuptools/command
copying setuptools/command/install.py -> build/src/setuptools/command
copying setuptools/command/install_egg_info.py -> build/src/setuptools/command
copying setuptools/command/install_lib.py -> build/src/setuptools/command
copying setuptools/command/install_scripts.py -> build/src/setuptools/command
copying setuptools/command/register.py -> build/src/setuptools/command
copying setuptools/command/rotate.py -> build/src/setuptools/command
copying setuptools/command/saveopts.py -> build/src/setuptools/command
copying setuptools/command/sdist.py -> build/src/setuptools/command
copying setuptools/command/setopt.py -> build/src/setuptools/command
copying setuptools/command/test.py -> build/src/setuptools/command
copying setuptools/command/upload.py -> build/src/setuptools/command
copying setuptools/command/upload_docs.py -> build/src/setuptools/command
copying setuptools/tests/win_script_wrapper.txt -> build/src/setuptools/tests
copying setuptools/cli.exe -> build/src/setuptools
copying setuptools/gui.exe -> build/src/setuptools
copying tests/install_test.py -> build/src/tests
copying tests/manual_test.py -> build/src/tests
copying tests/test_distribute_setup.py -> build/src/tests
copying tests/shlib_test/setup.py -> build/src/tests/shlib_test
copying tests/shlib_test/test_hello.py -> build/src/tests/shlib_test
copying tests/shlib_test/hello.c -> build/src/tests/shlib_test
copying tests/shlib_test/hellolib.c -> build/src/tests/shlib_test
copying tests/shlib_test/hello.pyx -> build/src/tests/shlib_test
copying tests/api_tests.txt -> build/src/tests
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- build/src/tests/api_tests.txt (original)
+++ build/src/tests/api_tests.txt (refactored)
@@ -39,7 +39,7 @@
     >>> dist.py_version == sys.version[:3]
     True

-    >>> print dist.platform
+    >>> print(dist.platform)
     None

 Including various computed attributes::
@@ -199,7 +199,7 @@
 You can ask a WorkingSet to ``find()`` a distribution matching a requirement::

     >>> from pkg_resources import Requirement
-    >>> print ws.find(Requirement.parse("Foo==1.0"))    # no match, return None
+    >>> print(ws.find(Requirement.parse("Foo==1.0")))    # no match,
return None
     None

     >>> ws.find(Requirement.parse("Bar==0.9"))  # match, return distribution
@@ -211,7 +211,7 @@
     >>> try:
     ...     ws.find(Requirement.parse("Bar==1.0"))
     ... except VersionConflict:
-    ...     print 'ok'
+    ...     print('ok')
     ok

 You can subscribe a callback function to receive notifications whenever a new
@@ -219,7 +219,7 @@
 once for each existing distribution in the working set, and then is called
 again for new distributions added thereafter::

-    >>> def added(dist): print "Added", dist
+    >>> def added(dist): print("Added", dist)
     >>> ws.subscribe(added)
     Added Bar 0.9
     >>> foo12 = Distribution(project_name="Foo", version="1.2",
location="f12")
RefactoringTool: Files that were modified:
RefactoringTool: build/src/tests/api_tests.txt
copying docs/conf.py -> build/src/docs
copying docs/easy_install.txt -> build/src/docs
copying docs/index.txt -> build/src/docs
copying docs/pkg_resources.txt -> build/src/docs
copying docs/python3.txt -> build/src/docs
copying docs/roadmap.txt -> build/src/docs
copying docs/setuptools.txt -> build/src/docs
copying docs/using.txt -> build/src/docs
copying docs/_theme/nature/theme.conf -> build/src/docs/_theme/nature
copying docs/_theme/nature/static/pygments.css ->
build/src/docs/_theme/nature/static
copying docs/_theme/nature/static/nature.css_t ->
build/src/docs/_theme/nature/static
copying docs/Makefile -> build/src/docs
copying docs/_templates/indexsidebar.html -> build/src/docs/_templates
copying distribute_setup.py -> build/src
copying easy_install.py -> build/src
copying pkg_resources.py -> build/src
copying setup.py -> build/src
copying site.py -> build/src
copying CHANGES.txt -> build/src
copying CONTRIBUTORS.txt -> build/src
copying DEVGUIDE.txt -> build/src
copying pip-log.txt -> build/src
copying README.txt -> build/src
copying MANIFEST.in -> build/src
copying launcher.c -> build/src
Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer: ws_comma
Before install bootstrap.
Scanning installed packages
No setuptools distribution found
running install
Traceback (most recent call last):
  File "setup.py", line 211, in <module>
    scripts = scripts,
  File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/core.py",
line 149, in setup
    dist.run_commands()
  File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py",
line 942, in run_commands
    self.run_command(cmd)
  File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py",
line 962, in run_command
    cmd_obj.run()
  File "build/src/setuptools/command/install.py", line 73, in run
    self.do_egg_install()
  File "build/src/setuptools/command/install.py", line 82, in do_egg_install
    easy_install = self.distribution.get_command_class('easy_install')
  File "build/src/setuptools/dist.py", line 361, in get_command_class
    self.cmdclass[command] = cmdclass = ep.load()
  File "build/src/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build/src/setuptools/command/easy_install.py", line 16, in <module>
    from setuptools.sandbox import run_setup
  File "build/src/setuptools/sandbox.py", line 232, in <module>
    WRITE_FLAGS = reduce(
NameError: name 'reduce' is not defined
bigmac:distribute-0.6.13 michael$ python3.1 setup.py install
Before install bootstrap.
Scanning installed packages
No setuptools distribution found
running install
Traceback (most recent call last):
  File "setup.py", line 211, in <module>
    scripts = scripts,
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/core.py",
line 149, in setup
    dist.run_commands()
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py",
line 919, in run_commands
    self.run_command(cmd)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py",
line 938, in run_command
    cmd_obj.run()
  File "build/src/setuptools/command/install.py", line 73, in run
    self.do_egg_install()
  File "build/src/setuptools/command/install.py", line 82, in do_egg_install
    easy_install = self.distribution.get_command_class('easy_install')
  File "build/src/setuptools/dist.py", line 361, in get_command_class
    self.cmdclass[command] = cmdclass = ep.load()
  File "build/src/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build/src/setuptools/command/easy_install.py", line 16, in <module>
    from setuptools.sandbox import run_setup
  File "build/src/setuptools/sandbox.py", line 232, in <module>
    WRITE_FLAGS = reduce(
NameError: name 'reduce' is not defined



-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100713/b171fd12/attachment-0001.html>

From fuzzyman at gmail.com  Wed Jul 14 01:12:28 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Wed, 14 Jul 2010 00:12:28 +0100
Subject: [Distutils] Installing distribute with Python 3.0 / 3.1
Message-ID: <AANLkTikKA7etqQTQ8MqPMRcB4ZG7L9AmIPq6cIj2NY_D@mail.gmail.com>

I get the following error attempting to install distribute 0.6.13 with
Python 3.0 / 3.1:

python3.0 setup.py install
creating build
creating build/src
creating build/src/docs
creating build/src/docs/_templates

creating build/src/docs/_theme
creating build/src/docs/_theme/nature
creating build/src/docs/_theme/nature/static
creating build/src/setuptools
creating build/src/setuptools/command
creating build/src/setuptools/tests

creating build/src/tests
creating build/src/tests/shlib_test
copying setuptools/__init__.py -> build/src/setuptools
copying setuptools/archive_util.py -> build/src/setuptools
copying setuptools/depends.py -> build/src/setuptools

copying setuptools/dist.py -> build/src/setuptools
copying setuptools/extension.py -> build/src/setuptools
copying setuptools/package_index.py -> build/src/setuptools
copying setuptools/sandbox.py -> build/src/setuptools

copying setuptools/tests/__init__.py -> build/src/setuptools/tests
copying setuptools/tests/doctest.py -> build/src/setuptools/tests
copying setuptools/tests/server.py -> build/src/setuptools/tests
copying setuptools/tests/test_build_ext.py -> build/src/setuptools/tests

copying setuptools/tests/test_develop.py -> build/src/setuptools/tests
copying setuptools/tests/test_easy_install.py -> build/src/setuptools/tests
copying setuptools/tests/test_packageindex.py -> build/src/setuptools/tests

copying setuptools/tests/test_resources.py -> build/src/setuptools/tests
copying setuptools/tests/test_sandbox.py -> build/src/setuptools/tests
copying setuptools/tests/test_upload_docs.py -> build/src/setuptools/tests

copying setuptools/command/__init__.py -> build/src/setuptools/command
copying setuptools/command/alias.py -> build/src/setuptools/command
copying setuptools/command/bdist_egg.py -> build/src/setuptools/command

copying setuptools/command/bdist_rpm.py -> build/src/setuptools/command
copying setuptools/command/bdist_wininst.py -> build/src/setuptools/command
copying setuptools/command/build_ext.py -> build/src/setuptools/command

copying setuptools/command/build_py.py -> build/src/setuptools/command
copying setuptools/command/develop.py -> build/src/setuptools/command
copying setuptools/command/easy_install.py -> build/src/setuptools/command

copying setuptools/command/easy_install2.py -> build/src/setuptools/command
copying setuptools/command/egg_info.py -> build/src/setuptools/command
copying setuptools/command/install.py -> build/src/setuptools/command

copying setuptools/command/install_egg_info.py -> build/src/setuptools/command
copying setuptools/command/install_lib.py -> build/src/setuptools/command
copying setuptools/command/install_scripts.py -> build/src/setuptools/command

copying setuptools/command/register.py -> build/src/setuptools/command
copying setuptools/command/rotate.py -> build/src/setuptools/command
copying setuptools/command/saveopts.py -> build/src/setuptools/command

copying setuptools/command/sdist.py -> build/src/setuptools/command
copying setuptools/command/setopt.py -> build/src/setuptools/command
copying setuptools/command/test.py -> build/src/setuptools/command

copying setuptools/command/upload.py -> build/src/setuptools/command
copying setuptools/command/upload_docs.py -> build/src/setuptools/command
copying setuptools/tests/win_script_wrapper.txt -> build/src/setuptools/tests

copying setuptools/cli.exe -> build/src/setuptools
copying setuptools/gui.exe -> build/src/setuptools
copying tests/install_test.py -> build/src/tests
copying tests/manual_test.py -> build/src/tests

copying tests/test_distribute_setup.py -> build/src/tests
copying tests/shlib_test/setup.py -> build/src/tests/shlib_test
copying tests/shlib_test/test_hello.py -> build/src/tests/shlib_test
copying tests/shlib_test/hello.c -> build/src/tests/shlib_test

copying tests/shlib_test/hellolib.c -> build/src/tests/shlib_test
copying tests/shlib_test/hello.pyx -> build/src/tests/shlib_test
copying tests/api_tests.txt -> build/src/tests
RefactoringTool: Skipping implicit fixer: buffer

RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- build/src/tests/api_tests.txt (original)
+++ build/src/tests/api_tests.txt (refactored)

@@ -39,7 +39,7 @@
     >>> dist.py_version == sys.version[:3]
     True

-    >>> print dist.platform
+    >>> print(dist.platform)
     None

 Including various computed attributes::

@@ -199,7 +199,7 @@
 You can ask a WorkingSet to ``find()`` a distribution matching a requirement::

     >>> from pkg_resources import Requirement
-    >>> print ws.find(Requirement.parse("Foo==1.0"))    # no match, return None

+    >>> print(ws.find(Requirement.parse("Foo==1.0")))    # no match,
return None
     None

     >>> ws.find(Requirement.parse("Bar==0.9"))  # match, return distribution

@@ -211,7 +211,7 @@
     >>> try:
     ...     ws.find(Requirement.parse("Bar==1.0"))
     ... except VersionConflict:
-    ...     print 'ok'
+    ...     print('ok')

     ok

 You can subscribe a callback function to receive notifications whenever a new
@@ -219,7 +219,7 @@
 once for each existing distribution in the working set, and then is called
 again for new distributions added thereafter::


-    >>> def added(dist): print "Added", dist
+    >>> def added(dist): print("Added", dist)
     >>> ws.subscribe(added)
     Added Bar 0.9
     >>> foo12 = Distribution(project_name="Foo", version="1.2",
location="f12")

RefactoringTool: Files that were modified:
RefactoringTool: build/src/tests/api_tests.txt
copying docs/conf.py -> build/src/docs
copying docs/easy_install.txt -> build/src/docs
copying docs/index.txt -> build/src/docs

copying docs/pkg_resources.txt -> build/src/docs
copying docs/python3.txt -> build/src/docs
copying docs/roadmap.txt -> build/src/docs
copying docs/setuptools.txt -> build/src/docs
copying docs/using.txt -> build/src/docs

copying docs/_theme/nature/theme.conf -> build/src/docs/_theme/nature
copying docs/_theme/nature/static/pygments.css ->
build/src/docs/_theme/nature/static
copying docs/_theme/nature/static/nature.css_t ->
build/src/docs/_theme/nature/static

copying docs/Makefile -> build/src/docs
copying docs/_templates/indexsidebar.html -> build/src/docs/_templates
copying distribute_setup.py -> build/src
copying easy_install.py -> build/src
copying pkg_resources.py -> build/src

copying setup.py -> build/src
copying site.py -> build/src
copying CHANGES.txt -> build/src
copying CONTRIBUTORS.txt -> build/src
copying DEVGUIDE.txt -> build/src
copying pip-log.txt -> build/src

copying README.txt -> build/src
copying MANIFEST.in -> build/src
copying launcher.c -> build/src
Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal

Skipping implicit fixer: ws_comma
Before install bootstrap.
Scanning installed packages
No setuptools distribution found
running install
Traceback (most recent call last):
  File "setup.py", line 211, in <module>

    scripts = scripts,
  File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/core.py",
line 149, in setup
    dist.run_commands()
  File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py",
line 942, in run_commands

    self.run_command(cmd)
  File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py",
line 962, in run_command
    cmd_obj.run()
  File "build/src/setuptools/command/install.py", line 73, in run

    self.do_egg_install()
  File "build/src/setuptools/command/install.py", line 82, in do_egg_install
    easy_install = self.distribution.get_command_class('easy_install')
  File "build/src/setuptools/dist.py", line 361, in get_command_class

    self.cmdclass[command] = cmdclass = ep.load()
  File "build/src/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build/src/setuptools/command/easy_install.py", line 16, in <module>

    from setuptools.sandbox import run_setup
  File "build/src/setuptools/sandbox.py", line 232, in <module>
    WRITE_FLAGS = reduce(
NameError: name 'reduce' is not defined
bigmac:distribute-0.6.13 michael$ python3.1 setup.py install

Before install bootstrap.
Scanning installed packages
No setuptools distribution found
running install
Traceback (most recent call last):
  File "setup.py", line 211, in <module>
    scripts = scripts,

  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/core.py",
line 149, in setup
    dist.run_commands()
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py",
line 919, in run_commands

    self.run_command(cmd)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py",
line 938, in run_command
    cmd_obj.run()
  File "build/src/setuptools/command/install.py", line 73, in run

    self.do_egg_install()
  File "build/src/setuptools/command/install.py", line 82, in do_egg_install
    easy_install = self.distribution.get_command_class('easy_install')
  File "build/src/setuptools/dist.py", line 361, in get_command_class

    self.cmdclass[command] = cmdclass = ep.load()
  File "build/src/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build/src/setuptools/command/easy_install.py", line 16, in <module>

    from setuptools.sandbox import run_setup
  File "build/src/setuptools/sandbox.py", line 232, in <module>
    WRITE_FLAGS = reduce(
NameError: name 'reduce' is not defined



-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100714/74cfeafa/attachment.html>

From ziade.tarek at gmail.com  Wed Jul 14 01:38:36 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 14 Jul 2010 01:38:36 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3CCF02.3070703@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>
	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>
	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>
	<4C3B87B0.4010905@v.loewis.de>
	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>
	<4C3B9282.9050700@v.loewis.de>
	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>
	<4C3B95CE.8090606@v.loewis.de>
	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>
	<4C3B9B89.4090602@v.loewis.de> <4C3BC01C.7060100@canterbury.ac.nz>
	<4C3C0992.7030002@v.loewis.de>
	<AANLkTikyVARfkfFezEvuSA2-1v48h-vJMda9KiRsszjZ@mail.gmail.com>
	<4C3CCF02.3070703@v.loewis.de>
Message-ID: <AANLkTinhH0pYylCEAUOroajeRBkxG7v8EyoB0rb3rQD1@mail.gmail.com>

On Tue, Jul 13, 2010 at 10:39 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> That might also work; I'd have to check with the lawyer whether there
>>> are any problems with such a change.
>>
>> It's a good news!
>>
>> If this problem will be solved by that policy, I come to be able to
>> teach the developers Distutils according to current documents.
>
> Please teach them to use a web browser to register instead.

No. If the fix Greg proposed is accepted by The PSF, this feature will
work again and you will be able to use it again. It worked perfectly
fine before the change.

Martin, if you want to remove some feature from Distutils, make a proposal.

But you can't decide on your own that a feature in a project
maintained by a bunch of other people, has to go.


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

From hltbra at gmail.com  Wed Jul 14 02:52:33 2010
From: hltbra at gmail.com (Hugo Lopes Tavares)
Date: Tue, 13 Jul 2010 21:52:33 -0300
Subject: [Distutils] Installing distribute with Python 3.0 / 3.1
In-Reply-To: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>
References: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>
Message-ID: <AANLkTinBCkQ_it8fm43AiQTVkg4NGfvzoLZkFjVX_dJq@mail.gmail.com>

It is really weird because I am using Python3.1 and easy_installed
distribute-0.6.13 right now.
The difference I can tell you is that I had setuptools installation:
Setuptools installation detected at /home/hugo/.../site-packages

On Tue, Jul 13, 2010 at 7:56 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> I get the following error attempting to install distribute 0.6.13 with
> Python 3.0 / 3.1:
>
> python3.0 setup.py install
> creating build
> creating build/src
> creating build/src/docs
> creating build/src/docs/_templates
>
> creating build/src/docs/_theme
> creating build/src/docs/_theme/nature
> creating build/src/docs/_theme/nature/static
> creating build/src/setuptools
> creating build/src/setuptools/command
> creating build/src/setuptools/tests
>
> creating build/src/tests
> creating build/src/tests/shlib_test
> copying setuptools/__init__.py -> build/src/setuptools
> copying setuptools/archive_util.py -> build/src/setuptools
> copying setuptools/depends.py -> build/src/setuptools
>
> copying setuptools/dist.py -> build/src/setuptools
> copying setuptools/extension.py -> build/src/setuptools
> copying setuptools/package_index.py -> build/src/setuptools
> copying setuptools/sandbox.py -> build/src/setuptools
>
> copying setuptools/tests/__init__.py -> build/src/setuptools/tests
> copying setuptools/tests/doctest.py -> build/src/setuptools/tests
> copying setuptools/tests/server.py -> build/src/setuptools/tests
> copying setuptools/tests/test_build_ext.py -> build/src/setuptools/tests
>
> copying setuptools/tests/test_develop.py -> build/src/setuptools/tests
> copying setuptools/tests/test_easy_install.py -> build/src/setuptools/tests
> copying setuptools/tests/test_packageindex.py -> build/src/setuptools/tests
>
> copying setuptools/tests/test_resources.py -> build/src/setuptools/tests
> copying setuptools/tests/test_sandbox.py -> build/src/setuptools/tests
> copying setuptools/tests/test_upload_docs.py -> build/src/setuptools/tests
>
> copying setuptools/command/__init__.py -> build/src/setuptools/command
> copying setuptools/command/alias.py -> build/src/setuptools/command
> copying setuptools/command/bdist_egg.py -> build/src/setuptools/command
>
> copying setuptools/command/bdist_rpm.py -> build/src/setuptools/command
> copying setuptools/command/bdist_wininst.py -> build/src/setuptools/command
> copying setuptools/command/build_ext.py -> build/src/setuptools/command
>
> copying setuptools/command/build_py.py -> build/src/setuptools/command
> copying setuptools/command/develop.py -> build/src/setuptools/command
> copying setuptools/command/easy_install.py -> build/src/setuptools/command
>
> copying setuptools/command/easy_install2.py -> build/src/setuptools/command
> copying setuptools/command/egg_info.py -> build/src/setuptools/command
> copying setuptools/command/install.py -> build/src/setuptools/command
>
> copying setuptools/command/install_egg_info.py ->
> build/src/setuptools/command
> copying setuptools/command/install_lib.py -> build/src/setuptools/command
> copying setuptools/command/install_scripts.py ->
> build/src/setuptools/command
>
> copying setuptools/command/register.py -> build/src/setuptools/command
> copying setuptools/command/rotate.py -> build/src/setuptools/command
> copying setuptools/command/saveopts.py -> build/src/setuptools/command
>
> copying setuptools/command/sdist.py -> build/src/setuptools/command
> copying setuptools/command/setopt.py -> build/src/setuptools/command
> copying setuptools/command/test.py -> build/src/setuptools/command
>
> copying setuptools/command/upload.py -> build/src/setuptools/command
> copying setuptools/command/upload_docs.py -> build/src/setuptools/command
> copying setuptools/tests/win_script_wrapper.txt ->
> build/src/setuptools/tests
>
> copying setuptools/cli.exe -> build/src/setuptools
> copying setuptools/gui.exe -> build/src/setuptools
> copying tests/install_test.py -> build/src/tests
> copying tests/manual_test.py -> build/src/tests
>
> copying tests/test_distribute_setup.py -> build/src/tests
> copying tests/shlib_test/setup.py -> build/src/tests/shlib_test
> copying tests/shlib_test/test_hello.py -> build/src/tests/shlib_test
> copying tests/shlib_test/hello.c -> build/src/tests/shlib_test
>
> copying tests/shlib_test/hellolib.c -> build/src/tests/shlib_test
> copying tests/shlib_test/hello.pyx -> build/src/tests/shlib_test
> copying tests/api_tests.txt -> build/src/tests
> RefactoringTool: Skipping implicit fixer: buffer
>
> RefactoringTool: Skipping implicit fixer: idioms
> RefactoringTool: Skipping implicit fixer: set_literal
> RefactoringTool: Skipping implicit fixer: ws_comma
> --- build/src/tests/api_tests.txt (original)
> +++ build/src/tests/api_tests.txt (refactored)
>
> @@ -39,7 +39,7 @@
>      >>> dist.py_version == sys.version[:3]
>      True
>
> -    >>> print dist.platform
> +    >>> print(dist.platform)
>      None
>
>  Including various computed attributes::
>
> @@ -199,7 +199,7 @@
>  You can ask a WorkingSet to ``find()`` a distribution matching a
> requirement::
>
>      >>> from pkg_resources import Requirement
> -    >>> print ws.find(Requirement.parse("Foo==1.0"))    # no match, return
> None
>
> +    >>> print(ws.find(Requirement.parse("Foo==1.0")))    # no match, return
> None
>      None
>
>      >>> ws.find(Requirement.parse("Bar==0.9"))  # match, return
> distribution
>
> @@ -211,7 +211,7 @@
>      >>> try:
>      ...     ws.find(Requirement.parse("Bar==1.0"))
>      ... except VersionConflict:
> -    ...     print 'ok'
> +    ...     print('ok')
>
>      ok
>
>  You can subscribe a callback function to receive notifications whenever a
> new
> @@ -219,7 +219,7 @@
>  once for each existing distribution in the working set, and then is called
>  again for new distributions added thereafter::
>
>
> -    >>> def added(dist): print "Added", dist
> +    >>> def added(dist): print("Added", dist)
>      >>> ws.subscribe(added)
>      Added Bar 0.9
>      >>> foo12 = Distribution(project_name="Foo", version="1.2",
> location="f12")
>
> RefactoringTool: Files that were modified:
> RefactoringTool: build/src/tests/api_tests.txt
> copying docs/conf.py -> build/src/docs
> copying docs/easy_install.txt -> build/src/docs
> copying docs/index.txt -> build/src/docs
>
> copying docs/pkg_resources.txt -> build/src/docs
> copying docs/python3.txt -> build/src/docs
> copying docs/roadmap.txt -> build/src/docs
> copying docs/setuptools.txt -> build/src/docs
> copying docs/using.txt -> build/src/docs
>
> copying docs/_theme/nature/theme.conf -> build/src/docs/_theme/nature
> copying docs/_theme/nature/static/pygments.css ->
> build/src/docs/_theme/nature/static
> copying docs/_theme/nature/static/nature.css_t ->
> build/src/docs/_theme/nature/static
>
> copying docs/Makefile -> build/src/docs
> copying docs/_templates/indexsidebar.html -> build/src/docs/_templates
> copying distribute_setup.py -> build/src
> copying easy_install.py -> build/src
> copying pkg_resources.py -> build/src
>
> copying setup.py -> build/src
> copying site.py -> build/src
> copying CHANGES.txt -> build/src
> copying CONTRIBUTORS.txt -> build/src
> copying DEVGUIDE.txt -> build/src
> copying pip-log.txt -> build/src
>
> copying README.txt -> build/src
> copying MANIFEST.in -> build/src
> copying launcher.c -> build/src
> Skipping implicit fixer: buffer
> Skipping implicit fixer: idioms
> Skipping implicit fixer: set_literal
>
> Skipping implicit fixer: ws_comma
> Before install bootstrap.
> Scanning installed packages
> No setuptools distribution found
> running install
> Traceback (most recent call last):
>   File "setup.py", line 211, in <module>
>
>     scripts = scripts,
>   File
> "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/core.py",
> line 149, in setup
>     dist.run_commands()
>   File
> "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py",
> line 942, in run_commands
>
>     self.run_command(cmd)
>   File
> "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py",
> line 962, in run_command
>     cmd_obj.run()
>   File "build/src/setuptools/command/install.py", line 73, in run
>
>     self.do_egg_install()
>   File "build/src/setuptools/command/install.py", line 82, in do_egg_install
>     easy_install = self.distribution.get_command_class('easy_install')
>   File "build/src/setuptools/dist.py", line 361, in get_command_class
>
>     self.cmdclass[command] = cmdclass = ep.load()
>   File "build/src/pkg_resources.py", line 1954, in load
>     entry = __import__(self.module_name, globals(),globals(), ['__name__'])
>   File "build/src/setuptools/command/easy_install.py", line 16, in <module>
>
>     from setuptools.sandbox import run_setup
>   File "build/src/setuptools/sandbox.py", line 232, in <module>
>     WRITE_FLAGS = reduce(
> NameError: name 'reduce' is not defined
> bigmac:distribute-0.6.13 michael$ python3.1 setup.py install
>
> Before install bootstrap.
> Scanning installed packages
> No setuptools distribution found
> running install
> Traceback (most recent call last):
>   File "setup.py", line 211, in <module>
>     scripts = scripts,
>
>   File
> "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/core.py",
> line 149, in setup
>     dist.run_commands()
>   File
> "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py",
> line 919, in run_commands
>
>     self.run_command(cmd)
>   File
> "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py",
> line 938, in run_command
>     cmd_obj.run()
>   File "build/src/setuptools/command/install.py", line 73, in run
>
>     self.do_egg_install()
>   File "build/src/setuptools/command/install.py", line 82, in do_egg_install
>     easy_install = self.distribution.get_command_class('easy_install')
>   File "build/src/setuptools/dist.py", line 361, in get_command_class
>
>     self.cmdclass[command] = cmdclass = ep.load()
>   File "build/src/pkg_resources.py", line 1954, in load
>     entry = __import__(self.module_name, globals(),globals(), ['__name__'])
>   File "build/src/setuptools/command/easy_install.py", line 16, in <module>
>
>     from setuptools.sandbox import run_setup
>   File "build/src/setuptools/sandbox.py", line 232, in <module>
>     WRITE_FLAGS = reduce(
> NameError: name 'reduce' is not defined
>
>
> --
> http://www.voidspace.org.uk
>
>
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>

From martin at v.loewis.de  Wed Jul 14 07:48:45 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 14 Jul 2010 07:48:45 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTinhH0pYylCEAUOroajeRBkxG7v8EyoB0rb3rQD1@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>	<4C3B9282.9050700@v.loewis.de>	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>	<4C3B95CE.8090606@v.loewis.de>	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>	<4C3B9B89.4090602@v.loewis.de>	<4C3BC01C.7060100@canterbury.ac.nz>	<4C3C0992.7030002@v.loewis.de>	<AANLkTikyVARfkfFezEvuSA2-1v48h-vJMda9KiRsszjZ@mail.gmail.com>	<4C3CCF02.3070703@v.loewis.de>
	<AANLkTinhH0pYylCEAUOroajeRBkxG7v8EyoB0rb3rQD1@mail.gmail.com>
Message-ID: <4C3D4FBD.5020804@v.loewis.de>

> No. If the fix Greg proposed is accepted by The PSF, this feature will
> work again and you will be able to use it again. It worked perfectly
> fine before the change.
> 
> Martin, if you want to remove some feature from Distutils, make a proposal.
> 
> But you can't decide on your own that a feature in a project
> maintained by a bunch of other people, has to go.

Van Lindberg has approved the change. However, I won't have time to
implement it in a foreseeable future. Can you provide a patch?

Regards,
Martin

From gary.poster at canonical.com  Wed Jul 14 10:44:01 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Wed, 14 Jul 2010 10:44:01 +0200
Subject: [Distutils] [buildout] buildout 1.5 sometime ever please?
In-Reply-To: <AANLkTik1czuqRVffYhV4JKXk9dUD8N0G_A0uacDVTuGC@mail.gmail.com>
References: <i14jq4$2ce$2@dough.gmane.org> <125219683.20100708163350@gmail.com>
	<AANLkTilF-jEiXzAE7B261eJinRzq8sjMrl9XDgd95u4S@mail.gmail.com>
	<128034701.20100708171502@gmail.com>
	<5CF9504B-6671-436C-A73F-D9D835DDBB49@canonical.com>
	<AANLkTin84m8k4eR5Le84FkRxuRGXx_a_231KbUzhftPr@mail.gmail.com>
	<4D0FC70D-CBCD-4E8D-9ED7-AA4E4A4277B9@canonical.com>
	<AANLkTik1czuqRVffYhV4JKXk9dUD8N0G_A0uacDVTuGC@mail.gmail.com>
Message-ID: <4AD51DC3-39EA-4032-85E4-4E74E8FCB81D@canonical.com>


On Jul 13, 2010, at 6:52 PM, Dave Peticolas wrote:

> 
> 
> On Tue, Jul 13, 2010 at 2:53 AM, Gary Poster <gary.poster at canonical.com> wrote:
> 
> On Jul 13, 2010, at 1:59 AM, Dave Peticolas wrote:
> 
> ...
> 
> >
> > I'm testing out the beta branch
> 
> Thank you!
> 
> > and running into a problem. I'm running buildout from a virtualenv,
> > and when I try to install the 'superlance' package, I get this:
> >
> >   The required version of setuptools (>=0.6c9) is not available, and
> >   can't be installed while this script is running. Please install
> >   a more recent version first, using 'easy_install -U setuptools'.
> >
> >   (Currently using setuptools 0.6c8 (/usr/lib/python2.5/site-packages))
> >   error: Setup script exited with 2
> >
> > This is despite the fact that I have 0.6c11 installed in the virtualenv. This seems to be caused
> > by the fact that the buildout bin script has this:
> >
> >   import sys
> >   sys.path[0:0] = [
> >       '/tmp/ve/eggs/zc.buildout-1.5.0b2-py2.5.egg',
> >       '/usr/lib/python2.5/site-packages',
> >       ]
> >
> > And thus picks up the older version of setuptools in /usr/lib/python2.5. I tried removing those lines,
> > but buildout seems to be re-creating that file when I run it.
> >
> > Any suggestions?
> 
> (1) This may be unrelated to your problem, but I have *not* added support for using a virtualenv without --no-site-packages, and AFAIK it was never supported.  It looks like you are not using --no-site-packages in your virtualenv, so I  don't support that.
> 
> Gotcha. And adding --no-site-packages does seem to have cleared up my problem. Thank you!

Awesome, thank you for giving it a whirl.

> (2) It looks like you are using an old bootstrap.  In addition to using the code from the svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix/ branch (I guess you made your own release?), you also need to make sure you are using the bootstrap if you want to use the new feature without virtualenv.
> 
> I pretty much always use buildout in a virtualenv. In my test, I'm creating the virtualenv, and then using easy_install to install buildout from a checkout
> of your branch. Is there a better way to run the test?

That's probably fine.  I have a shared download-cache, so when I test, I make an sdist, put it in my download-cache, and give it a whirl.

Gary

From merwok at netwok.org  Wed Jul 14 10:48:30 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 14 Jul 2010 10:48:30 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C3D4FBD.5020804@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>	<AANLkTilL3kNWKf3rmNy7C3sP_igMUqDtBbmmBM9kXxgF@mail.gmail.com>	<AANLkTikkqHsDBPGNwZfEwSM-59MomPKznEPNCLI3OXSp@mail.gmail.com>	<AANLkTilJI5gBx-NxKPaM-8ZUCUi-nNXrErw5yVV5gXTR@mail.gmail.com>	<4C3B87B0.4010905@v.loewis.de>	<AANLkTinIB_PcRuzK2P-a48M38B78jTun9JnPyF-ZkckF@mail.gmail.com>	<4C3B9282.9050700@v.loewis.de>	<AANLkTikGUckdxnWRhJgJQWCI3NHwZKiQWTTprc1aX2b_@mail.gmail.com>	<4C3B95CE.8090606@v.loewis.de>	<AANLkTim1iJd_42Edcm3CbG7K-lWD8zDY5LIZDYWAFABd@mail.gmail.com>	<4C3B9B89.4090602@v.loewis.de>	<4C3BC01C.7060100@canterbury.ac.nz>	<4C3C0992.7030002@v.loewis.de>	<AANLkTikyVARfkfFezEvuSA2-1v48h-vJMda9KiRsszjZ@mail.gmail.com>	<4C3CCF02.3070703@v.loewis.de>	<AANLkTinhH0pYylCEAUOroajeRBkxG7v8EyoB0rb3rQD1@mail.gmail.com>
	<4C3D4FBD.5020804@v.loewis.de>
Message-ID: <4C3D79DE.8040409@netwok.org>

Le 14/07/2010 07:48, "Martin v. L?wis" a ?crit :
> Van Lindberg has approved the change. However, I won't have time to
> implement it in a foreseeable future. Can you provide a patch?

I looked at the code and asked for help in catalog-sig:
http://mail.python.org/pipermail/catalog-sig/2010-July/003131.html

Regards


From fuzzyman at gmail.com  Wed Jul 14 13:50:43 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Wed, 14 Jul 2010 12:50:43 +0100
Subject: [Distutils] Distribution downloads by pip (and multiple
	distribution types)
Message-ID: <AANLkTilYF8dX4DTufZWpUPRvm9Ku1M80OHPpfltq0AR-@mail.gmail.com>

Hello all,

For unittest2 I now have three different distributions. A "version" that
supports Python 2.4 - 2.7, one for Python 2.3 that is developed in a
separate branch because it makes the code ugly, and a separate distribution
for Python 3.

The reason I'm not using 2to3 with a single codebase is that unittest2 for
Python 3 is *basically* just a straight copy of the unittest package from
Python 3.2 (with a few fixes to work in 3.0 and a few other changes that are
in unittest2 anyway). Having a single distribution with multiple versions in
and having setup.py decide at install time would be another approach, but
that plays badly with test discovery.

So the challenge is, how do I put all of these up on PyPI and have pip
install the right one?

pip doesn't make it clear what versions of Python it supports, and the PyPI
page doesn't use the trove classifiers (naughty!), but I'm fine with users
of the Python 2.3 distribution having to download and install manually.

Unfortunately it *seems* that "pip install unittest2" (on Python 2.4 - 2.7)
will just install from whichever file was *most recently uploaded* to the
PyPI page - even if it is marked as not a source distribution and has Python
2.3 in the name. So, the good news is that if you've used pip to install
unittest2 in the last few days you've got the Python 2.3 version. It is
feature complete with tests, so that shouldn't actually be a problem.

As far as I can tell the only way I can solve this is to remove the Python
2.3 download from PyPI and host it separately, which is what I've now done.
(Download link on the PyPI page if you need it.)

Similarly I guess there is no way to have a Python 3 distribution under the
same project and have pip install the correct distribution under the correct
version of Python.

To get round this I have created a separate project: unittest2py3k. It still
installs the same *package name*, just has a different project name.

Now if distutils2 could solve these problems, that would be great. :-) I'm
aware that setuptools / distribute allows you to provide (what are
effectively binary) distributions for specific Python versions, but I need
to support pip too.

It would also be great if there was a way of specifying "this distribution
is for Python 2.4 - 2.7", or even "any version of Python 2 after 2.4".

All the best,

Michael

-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100714/8359d171/attachment.html>

From fuzzyman at voidspace.org.uk  Wed Jul 14 15:33:19 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 14 Jul 2010 14:33:19 +0100
Subject: [Distutils] Installing distribute with Python 3.0 / 3.1
In-Reply-To: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>
References: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>
Message-ID: <AANLkTikj49Eov8gzWlMCuY3wB-s23K5uhjaRNi8aYyws@mail.gmail.com>

So, deleting the distribution and retrying with distribute_setup.py and
Python 3.1 worked fine. I wonder if the run with 3.0 cached some (broken)
files from the 2to3 run.

All the best,

Michael

On 13 July 2010 23:56, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

> I get the following error attempting to install distribute 0.6.13 with
> Python 3.0 / 3.1:
>
> python3.0 setup.py install
> creating build
> creating build/src
> creating build/src/docs
> creating build/src/docs/_templates
>
> creating build/src/docs/_theme
> creating build/src/docs/_theme/nature
> creating build/src/docs/_theme/nature/static
> creating build/src/setuptools
> creating build/src/setuptools/command
> creating build/src/setuptools/tests
>
> creating build/src/tests
> creating build/src/tests/shlib_test
> copying setuptools/__init__.py -> build/src/setuptools
> copying setuptools/archive_util.py -> build/src/setuptools
> copying setuptools/depends.py -> build/src/setuptools
>
> copying setuptools/dist.py -> build/src/setuptools
> copying setuptools/extension.py -> build/src/setuptools
> copying setuptools/package_index.py -> build/src/setuptools
> copying setuptools/sandbox.py -> build/src/setuptools
>
> copying setuptools/tests/__init__.py -> build/src/setuptools/tests
> copying setuptools/tests/doctest.py -> build/src/setuptools/tests
> copying setuptools/tests/server.py -> build/src/setuptools/tests
> copying setuptools/tests/test_build_ext.py -> build/src/setuptools/tests
>
> copying setuptools/tests/test_develop.py -> build/src/setuptools/tests
> copying setuptools/tests/test_easy_install.py -> build/src/setuptools/tests
> copying setuptools/tests/test_packageindex.py -> build/src/setuptools/tests
>
> copying setuptools/tests/test_resources.py -> build/src/setuptools/tests
> copying setuptools/tests/test_sandbox.py -> build/src/setuptools/tests
> copying setuptools/tests/test_upload_docs.py -> build/src/setuptools/tests
>
> copying setuptools/command/__init__.py -> build/src/setuptools/command
> copying setuptools/command/alias.py -> build/src/setuptools/command
> copying setuptools/command/bdist_egg.py -> build/src/setuptools/command
>
> copying setuptools/command/bdist_rpm.py -> build/src/setuptools/command
> copying setuptools/command/bdist_wininst.py -> build/src/setuptools/command
> copying setuptools/command/build_ext.py -> build/src/setuptools/command
>
> copying setuptools/command/build_py.py -> build/src/setuptools/command
> copying setuptools/command/develop.py -> build/src/setuptools/command
> copying setuptools/command/easy_install.py -> build/src/setuptools/command
>
> copying setuptools/command/easy_install2.py -> build/src/setuptools/command
> copying setuptools/command/egg_info.py -> build/src/setuptools/command
> copying setuptools/command/install.py -> build/src/setuptools/command
>
> copying setuptools/command/install_egg_info.py -> build/src/setuptools/command
> copying setuptools/command/install_lib.py -> build/src/setuptools/command
> copying setuptools/command/install_scripts.py -> build/src/setuptools/command
>
> copying setuptools/command/register.py -> build/src/setuptools/command
> copying setuptools/command/rotate.py -> build/src/setuptools/command
> copying setuptools/command/saveopts.py -> build/src/setuptools/command
>
> copying setuptools/command/sdist.py -> build/src/setuptools/command
> copying setuptools/command/setopt.py -> build/src/setuptools/command
> copying setuptools/command/test.py -> build/src/setuptools/command
>
> copying setuptools/command/upload.py -> build/src/setuptools/command
> copying setuptools/command/upload_docs.py -> build/src/setuptools/command
> copying setuptools/tests/win_script_wrapper.txt -> build/src/setuptools/tests
>
> copying setuptools/cli.exe -> build/src/setuptools
> copying setuptools/gui.exe -> build/src/setuptools
> copying tests/install_test.py -> build/src/tests
> copying tests/manual_test.py -> build/src/tests
>
> copying tests/test_distribute_setup.py -> build/src/tests
> copying tests/shlib_test/setup.py -> build/src/tests/shlib_test
> copying tests/shlib_test/test_hello.py -> build/src/tests/shlib_test
> copying tests/shlib_test/hello.c -> build/src/tests/shlib_test
>
> copying tests/shlib_test/hellolib.c -> build/src/tests/shlib_test
> copying tests/shlib_test/hello.pyx -> build/src/tests/shlib_test
> copying tests/api_tests.txt -> build/src/tests
> RefactoringTool: Skipping implicit fixer: buffer
>
> RefactoringTool: Skipping implicit fixer: idioms
> RefactoringTool: Skipping implicit fixer: set_literal
> RefactoringTool: Skipping implicit fixer: ws_comma
> --- build/src/tests/api_tests.txt (original)
> +++ build/src/tests/api_tests.txt (refactored)
>
> @@ -39,7 +39,7 @@
>      >>> dist.py_version == sys.version[:3]
>      True
>
> -    >>> print dist.platform
> +    >>> print(dist.platform)
>      None
>
>  Including various computed attributes::
>
> @@ -199,7 +199,7 @@
>  You can ask a WorkingSet to ``find()`` a distribution matching a requirement::
>
>      >>> from pkg_resources import Requirement
> -    >>> print ws.find(Requirement.parse("Foo==1.0"))    # no match, return None
>
> +    >>> print(ws.find(Requirement.parse("Foo==1.0")))    # no match, return None
>      None
>
>      >>> ws.find(Requirement.parse("Bar==0.9"))  # match, return distribution
>
> @@ -211,7 +211,7 @@
>      >>> try:
>      ...     ws.find(Requirement.parse("Bar==1.0"))
>      ... except VersionConflict:
> -    ...     print 'ok'
> +    ...     print('ok')
>
>      ok
>
>  You can subscribe a callback function to receive notifications whenever a new
> @@ -219,7 +219,7 @@
>  once for each existing distribution in the working set, and then is called
>  again for new distributions added thereafter::
>
>
> -    >>> def added(dist): print "Added", dist
> +    >>> def added(dist): print("Added", dist)
>      >>> ws.subscribe(added)
>      Added Bar 0.9
>      >>> foo12 = Distribution(project_name="Foo", version="1.2", location="f12")
>
> RefactoringTool: Files that were modified:
> RefactoringTool: build/src/tests/api_tests.txt
> copying docs/conf.py -> build/src/docs
> copying docs/easy_install.txt -> build/src/docs
> copying docs/index.txt -> build/src/docs
>
> copying docs/pkg_resources.txt -> build/src/docs
> copying docs/python3.txt -> build/src/docs
> copying docs/roadmap.txt -> build/src/docs
> copying docs/setuptools.txt -> build/src/docs
> copying docs/using.txt -> build/src/docs
>
> copying docs/_theme/nature/theme.conf -> build/src/docs/_theme/nature
> copying docs/_theme/nature/static/pygments.css -> build/src/docs/_theme/nature/static
> copying docs/_theme/nature/static/nature.css_t -> build/src/docs/_theme/nature/static
>
> copying docs/Makefile -> build/src/docs
> copying docs/_templates/indexsidebar.html -> build/src/docs/_templates
> copying distribute_setup.py -> build/src
> copying easy_install.py -> build/src
> copying pkg_resources.py -> build/src
>
> copying setup.py -> build/src
> copying site.py -> build/src
> copying CHANGES.txt -> build/src
> copying CONTRIBUTORS.txt -> build/src
> copying DEVGUIDE.txt -> build/src
> copying pip-log.txt -> build/src
>
> copying README.txt -> build/src
> copying MANIFEST.in -> build/src
> copying launcher.c -> build/src
> Skipping implicit fixer: buffer
> Skipping implicit fixer: idioms
> Skipping implicit fixer: set_literal
>
> Skipping implicit fixer: ws_comma
> Before install bootstrap.
> Scanning installed packages
> No setuptools distribution found
> running install
> Traceback (most recent call last):
>   File "setup.py", line 211, in <module>
>
>     scripts = scripts,
>   File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/core.py", line 149, in setup
>     dist.run_commands()
>   File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py", line 942, in run_commands
>
>     self.run_command(cmd)
>   File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/distutils/dist.py", line 962, in run_command
>     cmd_obj.run()
>   File "build/src/setuptools/command/install.py", line 73, in run
>
>     self.do_egg_install()
>   File "build/src/setuptools/command/install.py", line 82, in do_egg_install
>     easy_install = self.distribution.get_command_class('easy_install')
>   File "build/src/setuptools/dist.py", line 361, in get_command_class
>
>     self.cmdclass[command] = cmdclass = ep.load()
>   File "build/src/pkg_resources.py", line 1954, in load
>     entry = __import__(self.module_name, globals(),globals(), ['__name__'])
>   File "build/src/setuptools/command/easy_install.py", line 16, in <module>
>
>     from setuptools.sandbox import run_setup
>   File "build/src/setuptools/sandbox.py", line 232, in <module>
>     WRITE_FLAGS = reduce(
> NameError: name 'reduce' is not defined
> bigmac:distribute-0.6.13 michael$ python3.1 setup.py install
>
> Before install bootstrap.
> Scanning installed packages
> No setuptools distribution found
> running install
> Traceback (most recent call last):
>   File "setup.py", line 211, in <module>
>     scripts = scripts,
>
>   File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/core.py", line 149, in setup
>     dist.run_commands()
>   File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py", line 919, in run_commands
>
>     self.run_command(cmd)
>   File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/distutils/dist.py", line 938, in run_command
>     cmd_obj.run()
>   File "build/src/setuptools/command/install.py", line 73, in run
>
>     self.do_egg_install()
>   File "build/src/setuptools/command/install.py", line 82, in do_egg_install
>     easy_install = self.distribution.get_command_class('easy_install')
>   File "build/src/setuptools/dist.py", line 361, in get_command_class
>
>     self.cmdclass[command] = cmdclass = ep.load()
>   File "build/src/pkg_resources.py", line 1954, in load
>     entry = __import__(self.module_name, globals(),globals(), ['__name__'])
>   File "build/src/setuptools/command/easy_install.py", line 16, in <module>
>
>     from setuptools.sandbox import run_setup
>   File "build/src/setuptools/sandbox.py", line 232, in <module>
>     WRITE_FLAGS = reduce(
> NameError: name 'reduce' is not defined
>
>
>
> --
> http://www.voidspace.org.uk
>
>
>


-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100714/211c7f52/attachment-0001.html>

From merwok at netwok.org  Wed Jul 14 15:41:02 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 14 Jul 2010 15:41:02 +0200
Subject: [Distutils] Installing distribute with Python 3.0 / 3.1
In-Reply-To: <AANLkTikj49Eov8gzWlMCuY3wB-s23K5uhjaRNi8aYyws@mail.gmail.com>
References: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>
	<AANLkTikj49Eov8gzWlMCuY3wB-s23K5uhjaRNi8aYyws@mail.gmail.com>
Message-ID: <4C3DBE6E.5060202@netwok.org>

> I wonder if the run with 3.0 cached some (broken)
> files from the 2to3 run.

Distutils? build command uses make-style heuristics to find which files
to rebuild IIUC, so it?s very possible that?s the answer.

>> [snip wall of text] ;-)

Regards


From hltbra at gmail.com  Wed Jul 14 17:03:47 2010
From: hltbra at gmail.com (Hugo Lopes Tavares)
Date: Wed, 14 Jul 2010 12:03:47 -0300
Subject: [Distutils] Installing distribute with Python 3.0 / 3.1
In-Reply-To: <4C3DBE6E.5060202@netwok.org>
References: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>
	<AANLkTikj49Eov8gzWlMCuY3wB-s23K5uhjaRNi8aYyws@mail.gmail.com>
	<4C3DBE6E.5060202@netwok.org>
Message-ID: <AANLkTikfwzcthOkHvc6eBgL3ZDWeNwABpkJ83UiQEe2-@mail.gmail.com>

Maybe a problem related to __pycache__ folder created by compile call?
In python there is no longer execfile, and 2to3 converts execfile(filename) to:
execfile(compile(open(filename).read(), filename, 'exec'))
And it creates a __pycache__ folder. Maybe that's the problem..

On Wed, Jul 14, 2010 at 10:41 AM, ?ric Araujo <merwok at netwok.org> wrote:
>> I wonder if the run with 3.0 cached some (broken)
>> files from the 2to3 run.
>
> Distutils? build command uses make-style heuristics to find which files
> to rebuild IIUC, so it?s very possible that?s the answer.
>
>>> [snip wall of text] ;-)
>
> Regards
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From merwok at netwok.org  Wed Jul 14 21:46:37 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 14 Jul 2010 21:46:37 +0200
Subject: [Distutils] Installing distribute with Python 3.0 / 3.1
In-Reply-To: <AANLkTikfwzcthOkHvc6eBgL3ZDWeNwABpkJ83UiQEe2-@mail.gmail.com>
References: <AANLkTin5K_LKO7MnBJNKv43iSOiUFjcRBCjEl6WTuDCS@mail.gmail.com>	<AANLkTikj49Eov8gzWlMCuY3wB-s23K5uhjaRNi8aYyws@mail.gmail.com>	<4C3DBE6E.5060202@netwok.org>
	<AANLkTikfwzcthOkHvc6eBgL3ZDWeNwABpkJ83UiQEe2-@mail.gmail.com>
Message-ID: <4C3E141D.5010207@netwok.org>

PEP 3147 (__pycache__ directories) is 3.2-only.

No idea about the exec/execfile thing.

Regards


From gary.poster at canonical.com  Thu Jul 15 16:15:30 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 15 Jul 2010 16:15:30 +0200
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com>
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com>
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com>
Message-ID: <63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>

Hi Lennart.

I cannot duplicate this when running the tests for zc.recipe.testrunner, which was what you appeared to be doing.  

I do see some test failures in that package, some of them caused by the buildout change, but they are reasonable: the tests check for the actual script output, which is fragile, and which broke.

I used Python 2.6, as you appeared to be.  I have tried running with both 1.5.0b1 and a version of my current betafix branch.

Running within a --no-site-packages  virtualenv and b1 did break with errors like "IOError: [Errno 2] No such file or directory: '/tmp/tmpHXetXtbuildoutSetUp/_TEST_/sample-buildout/parts/buildout/orig-prefix.txt'".  That doesn't look like the error you are reporting.  These also are fixed with my betafix branch.

Can you give me some instructions to duplicate?

Thanks

Gary


On Apr 30, 2010, at 9:46 PM, Lennart Regebro wrote:

> Another bug:
> 
> In code like this:
> 
> def setUp(test):
>    zc.buildout.testing.buildoutSetUp(test)
>    zc.buildout.testing.install_develop('zc.recipe.testrunner', test)
>    zc.buildout.testing.install_develop('zc.recipe.egg', test)
>    zc.buildout.testing.install('zope.testing', test)
>    zc.buildout.testing.install('zope.testrunner', test)
>    zc.buildout.testing.install('zope.interface', test)
>    zc.buildout.testing.install('zope.exceptions', test)
> 
> You get the following error:
> 
> Traceback (most recent call last):
>  File "/opt/python26/lib/python2.6/doctest.py", line 2120, in setUp
>    self._dt_setUp(test)
>  File "/home/projects/zc.recipe.testrunner/trunk/src/zc/recipe/testrunner/tests.py",
> line 25, in setUp
>    zc.buildout.testing.buildoutSetUp(test)
>  File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/testing.py",
> line 332, in buildoutSetUp
>    make_buildout()
>  File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/testing.py",
> line 272, in make_buildout
>    ).bootstrap([])
>  File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/buildout.py",
> line 373, in bootstrap
>    include_site_packages=False,
>  File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/easy_install.py",
> line 1030, in install
>    return installer.install(specs, working_set)
>  File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/easy_install.py",
> line 843, in install
>    for dist in self._get_dist(requirement, ws, self._always_unzip):
>  File "/home/projects/zc.recipe.testrunner/trunk/zc.buildout-1.5.0b1-py2.6.egg/zc/buildout/easy_install.py",
> line 678, in _get_dist
>    raise MissingDistribution(requirement, ws)
> MissingDistribution: Couldn't find a distribution for 'distribute'.
> 
> 
> Going back to 1.4.3 (and zc.recipe.egg 1.2.2 solves the problem.
> 
> -- 
> Lennart Regebro: http://regebro.wordpress.com/
> Python 3 Porting: http://python-incompatibility.googlecode.com/
> +33 661 58 14 64


From chris at simplistix.co.uk  Fri Jul 16 17:09:41 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 16 Jul 2010 16:09:41 +0100
Subject: [Distutils] buildout and issues with dependencies and patch.
In-Reply-To: <AANLkTingccelEkjoe9KeDGtEJ3BulI9RB0CYfts4-Czc@mail.gmail.com>
References: <7BA0A3A9-1149-41FB-AA37-974AF2D4BE2B@linovia.com>
	<AANLkTingccelEkjoe9KeDGtEJ3BulI9RB0CYfts4-Czc@mail.gmail.com>
Message-ID: <4C407635.9070402@simplistix.co.uk>

Jim Fulton wrote:
> matplotlib is problematic for buildout due to the introspection it
> does.  I haven't found a good solution.  What I've done in the past is
> to make a not-so-clean Python (or virtualenv) that has numpy installed
> and then use buildout with that to install matplotlib.
> 
> (Another work-around occurs to me, which I will try and report back. :)

I've had success by building matplotlib and numpy binary eggs for each 
platform you want to deploy on by:

- unpacking the source distro
- python setup.py bdist_egg (can't remember the exact incantation here)
- putting the resulting egg somewhere that a --find-links or buildout 
equivalent can find.

>> My second question is, I also want to install pysvn. 

I would avoid using pysvn if at all possible. I've had serious problems 
with this being compiled against one set of svn libraries which the 
"real" client being used was compiled against another. Because of SVN's 
propensity for changing their working copy format with *every f'ing 
point release* this becomes extremely frustrating.

I tend to just shell out to the svn command and process the returned 
results with execute:

http://packages.python.org/execute/

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From pav at iki.fi  Sun Jul 18 16:43:20 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 18 Jul 2010 14:43:20 +0000 (UTC)
Subject: [Distutils] [OT] Caching 2to3 results
Message-ID: <i1v3u8$hsm$1@dough.gmane.org>

[shameless plug]

For those of you tired of waiting for 2to3 after "rm -rf build":

	http://github.com/pv/lib2to3cache

and

	cd numpy/
	USE_2TO3CACHE=1 python3 setup.py build

-- 
Pauli Virtanen


From pav at iki.fi  Sun Jul 18 16:45:03 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 18 Jul 2010 14:45:03 +0000 (UTC)
Subject: [Distutils] [OT] Caching 2to3 results
References: <i1v3u8$hsm$1@dough.gmane.org>
Message-ID: <i1v41f$hsm$2@dough.gmane.org>

Sun, 18 Jul 2010 14:43:20 +0000, Pauli Virtanen wrote:
> [shameless plug]

Sorry about the noise, I tried to aim this at the numpy-discussion list, 
but apparently failed...

-- 
Pauli Virtanen


From regebro at gmail.com  Thu Jul 22 11:51:39 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 22 Jul 2010 10:51:39 +0100
Subject: [Distutils] Failing test on zc.buildout.
Message-ID: <AANLkTimyq6BhKdDNNC88rubrikTDmxjBiAxFbpfgyne_@mail.gmail.com>

I was going to update zc.buildout to use doctest instead of
zope.testing.doctest and zope.testrunner instead of
zope.testing.testrunner, and I noticed trunk has some failing tests.
They all use the --setup-source option, but:

  bootstrap.py: error: no such option: --setup-source

So there is something wrong there. I'll probably comment those failing
tests out for the moment, unless somebody fixes them or tells me to
remove them completely. :-)

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.com/
+33 661 58 14 64

From gary.poster at canonical.com  Thu Jul 22 13:01:21 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 22 Jul 2010 07:01:21 -0400
Subject: [Distutils] Failing test on zc.buildout.
In-Reply-To: <AANLkTimyq6BhKdDNNC88rubrikTDmxjBiAxFbpfgyne_@mail.gmail.com>
References: <AANLkTimyq6BhKdDNNC88rubrikTDmxjBiAxFbpfgyne_@mail.gmail.com>
Message-ID: <4741F5E2-A44A-403A-9A69-9688FF0D67D1@canonical.com>

Hi Lennart.  Some of this has been discussed on the list before, and I'm afraid you have duplicated some work with the zope.testing changes.  

Specific to this question, the bootstrap on trunk is the wrong bootstrap because of the virtualenv problems and the fact that people use externals to link to bootstrap.

Please see the thread started by Martijn for follow-up, or I'm happy to talk to you on IRC (which might be nice if you can help me dupe the problem you reported against 1.5.0b1, as I wrote you a week or two ago).

In related news, I have decided on a way forward with releasing buildout.

- In my betafix branch, I have already made zc.buildout work with virtualenv as far as I know, as announced before and confirmed by at least one person.
- In case anyone encounters issues with the next beta release, I will create an "aspirin" release: a zc.buildout 1.4.4 that prefers itself if a version is not specified, and a bootstrap that prefers 1.4.4 if it is not specified.  This should give people a way to alleviate their immediate problems if they encounter any: people can just switch to the "aspirin" bootstrap and stay in the 1.4.4 line of zc.buildout until problems are resolved.
- I will make 1.5.0 and its associated bootstrap automatically prefer final releases *for the build system* (zc.buildout and recipes) so that we won't encounter this problem again.

Once I do this, I'll merge my betafix branch back to trunk (fixing tests on trunk) and make a b3 release.

Thanks to Benji York for helping me figure out this plan of attack.

Gary



On Jul 22, 2010, at 5:51 AM, Lennart Regebro wrote:

> I was going to update zc.buildout to use doctest instead of
> zope.testing.doctest and zope.testrunner instead of
> zope.testing.testrunner, and I noticed trunk has some failing tests.
> They all use the --setup-source option, but:
> 
>  bootstrap.py: error: no such option: --setup-source
> 
> So there is something wrong there. I'll probably comment those failing
> tests out for the moment, unless somebody fixes them or tells me to
> remove them completely. :-)
> 
> -- 
> Lennart Regebro: http://regebro.wordpress.com/
> Python 3 Porting: http://python3porting.com/
> +33 661 58 14 64
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From regebro at gmail.com  Thu Jul 22 18:47:29 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 22 Jul 2010 17:47:29 +0100
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com> 
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com> 
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com> 
	<63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
Message-ID: <AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com>

On Thu, Jul 15, 2010 at 15:15, Gary Poster <gary.poster at canonical.com> wrote:
> Hi Lennart.
>
> I cannot duplicate this when running the tests for zc.recipe.testrunner, which was what you appeared to be doing.

Well, in that case it probably works now. I'll try again (with the
betafix branch, right?)

From gary.poster at canonical.com  Thu Jul 22 20:10:48 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Thu, 22 Jul 2010 14:10:48 -0400
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com>
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com>
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com>
	<63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
	<AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com>
Message-ID: <47844ACC-79AB-401F-AB37-DC8D99C6EEB1@canonical.com>


On Jul 22, 2010, at 12:47 PM, Lennart Regebro wrote:

> On Thu, Jul 15, 2010 at 15:15, Gary Poster <gary.poster at canonical.com> wrote:
>> Hi Lennart.
>> 
>> I cannot duplicate this when running the tests for zc.recipe.testrunner, which was what you appeared to be doing.
> 
> Well, in that case it probably works now. I'll try again (with the
> betafix branch, right?)

Yeah, exactly (though like I said, I couldn't dupe it with 1.5.0b1 either)

Thanks

Gary

From regebro at gmail.com  Fri Jul 23 12:46:37 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 23 Jul 2010 11:46:37 +0100
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <47844ACC-79AB-401F-AB37-DC8D99C6EEB1@canonical.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com> 
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com> 
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com> 
	<63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
	<AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com> 
	<47844ACC-79AB-401F-AB37-DC8D99C6EEB1@canonical.com>
Message-ID: <AANLkTin6Pdnf8VidoLa9nVKAJpMbCi6W1t_o49fwbaJR@mail.gmail.com>

On Thu, Jul 22, 2010 at 19:10, Gary Poster <gary.poster at canonical.com> wrote:
>> Well, in that case it probably works now. I'll try again (with the
>> betafix branch, right?)
>
> Yeah, exactly (though like I said, I couldn't dupe it with 1.5.0b1 either)

OK, the way to duplicate it is to run the tests with

  $python setup.py test

To make that happen with 1.5.0dev, you have to make an sdist, put that
in the trunk directory, and also add

    dependency_links = ['.'],

to setup.py parameters.

The error doesn't appear if you run bin/test. Although I get other
errors when I do that. However, they are not related to your branch,
that happens with 1.5.0b2 as well:

Failed example:
    print system(os.path.join(sample_buildout, 'bin', 'buildout') + ' -q'),
Expected nothing
Got:
    install_dir
/tmp/tmpa_M-fRbuildoutSetUp/_TEST_/sample-buildout/develop-eggs/tmpDfJdS0build
    install_dir
/tmp/tmpa_M-fRbuildoutSetUp/_TEST_/sample-buildout/develop-eggs/tmpDfNtGFbuild
    install_dir
/tmp/tmpa_M-fRbuildoutSetUp/_TEST_/sample-buildout/develop-eggs/tmpuSWFFvbuild


However, with 1.5.0b2 and python setup.py test, the tests passes.
What a mess. :-)

-- 
Lennart Regebro, Colliberty: http://www.colliberty.com/
Python, Zope, Plone blog: http://regebro.wordpress.com/
Telephone: +33 661 58 14 64

From gary.poster at canonical.com  Fri Jul 23 15:05:01 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Fri, 23 Jul 2010 09:05:01 -0400
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <AANLkTin6Pdnf8VidoLa9nVKAJpMbCi6W1t_o49fwbaJR@mail.gmail.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com>
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com>
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com>
	<63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
	<AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com>
	<47844ACC-79AB-401F-AB37-DC8D99C6EEB1@canonical.com>
	<AANLkTin6Pdnf8VidoLa9nVKAJpMbCi6W1t_o49fwbaJR@mail.gmail.com>
Message-ID: <B02788B9-F2FB-49EF-AE68-381DA5FCF48C@canonical.com>


On Jul 23, 2010, at 6:46 AM, Lennart Regebro wrote:

> On Thu, Jul 22, 2010 at 19:10, Gary Poster <gary.poster at canonical.com> wrote:
>>> Well, in that case it probably works now. I'll try again (with the
>>> betafix branch, right?)
>> 
>> Yeah, exactly (though like I said, I couldn't dupe it with 1.5.0b1 either)
> 
> OK, the way to duplicate it is to run the tests with
> 
>  $python setup.py test
> 
> To make that happen with 1.5.0dev, you have to make an sdist, put that
> in the trunk directory, and also add
> 
>    dependency_links = ['.'],
> 
> to setup.py parameters.
> 
> The error doesn't appear if you run bin/test.

Ah, ok.

To my knowledge, these packages don't support that spelling.  bin/test is the way to run the tests for the Zope packages AFAIK.  Do you, or others, disagree?  The fact that you have to modify setup.py in order to run your example seems to support my perspective.

If you disagree, I'll see if I can address, but I'd rather not add that to the release blockers if I don't have to.

> Although I get other
> errors when I do that. However, they are not related to your branch,
> that happens with 1.5.0b2 as well:
> 
> Failed example:
>    print system(os.path.join(sample_buildout, 'bin', 'buildout') + ' -q'),
> Expected nothing
> Got:
>    install_dir
> /tmp/tmpa_M-fRbuildoutSetUp/_TEST_/sample-buildout/develop-eggs/tmpDfJdS0build
>    install_dir
> /tmp/tmpa_M-fRbuildoutSetUp/_TEST_/sample-buildout/develop-eggs/tmpDfNtGFbuild
>    install_dir
> /tmp/tmpa_M-fRbuildoutSetUp/_TEST_/sample-buildout/develop-eggs/tmpuSWFFvbuild

The install_dir stuff appears to be something that distribute adds.  They didn't show up with setuptools.  I just made the buildout tests in my betafix branch ignore them.  As far as I know, that's a reasonable approach.

Gary

From bletofarine at gmail.com  Fri Jul 23 14:46:37 2010
From: bletofarine at gmail.com (Florian Le Goff)
Date: Fri, 23 Jul 2010 14:46:37 +0200
Subject: [Distutils] distutils.Extension : setting a concurrency level
Message-ID: <AANLkTikJJSKD0QwE0BS3jpiHN6B=Mxan8tang8UgwY=e@mail.gmail.com>

Hi,

I'm wondering how to reproduce the equivalent of "make -j<n>" on a
setup.py script.

In my setup, I'm using distutils.Extension to build a C(++, somehow)
extension to Python 2.6. I have a few dozens files in the "sources"
parameter of the Extension module and I would like to get a chance to
use my multi-core CPU to speed up my extension's build.

My desired outcome: having setup.py build using a few instances of my
C-compiler in the same time, instead of only one.

There are probably an environnement var or two that I'm missing. Or
maybe it could be an interesting feature for distutils2 ?

Thank you for your help.

-- 
Florian Le Goff
Lille, France

From ziade.tarek at gmail.com  Fri Jul 23 15:40:57 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 23 Jul 2010 15:40:57 +0200
Subject: [Distutils] distutils.Extension : setting a concurrency level
In-Reply-To: <AANLkTikJJSKD0QwE0BS3jpiHN6B=Mxan8tang8UgwY=e@mail.gmail.com>
References: <AANLkTikJJSKD0QwE0BS3jpiHN6B=Mxan8tang8UgwY=e@mail.gmail.com>
Message-ID: <AANLkTi=LurVpsaHpw75oMGABpDZjk6mBwmFkW-aJ_rH0@mail.gmail.com>

On Fri, Jul 23, 2010 at 2:46 PM, Florian Le Goff <bletofarine at gmail.com> wrote:
> Hi,
>
> I'm wondering how to reproduce the equivalent of "make -j<n>" on a
> setup.py script.
>
> In my setup, I'm using distutils.Extension to build a C(++, somehow)
> extension to Python 2.6. I have a few dozens files in the "sources"
> parameter of the Extension module and I would like to get a chance to
> use my multi-core CPU to speed up my extension's build.
>
> My desired outcome: having setup.py build using a few instances of my
> C-compiler in the same time, instead of only one.
>
> There are probably an environnement var or two that I'm missing. Or
> maybe it could be an interesting feature for distutils2 ?

This is not possible in Distutils, and I know that Martin wanted such
a feature, ccing him, not sure if he did something.

In any case, building extensions in parallel would definitely be an
improvement and a patch for distutils2 is welcome

Regards
Tarek

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

From regebro at gmail.com  Fri Jul 23 16:07:06 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 23 Jul 2010 15:07:06 +0100
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <B02788B9-F2FB-49EF-AE68-381DA5FCF48C@canonical.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com> 
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com> 
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com> 
	<63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
	<AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com> 
	<47844ACC-79AB-401F-AB37-DC8D99C6EEB1@canonical.com>
	<AANLkTin6Pdnf8VidoLa9nVKAJpMbCi6W1t_o49fwbaJR@mail.gmail.com> 
	<B02788B9-F2FB-49EF-AE68-381DA5FCF48C@canonical.com>
Message-ID: <AANLkTikMKsS2VONymHW+Zzi10ir2Jf8gZCkNP5xFs9+U@mail.gmail.com>

On Fri, Jul 23, 2010 at 14:05, Gary Poster <gary.poster at canonical.com> wrote:
> To my knowledge, these packages don't support that spelling. ?bin/test is the way to run the tests for the Zope packages AFAIK. ?Do you, or others, disagree? ?The fact that you have to modify setup.py in order to run your example seems to support my perspective.

I only need to modify it to run it with unreleased modules.

> If you disagree, I'll see if I can address, but I'd rather not add that to the release blockers if I don't have to.

I disagree, because bin/test uses zc.recipe.testrunner and buildout,
which means that you must have those modules working before you can
test if they work. You get a horrid bootstrapping problem, and zope.*
is full of them. This has stopped Python 3 adoption, and I have in
fact been spendning most of the time on this getting rid of these
circular testing dependencies.

Porting to Python 3 is easy, as long as you don't have circular
dependencies, modules that use themselves to set up the development
environment or doctests. Unfortunately the zope world is full of all
three.

To add confusion, I made a custom test command that runs the
testrunner, and I tried doing the same from zc.recipe.testrunner, but
weirdly enough it didn't make a difference. However, it works under
Python 2.6, both ways.
(All versions have distribute 0.6.10 installed in site-packages)

So, complete and utter confusion. This does not fit my brain. :-)

From gary.poster at canonical.com  Fri Jul 23 16:09:43 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Fri, 23 Jul 2010 10:09:43 -0400
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <AANLkTikMKsS2VONymHW+Zzi10ir2Jf8gZCkNP5xFs9+U@mail.gmail.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com>
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com>
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com>
	<63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
	<AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com>
	<47844ACC-79AB-401F-AB37-DC8D99C6EEB1@canonical.com>
	<AANLkTin6Pdnf8VidoLa9nVKAJpMbCi6W1t_o49fwbaJR@mail.gmail.com>
	<B02788B9-F2FB-49EF-AE68-381DA5FCF48C@canonical.com>
	<AANLkTikMKsS2VONymHW+Zzi10ir2Jf8gZCkNP5xFs9+U@mail.gmail.com>
Message-ID: <22D94EC5-8608-4E93-B6B2-342993754CAC@canonical.com>


On Jul 23, 2010, at 10:07 AM, Lennart Regebro wrote:

> On Fri, Jul 23, 2010 at 14:05, Gary Poster <gary.poster at canonical.com> wrote:
>> To my knowledge, these packages don't support that spelling.  bin/test is the way to run the tests for the Zope packages AFAIK.  Do you, or others, disagree?  The fact that you have to modify setup.py in order to run your example seems to support my perspective.
> 
> I only need to modify it to run it with unreleased modules.
> 
>> If you disagree, I'll see if I can address, but I'd rather not add that to the release blockers if I don't have to.
> 
> I disagree,

OK, I'll look into it.

Gary

From regebro at gmail.com  Fri Jul 23 16:10:01 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 23 Jul 2010 15:10:01 +0100
Subject: [Distutils] Beta release of zc.buildout 1.5.0
In-Reply-To: <AANLkTikMKsS2VONymHW+Zzi10ir2Jf8gZCkNP5xFs9+U@mail.gmail.com>
References: <E5B3BE54-EF91-414F-AE67-DA5F45DF1DB1@canonical.com> 
	<14cd86b0bed6f8ca01af40a27bd87da7@mail.webfaction.com>
	<F4FAE039-33E5-4A9F-9841-6DF6A03463FB@canonical.com> 
	<s2y319e029f1004301246id74ea496i418db8e17d179220@mail.gmail.com> 
	<63450BFD-8F7A-4976-A2FC-0A9526710850@canonical.com>
	<AANLkTiniZr8oHs98k6nIlg4akXw7AMoMmqPbS7087ss2@mail.gmail.com> 
	<47844ACC-79AB-401F-AB37-DC8D99C6EEB1@canonical.com>
	<AANLkTin6Pdnf8VidoLa9nVKAJpMbCi6W1t_o49fwbaJR@mail.gmail.com> 
	<B02788B9-F2FB-49EF-AE68-381DA5FCF48C@canonical.com>
	<AANLkTikMKsS2VONymHW+Zzi10ir2Jf8gZCkNP5xFs9+U@mail.gmail.com>
Message-ID: <AANLkTimMHN5JkgiKSMCGBrowvTbafKj-PSvpN3w9A8Vs@mail.gmail.com>

On Fri, Jul 23, 2010 at 15:07, Lennart Regebro <regebro at gmail.com> wrote:
> However, it works under Python 2.6, both ways.

No it doesn't, my bad! It fails under Python 2.6 as well. I already
had b2 as an egg for 2.6 installed, so it used that instead of your
branch. That at least removes some of the confusion.

From martin at v.loewis.de  Sun Jul 25 23:57:23 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 25 Jul 2010 23:57:23 +0200
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com>
Message-ID: <4C4CB343.9010207@v.loewis.de>

> I wasn't able to make an account in PyPI using `setup.py register`.
> 
> http://pypi.python.org/pypi?:action=register_form require 'I agree'
> checkbox, but `distutils/command/register.py` doesn't seem to send
> a 'agree' form key/value to the PyPI server.
> 
> This problem occurs in the major python versions (include 2.7).
> 
> This introduced for PyPI site by
> https://svn.python.org/packages/trunk/pypi/webui.py rev-690.

Hi Takayuki,

Georg Brandl has now fixed the problem in r823.

Regards,
Martin

From chris at simplistix.co.uk  Mon Jul 26 19:04:04 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 26 Jul 2010 18:04:04 +0100
Subject: [Distutils] GCC versions and binary egg names
Message-ID: <4C4DC004.8060705@simplistix.co.uk>

Hi All,

In addition to the UCS2/4 problems already described by MAL and which 
I've bumped into myself, I now have a problem with binary linux eggs 
where the GCC version doesn't match that of the system the egg is being 
installed on.

Current egg metadata doesn't take either of these into account or even 
provide a way for the nature of the binary egg to be recorded.

How're people coping with this?
What are the future plans in this area?

cheers,

Chris


From cournape at gmail.com  Mon Jul 26 19:29:49 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 27 Jul 2010 02:29:49 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4DC004.8060705@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
Message-ID: <AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>

On Tue, Jul 27, 2010 at 2:04 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> In addition to the UCS2/4 problems already described by MAL and which I've
> bumped into myself, I now have a problem with binary linux eggs where the
> GCC version doesn't match that of the system the egg is being installed on.

That really should not be a problem, unless you use vastly different
versions of gcc.

> Current egg metadata doesn't take either of these into account or even
> provide a way for the nature of the binary egg to be recorded.
>
> How're people coping with this?
> What are the future plans in this area?

If you need to follow non trivial ABI aspects, the current python
infrastructure
is too simplistic. Also, I think that short of preparing rpm/deb for
the distributions you target, you are going into a very time consuming
process, and automated solution are completely beyond reach (the
closest being the build service from open suse, but that still depends
on the system packaging system).

Projects who manage to distribute cross distributions binaries usually
put a lot of manpower behind it (only the biggest ones or the ones
which strong financial incentive do it). Or they provide the whole
stack (EPD, Activestate distributions, Sage) so that they depend as
little as possible on the target environment.

cheers,

David

From chris at simplistix.co.uk  Mon Jul 26 19:39:14 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 26 Jul 2010 18:39:14 +0100
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>
References: <4C4DC004.8060705@simplistix.co.uk>
	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>
Message-ID: <4C4DC842.4020109@simplistix.co.uk>

David Cournapeau wrote:
> On Tue, Jul 27, 2010 at 2:04 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> Hi All,
>>
>> In addition to the UCS2/4 problems already described by MAL and which I've
>> bumped into myself, I now have a problem with binary linux eggs where the
>> GCC version doesn't match that of the system the egg is being installed on.
> 
> That really should not be a problem, unless you use vastly different
> versions of gcc.

Such as between Ubuntu 8.04 and 10.04? ;-)

>>
>> How're people coping with this?
>> What are the future plans in this area?
> 
> If you need to follow non trivial ABI aspects, the current python
> infrastructure
> is too simplistic.

One idea I've had is to have a separate index for each required 
combination and use layered --find-links= with easy_install to pick the 
right combination.

eg:

easy_install --find-links=/private/eggs --find-links=/8.04-eggs somepack

How do people feel about this as a solution?

I can't remember, can buildout and/or easy_install support multiple 
find-links locations?

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From pje at telecommunity.com  Mon Jul 26 19:42:21 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 26 Jul 2010 13:42:21 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4DC004.8060705@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
Message-ID: <20100726174219.4159C3A40D9@sparrow.telecommunity.com>

At 06:04 PM 7/26/2010 +0100, Chris Withers wrote:
>Hi All,
>
>In addition to the UCS2/4 problems already described by MAL and 
>which I've bumped into myself, I now have a problem with binary 
>linux eggs where the GCC version doesn't match that of the system 
>the egg is being installed on.
>
>Current egg metadata doesn't take either of these into account or 
>even provide a way for the nature of the binary egg to be recorded.
>
>How're people coping with this?
>What are the future plans in this area?

Egg binaries aren't a great idea on Linux; they were mainly intended 
for Windows and Mac, where the architectures are uniform and working 
compilers aren't just an apt-get or yum away.

(Ironically, this is a side effect of eggs being invented *before* 
easy_install; if I'd thought of easy_install *first*, I might not've 
bothered with eggs (as a distribution format) at all.  Certainly, 
sdists don't add a lot of installation overhead except on 
compiler-less platforms.)

Incidentally, if you look way, way back in the distutils-sig 
archives, you can see where I first raised the question of platform 
strings and addressing some of these issues, but at the time nobody 
was interested.  Since then, the topic gets raised periodically, but 
there has never been anyone with enough of both interest and 
knowledge to put together a concrete proposal for overhauling 
platform strings on *nix platforms.

OS/X and Windows, OTOH, have had proposals implemented either in 
distutils or setuptools over the last few years.  (Distutils needs 
code to *distinguish* platforms (by changing the strings), but 
setuptools only needs special code to be able to tell when the 
running platform supports running something built with a different 
platform string.  So, additions of UCS build info to distutils would 
probably not affect setuptools; addition of gcc info might.)


From cournape at gmail.com  Mon Jul 26 19:51:37 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 27 Jul 2010 02:51:37 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4DC842.4020109@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>
	<4C4DC842.4020109@simplistix.co.uk>
Message-ID: <AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>

On Tue, Jul 27, 2010 at 2:39 AM, Chris Withers <chris at simplistix.co.uk> wrote:

> Such as between Ubuntu 8.04 and 10.04? ;-)

That should still work, they both use gcc 4.x (unless you depend on
C++, and then you are in for a fun ride...)

>>>
>>> How're people coping with this?
>>> What are the future plans in this area?
>>
>> If you need to follow non trivial ABI aspects, the current python
>> infrastructure
>> is too simplistic.
>
> One idea I've had is to have a separate index for each required combination
> and use layered --find-links= with easy_install to pick the right
> combination.

That's one of the numerous reason why the whole idea of embedding
metadata in the filename falls short once you go beyond trivial
issues. The combination alone makes it complicated very fast. Trying
to come up with such a scheme in python is foolish IMHO: the problem
is complicated, and nobody has been able to solve it in a general
manner anyway.

I would strongly look into system packages-based solutions unless you
really cannot use them (non root install). If you can't use system
packages, then look at how the big ones do it (mozilla, intel,
etc...). Be ready to spend weeks on the problem if you don't have the
expertise...

cheers,

David

From barry at python.org  Mon Jul 26 20:17:08 2010
From: barry at python.org (Barry Warsaw)
Date: Mon, 26 Jul 2010 14:17:08 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4DC004.8060705@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
Message-ID: <20100726141708.26a11706@heresy>

On Jul 26, 2010, at 06:04 PM, Chris Withers wrote:

>In addition to the UCS2/4 problems already described by MAL and which
>I've bumped into myself, I now have a problem with binary linux eggs
>where the GCC version doesn't match that of the system the egg is
>being installed on.
>
>Current egg metadata doesn't take either of these into account or even
>provide a way for the nature of the binary egg to be recorded.
>
>How're people coping with this?
>What are the future plans in this area?

I wonder if any distutils experts would care to comment on PEP 3149, and its
applicability to this problem?

http://www.python.org/dev/peps/pep-3149/

Is there any way this PEP can help?  Do you have any comments that I should
add to the PEP?

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100726/c51bc9e6/attachment.pgp>

From shimizukawa at gmail.com  Tue Jul 27 01:22:29 2010
From: shimizukawa at gmail.com (Takayuki Shimizukawa)
Date: Tue, 27 Jul 2010 08:22:29 +0900
Subject: [Distutils] `setup.py register` can't create PyPI account.
In-Reply-To: <4C4CB343.9010207@v.loewis.de>
References: <AANLkTinsZzK9U5EEaZBlKHuKwoyZEo8gaq7wRH_6tjMP@mail.gmail.com> 
	<4C4CB343.9010207@v.loewis.de>
Message-ID: <AANLkTinqH6ZkwR8kLW-vL+6=AC9HJiNm9Twh7DFp2H6q@mail.gmail.com>

2010/7/26 "Martin v. L?wis" <martin at v.loewis.de>:
>> I wasn't able to make an account in PyPI using `setup.py register`.
>>
>> http://pypi.python.org/pypi?:action=register_form require 'I agree'
>> checkbox, but `distutils/command/register.py` doesn't seem to send
>> a 'agree' form key/value to the PyPI server.
>>
>> This problem occurs in the major python versions (include 2.7).
>>
>> This introduced for PyPI site by
>> https://svn.python.org/packages/trunk/pypi/webui.py rev-690.
>
> Hi Takayuki,
>
> Georg Brandl has now fixed the problem in r823.
>
> Regards,
> Martin

I confirmed it.
Thanks!

--
Takayuki SHIMIZUKAWA

From pje at telecommunity.com  Tue Jul 27 03:26:05 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 26 Jul 2010 21:26:05 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <20100726141708.26a11706@heresy>
References: <4C4DC004.8060705@simplistix.co.uk>
	<20100726141708.26a11706@heresy>
Message-ID: <20100727012603.1524A3A40DF@sparrow.telecommunity.com>

At 02:17 PM 7/26/2010 -0400, Barry Warsaw wrote:
>I wonder if any distutils experts would care to comment on PEP 3149, and its
>applicability to this problem?
>
>http://www.python.org/dev/peps/pep-3149/
>
>Is there any way this PEP can help?

The d/m/u flags look like what's needed, *within* a given 
platform.  The overall platform definition (OS, processor, gcc, etc.) 
is where things are still hairy, though.  (Binary eggs are of course 
already tagged with Python major/minor versions, so it's only the 
OS/processor/etc. that remains an open issue for platform strings.)


From cournape at gmail.com  Tue Jul 27 06:43:57 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 27 Jul 2010 13:43:57 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <20100726141708.26a11706@heresy>
References: <4C4DC004.8060705@simplistix.co.uk>
	<20100726141708.26a11706@heresy>
Message-ID: <AANLkTinFFLeSk_1da+dUpGmdgt9L0NVyS6FTURzpR=eK@mail.gmail.com>

On Tue, Jul 27, 2010 at 3:17 AM, Barry Warsaw <barry at python.org> wrote:
> On Jul 26, 2010, at 06:04 PM, Chris Withers wrote:
>
>>In addition to the UCS2/4 problems already described by MAL and which
>>I've bumped into myself, I now have a problem with binary linux eggs
>>where the GCC version doesn't match that of the system the egg is
>>being installed on.
>>
>>Current egg metadata doesn't take either of these into account or even
>>provide a way for the nature of the binary egg to be recorded.
>>
>>How're people coping with this?
>>What are the future plans in this area?
>
> I wonder if any distutils experts would care to comment on PEP 3149, and its
> applicability to this problem?
>
> http://www.python.org/dev/peps/pep-3149/
>
> Is there any way this PEP can help? ?Do you have any comments that I should
> add to the PEP?

AFAIK, this PEP helps for ABI issues *within* one platform at one
given version. But this does not cope with the issue of
inter-distributions ABI (which I think is hopelessly intractable
unless you bundle almost everything, which is what everybody is doing
outside the system packaging system)

cheers,

David

From chris at simplistix.co.uk  Tue Jul 27 10:28:45 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 27 Jul 2010 09:28:45 +0100
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <20100726174219.4159C3A40D9@sparrow.telecommunity.com>
References: <4C4DC004.8060705@simplistix.co.uk>
	<20100726174219.4159C3A40D9@sparrow.telecommunity.com>
Message-ID: <4C4E98BD.5070803@simplistix.co.uk>

P.J. Eby wrote:
> Egg binaries aren't a great idea on Linux; 

If more packages were statically linked they would be :-/

> they were mainly intended for 
> Windows and Mac, where the architectures are uniform and working 
> compilers aren't just an apt-get or yum away.

On linux, it's the build rather than runtime dependencies that are the 
pain... Also, a lot of the scipy-ish packages (and lxml) often having 
confusing and brittle build requirements.

> (Ironically, this is a side effect of eggs being invented *before* 
> easy_install; if I'd thought of easy_install *first*, I might not've 
> bothered with eggs (as a distribution format) at all.  Certainly, sdists 
> don't add a lot of installation overhead except on compiler-less 
> platforms.)

Agree, where the build dependencies are simple :-/

> Incidentally, if you look way, way back in the distutils-sig archives, 
> you can see where I first raised the question of platform strings and 
> addressing some of these issues, but at the time nobody was interested.  

People are never interested, until they have the problem themselves or 
are in a position where they can bikeshed on a topic ;-)

> Since then, the topic gets raised periodically, but there has never been 
> anyone with enough of both interest and knowledge to put together a 
> concrete proposal for overhauling platform strings on *nix platforms.
> 

I lack on the latter and time for the former...

Chris


From chris at simplistix.co.uk  Tue Jul 27 10:36:29 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 27 Jul 2010 09:36:29 +0100
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>
References: <4C4DC004.8060705@simplistix.co.uk>	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>	<4C4DC842.4020109@simplistix.co.uk>
	<AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>
Message-ID: <4C4E9A8D.7080700@simplistix.co.uk>

David Cournapeau wrote:
> On Tue, Jul 27, 2010 at 2:39 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> 
>> Such as between Ubuntu 8.04 and 10.04? ;-)
> 
> That should still work, they both use gcc 4.x (unless you depend on
> C++, and then you are in for a fun ride...)

Chaco and wxPython, let the fun begin :-(
>> One idea I've had is to have a separate index for each required combination
>> and use layered --find-links= with easy_install to pick the right
>> combination.
> 
> That's one of the numerous reason why the whole idea of embedding
> metadata in the filename falls short once you go beyond trivial
> issues.

Indeed, but the other option requires a more complicated service to 
query. Being able to "serve" packages from a simple folder or from 
simple folder served via svn or Apache is a huge win.

> The combination alone makes it complicated very fast. Trying
> to come up with such a scheme in python is foolish IMHO: the problem
> is complicated, and nobody has been able to solve it in a general
> manner anyway.

I think that's overly pessemistic. What problems do you see with the 
multiple-find-links suggestion I made above?

> I would strongly look into system packages-based solutions unless you
> really cannot use them (non root install).

I pertty strongly disagree. In a heterogenous operating system 
environment, where that environment includes MacOS and Windows, trying 
to maintain separate os packages for each of the os packaging systems is 
a nightmare.

Working with sdists as much as possible with binary eggs thrown in where 
possible seems like the best way forward for me. What are the problems 
you see with that solution?

cheers,

Chris


From cournape at gmail.com  Tue Jul 27 12:14:55 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 27 Jul 2010 19:14:55 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4E9A8D.7080700@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>
	<4C4DC842.4020109@simplistix.co.uk>
	<AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>
	<4C4E9A8D.7080700@simplistix.co.uk>
Message-ID: <AANLkTinoWTjmu_sGqCPo5kyj5D50u8bDFpBtXNUr8S5Q@mail.gmail.com>

On Tue, Jul 27, 2010 at 5:36 PM, Chris Withers <chris at simplistix.co.uk> wrote:

>
> Indeed, but the other option requires a more complicated service to query.
> Being able to "serve" packages from a simple folder or from simple folder
> served via svn or Apache is a huge win.

I don't see how one preclude the other.

>
>> The combination alone makes it complicated very fast. Trying
>> to come up with such a scheme in python is foolish IMHO: the problem
>> is complicated, and nobody has been able to solve it in a general
>> manner anyway.
>
> I think that's overly pessemistic. What problems do you see with the
> multiple-find-links suggestion I made above?

It quickly becomes intractable once you have complex requirements.

>
>> I would strongly look into system packages-based solutions unless you
>> really cannot use them (non root install).
>
> I pertty strongly disagree. In a heterogenous operating system environment,
> where that environment includes MacOS and Windows, trying to maintain
> separate os packages for each of the os packaging systems is a nightmare.

I don't see how egg changes anything there compared to rpm/deb to that
issue. At least, rpm/deb and the infrastructure around have been
designed to somewhat deal with those issues, whereas egg clearly was
not.

EPD can use eggs because they pretty much control the whole stack from
python, hence significantly reducing the issues of dependencies
issues.

> Working with sdists as much as possible with binary eggs thrown in where
> possible seems like the best way forward for me. What are the problems you
> see with that solution?

The numerous issues of dealing with ABI issues on Linux are well
known. First there is UCS2 vs UCS4 for python extensions, then there
is gcc versions and stdlib versions for C++, then you will also have
issues with gfortran vs g77 which do not have compatible ABI either,
etc...

cheers,

David

From barry at python.org  Tue Jul 27 16:22:43 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 27 Jul 2010 10:22:43 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <20100727012603.1524A3A40DF@sparrow.telecommunity.com>
References: <4C4DC004.8060705@simplistix.co.uk>
	<20100726141708.26a11706@heresy>
	<20100727012603.1524A3A40DF@sparrow.telecommunity.com>
Message-ID: <20100727102243.269aa7a9@heresy>

On Jul 26, 2010, at 09:26 PM, P.J. Eby wrote:

>At 02:17 PM 7/26/2010 -0400, Barry Warsaw wrote:
>>I wonder if any distutils experts would care to comment on PEP 3149,
>>and its applicability to this problem?
>>
>>http://www.python.org/dev/peps/pep-3149/
>>
>>Is there any way this PEP can help?
>
>The d/m/u flags look like what's needed, *within* a given platform.
>The overall platform definition (OS, processor, gcc, etc.) is where
>things are still hairy, though.  (Binary eggs are of course already
>tagged with Python major/minor versions, so it's only the
>OS/processor/etc. that remains an open issue for platform strings.)

I'm disinclined to expand PEP 3149 to include other platform designations.
Ronald brought this up on python-dev regarding OS X, but it adds complexity
that isn't necessary for my particular use case.  I'm in favor of keeping the
spec narrow - unless you feel otherwise, and someone comes up with an elegant
way to support the egg use case without making the file names really long and
ugly.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100727/4c5ecbd1/attachment.pgp>

From barry at python.org  Tue Jul 27 16:25:24 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 27 Jul 2010 10:25:24 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <AANLkTinFFLeSk_1da+dUpGmdgt9L0NVyS6FTURzpR=eK@mail.gmail.com>
References: <4C4DC004.8060705@simplistix.co.uk>
	<20100726141708.26a11706@heresy>
	<AANLkTinFFLeSk_1da+dUpGmdgt9L0NVyS6FTURzpR=eK@mail.gmail.com>
Message-ID: <20100727102524.4ce0f147@heresy>

On Jul 27, 2010, at 01:43 PM, David Cournapeau wrote:

>> I wonder if any distutils experts would care to comment on PEP 3149,
>> and its applicability to this problem?
>>
>> http://www.python.org/dev/peps/pep-3149/
>>
>> Is there any way this PEP can help? ?Do you have any comments that I
>> should add to the PEP?
>
>AFAIK, this PEP helps for ABI issues *within* one platform at one
>given version. But this does not cope with the issue of
>inter-distributions ABI (which I think is hopelessly intractable
>unless you bundle almost everything, which is what everybody is doing
>outside the system packaging system)

Agreed.
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100727/9a2199a4/attachment.pgp>

From pje at telecommunity.com  Tue Jul 27 17:58:49 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 27 Jul 2010 11:58:49 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <20100727102243.269aa7a9@heresy>
References: <4C4DC004.8060705@simplistix.co.uk>
	<20100726141708.26a11706@heresy>
	<20100727012603.1524A3A40DF@sparrow.telecommunity.com>
	<20100727102243.269aa7a9@heresy>
Message-ID: <20100727155849.4AAF03A4093@sparrow.telecommunity.com>

At 10:22 AM 7/27/2010 -0400, Barry Warsaw wrote:
>On Jul 26, 2010, at 09:26 PM, P.J. Eby wrote:
>
> >At 02:17 PM 7/26/2010 -0400, Barry Warsaw wrote:
> >>I wonder if any distutils experts would care to comment on PEP 3149,
> >>and its applicability to this problem?
> >>
> >>http://www.python.org/dev/peps/pep-3149/
> >>
> >>Is there any way this PEP can help?
> >
> >The d/m/u flags look like what's needed, *within* a given platform.
> >The overall platform definition (OS, processor, gcc, etc.) is where
> >things are still hairy, though.  (Binary eggs are of course already
> >tagged with Python major/minor versions, so it's only the
> >OS/processor/etc. that remains an open issue for platform strings.)
>
>I'm disinclined to expand PEP 3149 to include other platform designations.

To be clear, I wasn't asking for it to.  I was just saying that egg 
platform strings could adopt the d/m/u flags convention, but it 
wasn't in itself sufficient for getting the egg platform string mess 
sorted out on non-Windows/non-OSX platforms.


>Ronald brought this up on python-dev regarding OS X, but it adds complexity
>that isn't necessary for my particular use case.  I'm in favor of keeping the
>spec narrow - unless you feel otherwise, and someone comes up with an elegant
>way to support the egg use case without making the file names really long and
>ugly.

Nope, I don't see a need here.  If an egg platform string is 
involved, it means that the egg's contents are already segregated, 
and the platform info then needn't be duplicated on the .so files within it. 


From barry at python.org  Tue Jul 27 21:03:32 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 27 Jul 2010 15:03:32 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <20100727155849.4AAF03A4093@sparrow.telecommunity.com>
References: <4C4DC004.8060705@simplistix.co.uk>
	<20100726141708.26a11706@heresy>
	<20100727012603.1524A3A40DF@sparrow.telecommunity.com>
	<20100727102243.269aa7a9@heresy>
	<20100727155849.4AAF03A4093@sparrow.telecommunity.com>
Message-ID: <20100727150332.6c7f67a3@heresy>

On Jul 27, 2010, at 11:58 AM, P.J. Eby wrote:

>To be clear, I wasn't asking for it to.  I was just saying that egg
>platform strings could adopt the d/m/u flags convention, but it wasn't
>in itself sufficient for getting the egg platform string mess sorted
>out on non-Windows/non-OSX platforms.

Gotcha.  Yes, it makes sense to adopt the same flag convention when there same
semantics are involved.

>>Ronald brought this up on python-dev regarding OS X, but it adds
>>complexity that isn't necessary for my particular use case.  I'm in
>>favor of keeping the spec narrow - unless you feel otherwise, and
>>someone comes up with an elegant way to support the egg use case
>>without making the file names really long and ugly.
>
>Nope, I don't see a need here.  If an egg platform string is involved,
>it means that the egg's contents are already segregated, and the
>platform info then needn't be duplicated on the .so files within it. 

+1

Thanks,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100727/986e4770/attachment-0001.pgp>

From mailing at franzoni.eu  Tue Jul 27 18:29:47 2010
From: mailing at franzoni.eu (Alan Franzoni)
Date: Tue, 27 Jul 2010 18:29:47 +0200
Subject: [Distutils] Force easy_install to use .tar.gz (sdist) instead of
	bdist/bdist_egg
Message-ID: <i2n1hs$jb1$1@dough.gmane.org>

Hello,
like other people, I'm experiencing some problems with binary dists and
eggs across different linux distros. Is it possibile to tell
easy_install or pip just to ignore any egg or bdist which can be found
on the index and just use the sdist? And is there any way to integrate
such behaviour with zc.buildout automatic dep fetching?

Thank you!

Alan Franzoni


From pje at telecommunity.com  Tue Jul 27 22:38:49 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 27 Jul 2010 16:38:49 -0400
Subject: [Distutils] Force easy_install to use .tar.gz (sdist) instead
 of bdist/bdist_egg
In-Reply-To: <i2n1hs$jb1$1@dough.gmane.org>
References: <i2n1hs$jb1$1@dough.gmane.org>
Message-ID: <20100727203900.5445F3A4093@sparrow.telecommunity.com>

At 06:29 PM 7/27/2010 +0200, Alan Franzoni wrote:
>Hello,
>like other people, I'm experiencing some problems with binary dists and
>eggs across different linux distros. Is it possibile to tell
>easy_install or pip just to ignore any egg or bdist which can be found
>on the index and just use the sdist?

"easy_install -eb tmpdir requirement" will download and unpack source 
(or check out from svn:) to tmpdir/projectname (with projectname in 
all-lowercase).


>  And is there any way to integrate
>such behaviour with zc.buildout automatic dep fetching?

Probably.  If there isn't an option to force building from source, 
you can probably create your own recipe/plugin to do it.


From doko at ubuntu.com  Wed Jul 28 01:55:18 2010
From: doko at ubuntu.com (Matthias Klose)
Date: Wed, 28 Jul 2010 01:55:18 +0200
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4DC004.8060705@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
Message-ID: <4C4F71E6.6000903@ubuntu.com>

On 26.07.2010 19:04, Chris Withers wrote:
> Hi All,
>
> In addition to the UCS2/4 problems already described by MAL and which
> I've bumped into myself, I now have a problem with binary linux eggs
> where the GCC version doesn't match that of the system the egg is being
> installed on.

why would this be needed? Both the C ABI and C++ ABI didn't change for years, at 
least on the common ix86 architectures. There were corner cases on some 
architectures, but I doubt that anybody did build eggs for those.

   Matthias

From cournape at gmail.com  Wed Jul 28 02:42:38 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 28 Jul 2010 09:42:38 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4F71E6.6000903@ubuntu.com>
References: <4C4DC004.8060705@simplistix.co.uk> <4C4F71E6.6000903@ubuntu.com>
Message-ID: <AANLkTikGUjJKT5aECH2kV1vgF1rqdWsGdoHTm+4ch2it@mail.gmail.com>

On Wed, Jul 28, 2010 at 8:55 AM, Matthias Klose <doko at ubuntu.com> wrote:
> On 26.07.2010 19:04, Chris Withers wrote:
>>
>> Hi All,
>>
>> In addition to the UCS2/4 problems already described by MAL and which
>> I've bumped into myself, I now have a problem with binary linux eggs
>> where the GCC version doesn't match that of the system the egg is being
>> installed on.
>
> why would this be needed? Both the C ABI and C++ ABI didn't change for
> years, at least on the common ix86 architectures. There were corner cases on
> some architectures, but I doubt that anybody did build eggs for those.

The Fortran one did, and given that the OP seems interested in the
scientific python toolstack, that will cause headache. It certainly
has and (still does) caused a lot of headache for the scipy community
(and we do not distribute binaries for windows),

cheers,

David

From cournape at gmail.com  Wed Jul 28 02:43:09 2010
From: cournape at gmail.com (David Cournapeau)
Date: Wed, 28 Jul 2010 09:43:09 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <AANLkTikGUjJKT5aECH2kV1vgF1rqdWsGdoHTm+4ch2it@mail.gmail.com>
References: <4C4DC004.8060705@simplistix.co.uk> <4C4F71E6.6000903@ubuntu.com>
	<AANLkTikGUjJKT5aECH2kV1vgF1rqdWsGdoHTm+4ch2it@mail.gmail.com>
Message-ID: <AANLkTimtddCzG3_vVsD8vNg9W3SA47pkUNaBhboMKh=H@mail.gmail.com>

On Wed, Jul 28, 2010 at 9:42 AM, David Cournapeau <cournape at gmail.com> wrote:

> The Fortran one did, and given that the OP seems interested in the
> scientific python toolstack, that will cause headache. It certainly
> has and (still does) caused a lot of headache for the scipy community
> (and we do not distribute binaries for windows)

I meant we do not distribute binaries for *Linux*, of course,

David

From pje at telecommunity.com  Wed Jul 28 20:23:56 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 28 Jul 2010 14:23:56 -0400
Subject: [Distutils] Force easy_install to use .tar.gz (sdist) instead
 of bdist/bdist_egg
In-Reply-To: <4C4FEE26.90305@goebel-consult.de>
References: <i2n1hs$jb1$1@dough.gmane.org>
	<20100727203900.5445F3A4093@sparrow.telecommunity.com>
	<4C4FEE26.90305@goebel-consult.de>
Message-ID: <20100728182358.12A963A4093@sparrow.telecommunity.com>

At 10:45 AM 7/28/2010 +0200, Hartmut Goebel wrote:
>Am 27.07.2010 22:38, schrieb P.J. Eby:
>
> > "easy_install -eb tmpdir requirement" will download and unpack source
> > (or check out from svn:) to tmpdir/projectname (with projectname in
> > all-lowercase).
>
>Unfortunately this does not install from source.

"easy_install -eb tmpdir requirement && easy_install 
tmpdir/projectnameinalllowercase" will, though.  (As will 
"easy_install -eb tmpdir requirement && cd tmpdir/projectnamelower && 
python setup.py install", though this latter choice may or may not do 
an egg-based install.)


From tseaver at palladion.com  Wed Jul 28 22:37:27 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 28 Jul 2010 16:37:27 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C4DC004.8060705@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
Message-ID: <i2q4e8$ip5$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Withers wrote:
> Hi All,
> 
> In addition to the UCS2/4 problems already described by MAL and which 
> I've bumped into myself, I now have a problem with binary linux eggs 
> where the GCC version doesn't match that of the system the egg is being 
> installed on.

GCC version shouldn't matter.  It is barely possible that libc versions
might.

> Current egg metadata doesn't take either of these into account or even 
> provide a way for the nature of the binary egg to be recorded.
> 
> How're people coping with this?

By never, ever, ever distributing binary eggs, especially for Linux.  An
sdist is nearly always consumable there, with the exception of
deliberately damaged (no tools) lockdown environments:  in such
environments, the dungeonmaster knows exactly which libC / Python is
targeted, and can build / install the binary eggs (privately, please!).

> What are the future plans in this area?

Denying-a-problem-with-the-status-quo'ly ;),


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkxQlQMACgkQ+gerLs4ltQ6NggCgj7kyXbKKIIO54wUZXTqb4KJQ
OO0An3HK5XxMXWMhihetnKvMTBUghFR9
=UXos
-----END PGP SIGNATURE-----


From leorochael at gmail.com  Thu Jul 29 00:44:10 2010
From: leorochael at gmail.com (Leonardo Rochael Almeida)
Date: Wed, 28 Jul 2010 19:44:10 -0300
Subject: [Distutils] buildout: build options for dependencies of recipes
Message-ID: <AANLkTikC6ETOPYdHAfq1Wf4bMD+1w7PakmjqS-Ke2hMS@mail.gmail.com>

Hi all

The zc.recipe.egg:custom recipe allows the specification of build
options for a custom egg. But what do we do if we want to specify
custom build options for an egg that is a dependency of a recipe (or
perhaps the recipe itself)?

Case in point

We have a recipe, erp5.recipe.mysqldatabase, that uses the
MySQL-python. However, since we have a non-distribution installation
of MySQL (we need to patch it with the Senna full text index), we need
to pass compilation instructions to MySQL-python so that it actually
finds the correct MySQL include and lib directories, which we do
through zc.recipe.egg:custom.

This works for buildout parts with recipes based on zc.recipe.egg
(e.g. collective.recipe.zope2instance), even if some of the eggs
mentioned depend on MySQL-python, as long as the zc.recipe.egg:custom
part for MySQL-python runs first.

But if the recipe itself depends on MySQL-python, we don't get the
opportunity to pass custom build options to MySQL-python, since
buildout will try to satisfy the recipe dependencies of all parts even
before installing the zc.recipe.egg:custom part.

zc.buildout has APIs [1] [2] for passing custom build options for
eggs, but appart from zc.recipe.egg:custom, I couldn't find any way to
use these APIs for dependencies of recipes.

[1] http://pypi.python.org/pypi/zc.buildout#handling-custom-build-options-for-extensions-provided-in-source-distributions
[2] http://pypi.python.org/pypi/zc.buildout#handling-custom-build-options-for-extensions-in-develop-eggs

Since we can specify versions for eggs by specifying a section with
version information, I was hoping that we could also specify build
options somehow. Since there are many pieces of information (including
environment variables). I think that we'd need a whole section for
each egg. Something on the lines of:

  [buildout]
  build-options-sufix = -options
  ...

  [MySQL-python-options]
  # options like the ones for the zc.recipe.egg:custom recipe

Is there something like this available, and I just missed it?
Can something like this be implemented as a buildout extension?

Cheers,

Leo

PS: Conversely, it would also be nice to be able to specify different
"versions" sections per zc.recipe.egg part instead of a single global
one, exactly so that we can compare different version combinations
with a single buildout.

From hltbra at gmail.com  Thu Jul 29 16:27:05 2010
From: hltbra at gmail.com (Hugo Lopes Tavares)
Date: Thu, 29 Jul 2010 11:27:05 -0300
Subject: [Distutils] Force easy_install to use .tar.gz (sdist) instead
	of bdist/bdist_egg
In-Reply-To: <20100728182358.12A963A4093@sparrow.telecommunity.com>
References: <i2n1hs$jb1$1@dough.gmane.org>
	<20100727203900.5445F3A4093@sparrow.telecommunity.com>
	<4C4FEE26.90305@goebel-consult.de>
	<20100728182358.12A963A4093@sparrow.telecommunity.com>
Message-ID: <AANLkTinGSHPJ3gSg9Dyim+LgkrfZ-rgOT39UOzTekiZA@mail.gmail.com>

Pip always installs from source, but I don't know how you could add
this behavior to zc.buildout.

On Wed, Jul 28, 2010 at 3:23 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 10:45 AM 7/28/2010 +0200, Hartmut Goebel wrote:
>>
>> Am 27.07.2010 22:38, schrieb P.J. Eby:
>>
>> > "easy_install -eb tmpdir requirement" will download and unpack source
>> > (or check out from svn:) to tmpdir/projectname (with projectname in
>> > all-lowercase).
>>
>> Unfortunately this does not install from source.
>
> "easy_install -eb tmpdir requirement && easy_install
> tmpdir/projectnameinalllowercase" will, though. ?(As will "easy_install -eb
> tmpdir requirement && cd tmpdir/projectnamelower && python setup.py
> install", though this latter choice may or may not do an egg-based install.)
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From barry at python.org  Thu Jul 29 17:16:08 2010
From: barry at python.org (Barry Warsaw)
Date: Thu, 29 Jul 2010 11:16:08 -0400
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <i2q4e8$ip5$1@dough.gmane.org>
References: <4C4DC004.8060705@simplistix.co.uk> <i2q4e8$ip5$1@dough.gmane.org>
Message-ID: <20100729111608.56976d61@heresy>

On Jul 28, 2010, at 04:37 PM, Tres Seaver wrote:

>By never, ever, ever distributing binary eggs, especially for Linux.
>An sdist is nearly always consumable there, with the exception of
>deliberately damaged (no tools) lockdown environments:  in such
>environments, the dungeonmaster knows exactly which libC / Python is
>targeted, and can build / install the binary eggs (privately, please!).

Right, and IME, admins of those locked down systems aren't about to install
*anything* from the Cheeseshop anyway. :)  They really really prefer
distribution packages (well, on platforms that have a packaging system ;).

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100729/26e76aae/attachment.pgp>

From reinout at vanrees.org  Fri Jul 30 10:05:09 2010
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 30 Jul 2010 10:05:09 +0200
Subject: [Distutils] buildout and issues with dependencies and patch.
In-Reply-To: <AANLkTingccelEkjoe9KeDGtEJ3BulI9RB0CYfts4-Czc@mail.gmail.com>
References: <7BA0A3A9-1149-41FB-AA37-974AF2D4BE2B@linovia.com>
	<AANLkTingccelEkjoe9KeDGtEJ3BulI9RB0CYfts4-Czc@mail.gmail.com>
Message-ID: <i2u13m$6a5$1@dough.gmane.org>

On 07/06/2010 03:21 PM, Jim Fulton wrote:
> On Mon, Jul 5, 2010 at 11:30 AM, Xavier Ordoquy<xordoquy at linovia.com>  wrote:
>>
>> Does someone know a way to get numpy eggs prepend to the paths so
> that matplotlib can detect it ?
>
> matplotlib is problematic for buildout due to the introspection it
> does.  I haven't found a good solution.  What I've done in the past is
> to make a not-so-clean Python (or virtualenv) that has numpy installed
> and then use buildout with that to install matplotlib.

I've also installed numpy globally ("apt-get install .....").  I'm 
currently experimenting with a recipe that first looks up several named 
eggs globally.  Only if they're not available yet, does it install them 
regularly through buildout.  So something like:

[buildout]
...
parts =
     sysegg
     ...

[sysegg]
recipe = osc.recipe.sysegg
force-sysegg =
eggs =
     numpy


It seems to work quite well.  I'm hoping it helps me with the packages 
that install just fine on linux and not on windows or vice versa.  You 
only have to install global versions of just the once that fail, that way.



Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"


From cz at gocept.com  Fri Jul 30 10:17:09 2010
From: cz at gocept.com (Christian Zagrodnick)
Date: Fri, 30 Jul 2010 10:17:09 +0200
Subject: [Distutils] [buildout] extending a .cfg supplied by another
	package
References: <4BEA9C69.8060602@simplistix.co.uk>
	<AANLkTin2wHf2bRi4L0DpbVHutx7LaTWtJqeKuxpPbIid@mail.gmail.com>
Message-ID: <i2u1q4$8i4$1@dough.gmane.org>

On 2010-05-12 21:51:19 +0200, Jim Fulton said:

> On Wed, May 12, 2010 at 8:17 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> Hi All,
>> 
>> I'd like to be able to do:
>> 
>> [buildout]
>> extends=some.package:aconfig.cfg
> 
> That's an interesting idea.
> 
>> ...kinda like you can with templates in BFG, which I believe uses pkg_tools
>> to do the hard work.
>> 
>> What're the chances of that happening?
> 
> Low, in the short term. A good first step would be to work out a
> somewhat detailed proposal including:
> 
> - Descriptions of specific situations where this would solve a
>   problem, with specific examples of how the proposed meachanism would
>   be applied.
> 
> - A syntax proposal.  It has to address distinguishing file paths from
>   urls from these new things. I suspect these should be expressed as
>   URLs, e.g.:
> 
>      project://some.project/aconfig.cfg

I propose egg://<requirement string>/<path in egg>.

For example egg://some.package=0.6/foo/file.cfg would basically return 
pkg_resources.resource_string('some.package', 'foo/file.cfg').

> 
> I'll note that I suspect you can do this now using a buildout
> extension that installs a new URL handler in urtllib2.

That doesn't work for extends= because extends evaluated first to build 
the composed configuration. Extensions are loaded after that.

I don't see a useful way to not integrating the egg://-handler to 
buildout directly.

Are there chances this will integrated to buildout when we try that on 
a branch?

Regards,
-- 
Christian Zagrodnick ? cz at gocept.com
gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany
http://gocept.com ? tel +49 345 1229889 4 ? fax +49 345 1229889 1
Zope and Plone consulting and development



From cz at gocept.com  Fri Jul 30 14:44:28 2010
From: cz at gocept.com (Christian Zagrodnick)
Date: Fri, 30 Jul 2010 14:44:28 +0200
Subject: [Distutils] [buildout] extending a .cfg supplied by another
	package
References: <4BEA9C69.8060602@simplistix.co.uk>
	<AANLkTin2wHf2bRi4L0DpbVHutx7LaTWtJqeKuxpPbIid@mail.gmail.com>
	<i2u1q4$8i4$1@dough.gmane.org>
Message-ID: <i2uhfb$t4h$1@dough.gmane.org>

On 2010-07-30 10:17:09 +0200, Christian Zagrodnick said:

> On 2010-05-12 21:51:19 +0200, Jim Fulton said:
> 
>> On Wed, May 12, 2010 at 8:17 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>>> Hi All,
> 
>>> I'd like to be able to do:
> 
>>> [buildout]
>>> extends=some.package:aconfig.cfg
> 
>> That's an interesting idea.
> 
>>> ...kinda like you can with templates in BFG, which I believe uses pkg_tools
>>> to do the hard work.
> 
>>> What're the chances of that happening?
> 
>> Low, in the short term. A good first step would be to work out a
>> somewhat detailed proposal including:
> 
>> - Descriptions of specific situations where this would solve a
>> problem, with specific examples of how the proposed meachanism would
>> be applied.
> 
>> - A syntax proposal.  It has to address distinguishing file paths from
>> urls from these new things. I suspect these should be expressed as
>> URLs, e.g.:
> 
>> project://some.project/aconfig.cfg
> 
> I propose egg://<requirement string>/<path in egg>.
> 
> For example egg://some.package=0.6/foo/file.cfg would basically return
> pkg_resources.resource_string('some.package', 'foo/file.cfg').
> 
> 
>> I'll note that I suspect you can do this now using a buildout
>> extension that installs a new URL handler in urtllib2.
> 
> That doesn't work for extends= because extends evaluated first to build
> the composed configuration. Extensions are loaded after that.
> 
> I don't see a useful way to not integrating the egg://-handler to
> buildout directly.
> 
> Are there chances this will integrated to buildout when we try that on
> a branch?

Actually I figured that an egg://-handler doesn't help with versions 
very much. I try something else and let you know when there is 
something interesting.

-- 
Christian Zagrodnick ? cz at gocept.com
gocept gmbh & co. kg ? forsterstra?e 29 ? 06112 halle (saale) ? germany
http://gocept.com ? tel +49 345 1229889 4 ? fax +49 345 1229889 1
Zope and Plone consulting and development



From jim at zope.com  Fri Jul 30 15:33:17 2010
From: jim at zope.com (Jim Fulton)
Date: Fri, 30 Jul 2010 09:33:17 -0400
Subject: [Distutils] [buildout] extending a .cfg supplied by another
	package
In-Reply-To: <i2u1q4$8i4$1@dough.gmane.org>
References: <4BEA9C69.8060602@simplistix.co.uk>
	<AANLkTin2wHf2bRi4L0DpbVHutx7LaTWtJqeKuxpPbIid@mail.gmail.com> 
	<i2u1q4$8i4$1@dough.gmane.org>
Message-ID: <AANLkTi=+cAHg=6Mhw3+cCP5NuHWopGcsqwYkWLuqC+pt@mail.gmail.com>

On Fri, Jul 30, 2010 at 4:17 AM, Christian Zagrodnick <cz at gocept.com> wrote:
> On 2010-05-12 21:51:19 +0200, Jim Fulton said:
>
>> On Wed, May 12, 2010 at 8:17 AM, Chris Withers <chris at simplistix.co.uk>
...

> I don't see a useful way to not integrating the egg://-handler to buildout
> directly.

I have no confidence in my ability to interpret that double negative.

> Are there chances this will integrated to buildout when we try that on a
> branch?

Not sure what you mean.  If you get this working on a branch,
I'm happy to review and, if agreeable, merge it.

Note that I don't intend to do anything until after 1.5 lands.

On Fri, Jul 30, 2010 at 8:44 AM, Christian Zagrodnick <cz at gocept.com> wrote:
...
> Actually I figured that an egg://-handler doesn't help with versions very
> much. I try something else and let you know when there is something
> interesting.

I don't know what you're trying to say here.

Jim

-- 
Jim Fulton

From jim at zope.com  Fri Jul 30 15:37:16 2010
From: jim at zope.com (Jim Fulton)
Date: Fri, 30 Jul 2010 09:37:16 -0400
Subject: [Distutils] buildout 2
Message-ID: <AANLkTikp2PE+HhvLz-o=XVTvvp63kj5u916DDbSVjjRo@mail.gmail.com>

FYI.

After 1.5 lands and the dust settles, I intend to look at refactoring
buildout pretty significantly, primarily to make maintenance simpler.

Jim

--
Jim Fulton

From chris at simplistix.co.uk  Fri Jul 30 17:37:58 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 30 Jul 2010 16:37:58 +0100
Subject: [Distutils] Announcing buildout_versions 1.0
Message-ID: <4C52F1D6.8070506@simplistix.co.uk>

Hi All,

I'm pleased to announce the first release of buildout_versions.

This is my take on buildout.dumppickedversions in that it's purpose is 
to make the user of a buildout aware if any package versions have been 
picked by buildout rather than specified by the buildout configuration.

It has two important differences:

- if no versions need to be picked, it generates no output

- if you specify recording of picked versions to a file, that file is 
only ever appended to, not overwritten.

The PyPI page is here:
http://pypi.python.org/pypi/buildout_versions

The documentation is here:
http://packages.python.org/buildout_versions

This extensions is also fully tested. If you have any problems or 
suggestions, please let me know on this list!

cheers,

Chris


From chris at simplistix.co.uk  Fri Jul 30 17:40:11 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 30 Jul 2010 16:40:11 +0100
Subject: [Distutils] buildout 2
In-Reply-To: <AANLkTikp2PE+HhvLz-o=XVTvvp63kj5u916DDbSVjjRo@mail.gmail.com>
References: <AANLkTikp2PE+HhvLz-o=XVTvvp63kj5u916DDbSVjjRo@mail.gmail.com>
Message-ID: <4C52F25B.2020302@simplistix.co.uk>

Jim Fulton wrote:
> After 1.5 lands and the dust settles, I intend to look at refactoring
> buildout pretty significantly, primarily to make maintenance simpler.

Can I put in a plea to make testing extensions and recipes easier?

It'd be nice not to have to do the:

     zc.buildout.testing.install('zc.recipe.egg',test)

..dance, along with the unpredicable appeare of the "Couldn't find index 
page" lines in sample output.

cheers,

Chris


From chris at simplistix.co.uk  Fri Jul 30 18:11:09 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 30 Jul 2010 17:11:09 +0100
Subject: [Distutils] Announcing buildout-versions 1.1
In-Reply-To: <4C52F1D6.8070506@simplistix.co.uk>
References: <4C52F1D6.8070506@simplistix.co.uk>
Message-ID: <4C52F99D.1070701@simplistix.co.uk>

Chris Withers wrote:
> Hi All,
> 
> I'm pleased to announce the first release of buildout_versions.

After having some trouble with a package with an underscore in it's 
name, I've renamed it to buildout-versions and done a 1.1 release :-(

The PyPI page is now here:
http://pypi.python.org/pypi/buildout-versions

The documentation is now here:
http://packages.python.org/buildout-versions

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Sat Jul 31 18:34:35 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 31 Jul 2010 17:34:35 +0100
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <AANLkTinoWTjmu_sGqCPo5kyj5D50u8bDFpBtXNUr8S5Q@mail.gmail.com>
References: <4C4DC004.8060705@simplistix.co.uk>	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>	<4C4DC842.4020109@simplistix.co.uk>	<AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>	<4C4E9A8D.7080700@simplistix.co.uk>
	<AANLkTinoWTjmu_sGqCPo5kyj5D50u8bDFpBtXNUr8S5Q@mail.gmail.com>
Message-ID: <4C54509B.80501@simplistix.co.uk>

David Cournapeau wrote:
> On Tue, Jul 27, 2010 at 5:36 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> 
>> Indeed, but the other option requires a more complicated service to query.
>> Being able to "serve" packages from a simple folder or from simple folder
>> served via svn or Apache is a huge win.
> 
> I don't see how one preclude the other.

How would you serve your proposed "rich" environment from Apache?

>>> The combination alone makes it complicated very fast. Trying
>>> to come up with such a scheme in python is foolish IMHO: the problem
>>> is complicated, and nobody has been able to solve it in a general
>>> manner anyway.
>> I think that's overly pessemistic. What problems do you see with the
>> multiple-find-links suggestion I made above?
> 
> It quickly becomes intractable once you have complex requirements.

Again, I think you're being overly pessimistic. Please can you give an 
actual example?

> I don't see how egg changes anything there compared to rpm/deb to that
> issue. At least, rpm/deb and the infrastructure around have been
> designed to somewhat deal with those issues, whereas egg clearly was
> not.

rpm/deb focus only on their own operating system. They don't help with 
Windows or MacOS. Eggs work the same on all platforms, from the clients 
perspective, it's just a case of making the right eggs available that 
appears to be problematic.

> EPD can use eggs because they pretty much control the whole stack from
> python, hence significantly reducing the issues of dependencies
> issues.

I don't follow. EPD uses a whole host of dependencies that are non-python...

>> Working with sdists as much as possible with binary eggs thrown in where
>> possible seems like the best way forward for me. What are the problems you
>> see with that solution?
> 
> The numerous issues of dealing with ABI issues on Linux are well
> known. First there is UCS2 vs UCS4 for python extensions, then there
> is gcc versions and stdlib versions for C++, then you will also have
> issues with gfortran vs g77 which do not have compatible ABI either,
> etc...

Indeed, but as I said before, this is a constrained environment.
Ubuntu 8.04 or 10.04, each with a controllable list of installed 
packages. With Windows and MacOSX, python packagers seem to go the route 
of statically linking anyway...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Sat Jul 31 18:38:01 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 31 Jul 2010 17:38:01 +0100
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <i2q4e8$ip5$1@dough.gmane.org>
References: <4C4DC004.8060705@simplistix.co.uk> <i2q4e8$ip5$1@dough.gmane.org>
Message-ID: <4C545169.8020901@simplistix.co.uk>

Tres Seaver wrote:
> 
> GCC version shouldn't matter.  It is barely possible that libc versions
> might.

Practical experience on trying to migrate from Ubuntu 8.04 to 10.04 
suggests both matter with the common scipy stack.

> By never, ever, ever distributing binary eggs, especially for Linux. 

That's fine in a world without python packages with C and Fortran 
extensions that are a royal PITA to compile. (fragile much?!)

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Sat Jul 31 18:38:49 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 31 Jul 2010 17:38:49 +0100
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <20100729111608.56976d61@heresy>
References: <4C4DC004.8060705@simplistix.co.uk> <i2q4e8$ip5$1@dough.gmane.org>
	<20100729111608.56976d61@heresy>
Message-ID: <4C545199.9000004@simplistix.co.uk>

Barry Warsaw wrote:
> Right, and IME, admins of those locked down systems aren't about to install
> *anything* from the Cheeseshop anyway. :)  They really really prefer
> distribution packages (well, on platforms that have a packaging system ;).

The specific use case I have would involve an internal "egg server" 
accessed by way of --find-links.

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From cournape at gmail.com  Sat Jul 31 18:51:59 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 1 Aug 2010 01:51:59 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C54509B.80501@simplistix.co.uk>
References: <4C4DC004.8060705@simplistix.co.uk>
	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>
	<4C4DC842.4020109@simplistix.co.uk>
	<AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>
	<4C4E9A8D.7080700@simplistix.co.uk>
	<AANLkTinoWTjmu_sGqCPo5kyj5D50u8bDFpBtXNUr8S5Q@mail.gmail.com>
	<4C54509B.80501@simplistix.co.uk>
Message-ID: <AANLkTimx0aLJpwpBossZehSzts07=wd20cYHFw47Hr8a@mail.gmail.com>

On Sun, Aug 1, 2010 at 1:34 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> David Cournapeau wrote:
>>
>> On Tue, Jul 27, 2010 at 5:36 PM, Chris Withers <chris at simplistix.co.uk>
>> wrote:
>>
>>> Indeed, but the other option requires a more complicated service to
>>> query.
>>> Being able to "serve" packages from a simple folder or from simple folder
>>> served via svn or Apache is a huge win.
>>
>> I don't see how one preclude the other.
>
> How would you serve your proposed "rich" environment from Apache?

Debian repositories are mostly purely file-based + a few metadata for
example. I mean, it is not like this issue have not been tackled for
*decades*....

>
>>>> The combination alone makes it complicated very fast. Trying
>>>> to come up with such a scheme in python is foolish IMHO: the problem
>>>> is complicated, and nobody has been able to solve it in a general
>>>> manner anyway.
>>>
>>> I think that's overly pessemistic. What problems do you see with the
>>> multiple-find-links suggestion I made above?
>>
>> It quickly becomes intractable once you have complex requirements.
>
> Again, I think you're being overly pessimistic. Please can you give an
> actual example?

Well, you do what you want from my suggestion, but I happen to know
extremely well the packages and the issues you are tackling :)

The issue is painstakingly obvious: you have to deal with N1 python
version, N2 C++ ABIs, N3 Fortran ABIs, so you end up having an
exponential explosion of situations.

>
>> I don't see how egg changes anything there compared to rpm/deb to that
>> issue. At least, rpm/deb and the infrastructure around have been
>> designed to somewhat deal with those issues, whereas egg clearly was
>> not.
>
> rpm/deb focus only on their own operating system. They don't help with
> Windows or MacOS. Eggs work the same on all platforms, from the clients
> perspective, it's just a case of making the right eggs available that
> appears to be problematic.

But egg or rpm/deb is the least of your issue here... The problem is
to make a set of binaries which work everywhere. And that's what is
intractable on Linux in general. The advantage of rpm/deb is that it
gives you a way to correctly manage the thing.

>
>> EPD can use eggs because they pretty much control the whole stack from
>> python, hence significantly reducing the issues of dependencies
>> issues.
>
> I don't follow. EPD uses a whole host of dependencies that are non-python...

yes, but most of them are included in EPD. EPD installs its own
python, its own swig, its own blas/lapack libraries, etc... which
means the exponential explosion of situations mentioned before do not
happen.

>
> Indeed, but as I said before, this is a constrained environment.
> Ubuntu 8.04 or 10.04, each with a controllable list of installed packages.

Then use .deb if you can, it will work so much better. You will
somewhat have a guarantee that everything is built correctly and as
expected.

> With Windows and MacOSX, python packagers seem to go the route of statically
> linking anyway...

The mac situation is pretty awful. There are countless different
python interpreters, each incompatible with each other. For
Numpy/Scipy, we only target the official python.org binary, but even
though, we still have tons of issues.

The static linking is almost always a bad idea, and mostly because of
distutils warts. Certainly, we want to go away from it as soon as
possible (one of the goal of the packaging solution I am working on is
to enable proper linking, but that requires a decent build tool
instead of distutils)

David

From merwok at netwok.org  Sat Jul 31 19:28:39 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 31 Jul 2010 19:28:39 +0200
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <AANLkTimx0aLJpwpBossZehSzts07=wd20cYHFw47Hr8a@mail.gmail.com>
References: <4C4DC004.8060705@simplistix.co.uk>	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>	<4C4DC842.4020109@simplistix.co.uk>	<AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>	<4C4E9A8D.7080700@simplistix.co.uk>	<AANLkTinoWTjmu_sGqCPo5kyj5D50u8bDFpBtXNUr8S5Q@mail.gmail.com>	<4C54509B.80501@simplistix.co.uk>
	<AANLkTimx0aLJpwpBossZehSzts07=wd20cYHFw47Hr8a@mail.gmail.com>
Message-ID: <4C545D47.9070001@netwok.org>

> The static linking is almost always a bad idea, and mostly because of
> distutils warts.

Even if you?re happily working on another tool, it would be very
appreciated if you could list those distutils issues in an email or
better on bugs.python.org.

Regards


From cournape at gmail.com  Sat Jul 31 19:48:48 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 1 Aug 2010 02:48:48 +0900
Subject: [Distutils] GCC versions and binary egg names
In-Reply-To: <4C545D47.9070001@netwok.org>
References: <4C4DC004.8060705@simplistix.co.uk>
	<AANLkTimQxCqnvpTduhNM8eu=RNuhT2jzokH0haF7hyjX@mail.gmail.com>
	<4C4DC842.4020109@simplistix.co.uk>
	<AANLkTimCXcn96Ppt4L-Xx6fr=V51vjyEkrijY2+Pewrn@mail.gmail.com>
	<4C4E9A8D.7080700@simplistix.co.uk>
	<AANLkTinoWTjmu_sGqCPo5kyj5D50u8bDFpBtXNUr8S5Q@mail.gmail.com>
	<4C54509B.80501@simplistix.co.uk>
	<AANLkTimx0aLJpwpBossZehSzts07=wd20cYHFw47Hr8a@mail.gmail.com>
	<4C545D47.9070001@netwok.org>
Message-ID: <AANLkTi=gU6Uu7YEVNJyobDQr0796vOxpCVYbfBfY7XFC@mail.gmail.com>

On Sun, Aug 1, 2010 at 2:28 AM, ?ric Araujo <merwok at netwok.org> wrote:
>> The static linking is almost always a bad idea, and mostly because of
>> distutils warts.
>
> Even if you?re happily working on another tool, it would be very
> appreciated if you could list those distutils issues in an email or
> better on bugs.python.org.

this is not a bug, but an architectural reason, because distutils
makes it impossible to use external build tools reliably.
Reimplementing this in distutils (or any other tool) does not make any
sense, waf for example does it perfectly
(http://code.google.com/p/waf/wiki/Uselib).

David

From jaraco at jaraco.com  Sat Jul 31 21:39:37 2010
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Sat, 31 Jul 2010 12:39:37 -0700
Subject: [Distutils] How to customize egg_info behavior
Message-ID: <12C7AB425F0DD546B6049311F827C74E08A37476C2@VA3DIAXVS141.RED001.local>

I'm using setuptools 0.6c11.

 

I'd like to programmatically customize the way the egg_info command is run.
That is, in my setup.py, I would like to run some functions to determine the
tag-build, tag-date, and tag-svn-revision parameters to egg_info. Are there
parameters

 

How is this task best accomplished? Do I subclass the egg_info Command? If
so, do I just specify cmdclass={'egg_info':my_custom_egg_info} ?  Or would
you recommend another approach?

 

Regards,

Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100731/643bf6e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100731/643bf6e9/attachment.bin>