From ben+python at benfinney.id.au  Wed Jul  1 04:01:15 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 01 Jul 2009 12:01:15 +1000
Subject: [Distutils] introspecting package data
References: <4A49FE13.2050902@simplistix.co.uk>
	<94bdd2610906300523l39fc6189s55466cfcd12531d0@mail.gmail.com>
	<4A4A120E.7070801@simplistix.co.uk>
	<CDE24769-8203-4478-9CDA-5FFE39768251@zope.com>
	<4A4A21A5.7010102@simplistix.co.uk>
Message-ID: <87ljn9tb4k.fsf@benfinney.id.au>

Chris Withers <chris at simplistix.co.uk> writes:

> > I recommend creating a data file that both setup.py and sphinx's
> > config.py read.
> 
> Declarative specification of package metadata in a non-python format?

ohpleaseohpleaseohpleaseohplease

-- 
 \       ?My business is to teach my aspirations to conform themselves |
  `\              to fact, not to try and make facts harmonise with my |
_o__)                   aspirations.? ?Thomas Henry Huxley, 1860-09-23 |
Ben Finney


From jim at zope.com  Wed Jul  1 11:33:33 2009
From: jim at zope.com (Jim Fulton)
Date: Wed, 1 Jul 2009 05:33:33 -0400
Subject: [Distutils] setuptools v. subversion 1.6
In-Reply-To: <4A4B1C73.9080207@simplistix.co.uk>
References: <4A4A4209.4000905@simplistix.co.uk>
	<B98C64D0-5154-4CCE-8293-14D6EDE0DC43@zope.com>
	<4A4B1C73.9080207@simplistix.co.uk>
Message-ID: <8E8BA669-09AC-424D-84A4-3A9BBD3477DA@zope.com>


On Jul 1, 2009, at 4:21 AM, Chris Withers wrote:

> Jim Fulton wrote:
>> IMO, include_package_data is an attractive nuisance. For newer  
>> projects, I just use package_data with a few globs.
>
> Does setuptools' setup function support package_data?
> I've been trying to use it but so far it totally fails to find the  
> files I specify..


Yes. Here's a working example:

   http://svn.zope.org/bobo/trunk/bobodoctestumentation/setup.py?rev=101064&view=auto

Jim

--
Jim Fulton
Zope Corporation



From chris at simplistix.co.uk  Wed Jul  1 10:21:07 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 01 Jul 2009 09:21:07 +0100
Subject: [Distutils] setuptools v. subversion 1.6
In-Reply-To: <B98C64D0-5154-4CCE-8293-14D6EDE0DC43@zope.com>
References: <4A4A4209.4000905@simplistix.co.uk>
	<B98C64D0-5154-4CCE-8293-14D6EDE0DC43@zope.com>
Message-ID: <4A4B1C73.9080207@simplistix.co.uk>

Jim Fulton wrote:
> 
> IMO, include_package_data is an attractive nuisance. For newer projects, 
> I just use package_data with a few globs.

Does setuptools' setup function support package_data?
I've been trying to use it but so far it totally fails to find the files 
I specify..

Chris


From chris at simplistix.co.uk  Wed Jul  1 11:33:03 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 01 Jul 2009 10:33:03 +0100
Subject: [Distutils] Where is the setuptools source repository?
Message-ID: <4A4B2D4F.9070702@simplistix.co.uk>

Hi All,

I'm trying to figure out why my package_data is being ignored. Of 
course, setuptools ends up being an egg, so it's impossible to pdb through.

So, I thought I'd checkout the setuptools trunk and just use that 
instead. But where is it?

The closest I could find is:

http://svn.python.org/projects/sandbox/trunk/setuptools

...but this has no tags, branches, etc. So is this it?
If not, where is it?

cheers,

Chris

From pje at telecommunity.com  Thu Jul  2 04:44:59 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 01 Jul 2009 22:44:59 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <4A4B2D4F.9070702@simplistix.co.uk>
References: <4A4B2D4F.9070702@simplistix.co.uk>
Message-ID: <20090702024200.5F2883A4109@sparrow.telecommunity.com>

At 10:33 AM 7/1/2009 +0100, Chris Withers wrote:
>Hi All,
>
>I'm trying to figure out why my package_data is being ignored. Of 
>course, setuptools ends up being an egg, so it's impossible to pdb through.
>
>So, I thought I'd checkout the setuptools trunk and just use that 
>instead. But where is it?
>
>The closest I could find is:
>
>http://svn.python.org/projects/sandbox/trunk/setuptools
>
>...but this has no tags, branches, etc. So is this it?

Yes.  The branches are in /sandbox/branches.

(Btw, 'package_data' will cause things to get included at install 
time, but it does not put them into sdist.  You'll need to use 
MANIFEST.in or a revision-control plugin to get data files included 
in an sdist.)


From ziade.tarek at gmail.com  Thu Jul  2 10:16:28 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 2 Jul 2009 10:16:28 +0200
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <20090702024200.5F2883A4109@sparrow.telecommunity.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
Message-ID: <94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>

On Thu, Jul 2, 2009 at 4:44 AM, P.J. Eby<pje at telecommunity.com> wrote:
> At 10:33 AM 7/1/2009 +0100, Chris Withers wrote:
>>
>> Hi All,
>>
>> I'm trying to figure out why my package_data is being ignored. Of course,
>> setuptools ends up being an egg, so it's impossible to pdb through.
>>
>> So, I thought I'd checkout the setuptools trunk and just use that instead.
>> But where is it?
>>
>> The closest I could find is:
>>
>> http://svn.python.org/projects/sandbox/trunk/setuptools
>>
>> ...but this has no tags, branches, etc. So is this it?
>
> Yes. ?The branches are in /sandbox/branches.
>
> (Btw, 'package_data' will cause things to get included at install time, but
> it does not put them into sdist. ?You'll need to use MANIFEST.in or a
> revision-control plugin to get data files included in an sdist.)

At distutils level, that's not true anymore with the current distutils
trunk though, which includes
package_data files without having to put them in the MANIFEST template

>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From jim at zope.com  Thu Jul  2 10:51:46 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 2 Jul 2009 04:51:46 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <20090702024200.5F2883A4109@sparrow.telecommunity.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
Message-ID: <7A244244-6D0E-4964-98C6-C6C84C4755EE@zope.com>


On Jul 1, 2009, at 10:44 PM, P.J. Eby wrote:
> (Btw, 'package_data' will cause things to get included at install  
> time, but it does not put them into sdist.  You'll need to use  
> MANIFEST.in or a revision-control plugin to get data files included  
> in an sdist.)


That's not what I've found.

Jim

--
Jim Fulton
Zope Corporation



From jim at zope.com  Thu Jul  2 11:01:16 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 2 Jul 2009 05:01:16 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
Message-ID: <0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>


On Jul 2, 2009, at 4:16 AM, Tarek Ziad? wrote:

> On Thu, Jul 2, 2009 at 4:44 AM, P.J. Eby<pje at telecommunity.com> wrote:
>> At 10:33 AM 7/1/2009 +0100, Chris Withers wrote:
>>>
>>> Hi All,
>>>
>>> I'm trying to figure out why my package_data is being ignored. Of  
>>> course,
>>> setuptools ends up being an egg, so it's impossible to pdb through.
>>>
>>> So, I thought I'd checkout the setuptools trunk and just use that  
>>> instead.
>>> But where is it?
>>>
>>> The closest I could find is:
>>>
>>> http://svn.python.org/projects/sandbox/trunk/setuptools
>>>
>>> ...but this has no tags, branches, etc. So is this it?
>>
>> Yes.  The branches are in /sandbox/branches.
>>
>> (Btw, 'package_data' will cause things to get included at install  
>> time, but
>> it does not put them into sdist.  You'll need to use MANIFEST.in or a
>> revision-control plugin to get data files included in an sdist.)
>
> At distutils level, that's not true anymore with the current distutils
> trunk though, which includes
> package_data files without having to put them in the MANIFEST template


Interesting.  I didn't realize that this changed.  This works at least  
as far back as Python 2.4, so if it changed, it changed some time  
ago.  Of course, the documentation:

   http://docs.python.org/distutils/setupscript.html#installing-package-data

indicates it should work. It also indicates that this option is new in  
Python 2.4.

Jim


--
Jim Fulton
Zope Corporation



From ziade.tarek at gmail.com  Thu Jul  2 11:25:48 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 2 Jul 2009 11:25:48 +0200
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
Message-ID: <94bdd2610907020225w64ceec94k8ca51f8bc406ee9d@mail.gmail.com>

>>> (Btw, 'package_data' will cause things to get included at install time,
>>> but
>>> it does not put them into sdist. ?You'll need to use MANIFEST.in or a
>>> revision-control plugin to get data files included in an sdist.)
>>
>> At distutils level, that's not true anymore with the current distutils
>> trunk though, which includes
>> package_data files without having to put them in the MANIFEST template
>
>
> Interesting. ?I didn't realize that this changed. ?This works at least as
> far back as Python 2.4, so if it changed, it changed some time ago. ?Of
> course, the documentation:
>
> ?http://docs.python.org/distutils/setupscript.html#installing-package-data
>
> indicates it should work. It also indicates that this option is new in
> Python 2.4.

I can't find in the svn logs such changes. Are we talking about the same issue ?
e.g. being forced to define package_data files in the MANIFEST.in
template to have them included
by sdist ?

What happened is that someone added an issue complaining that defined
package_data were
not installed, *unless* defined in the MANIFEST.in,

so I have worked in sdist to include them when the command is called
(in add_defaults), so it'll work
for Python 2.7.

btw, that breaks setuptools because its sdist command patches
disutils's sdist to provide a function that scans
VCS/DVCS directories and dies in a recursive loop.

I've provided a patch in setuptools bug tracker to avoid this. The
patch keeps the 'old' behavior so setuptools can
still work as expected when scanning vcs dirs. But it's a hack.

Notice that my plan is to backport distutils 2.7 when Python 2.7/3.2
is out, for python >= 2.5 and to provide
a new compatibility branch for setuptools at the same time for people
that uses it (unless the project evolves before
we reach that date). I am wondering though if it's not a good idea to
start that branch now, so it changes
while distutils changes, and is ready the very day 2.7/3.2 are out.

From jim at zope.com  Thu Jul  2 11:43:55 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 2 Jul 2009 05:43:55 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <94bdd2610907020225w64ceec94k8ca51f8bc406ee9d@mail.gmail.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<94bdd2610907020225w64ceec94k8ca51f8bc406ee9d@mail.gmail.com>
Message-ID: <5B5D8295-F9ED-40BA-A3DB-281304A8364D@zope.com>


On Jul 2, 2009, at 5:25 AM, Tarek Ziad? wrote:

>>>> (Btw, 'package_data' will cause things to get included at install  
>>>> time,
>>>> but
>>>> it does not put them into sdist.  You'll need to use MANIFEST.in  
>>>> or a
>>>> revision-control plugin to get data files included in an sdist.)
>>>
>>> At distutils level, that's not true anymore with the current  
>>> distutils
>>> trunk though, which includes
>>> package_data files without having to put them in the MANIFEST  
>>> template
>>
>>
>> Interesting.  I didn't realize that this changed.  This works at  
>> least as
>> far back as Python 2.4, so if it changed, it changed some time  
>> ago.  Of
>> course, the documentation:
>>
>>  http://docs.python.org/distutils/setupscript.html#installing-package-data
>>
>> indicates it should work. It also indicates that this option is new  
>> in
>> Python 2.4.
>
> I can't find in the svn logs such changes. Are we talking about the  
> same issue ?

> e.g. being forced to define package_data files in the MANIFEST.in
> template to have them included
> by sdist ?
>
> What happened is that someone added an issue complaining that defined
> package_data were
> not installed, *unless* defined in the MANIFEST.in,

Gaaaa.  Being more careful in my experimentation, I've found that  
package_data only seems to work if setuptools is used.  What's worse,  
only files checked into svn are included even when using package_data,  
so my theory about package_data being explicit and not dependent on  
the revision control system uses is wrong. :(

Jim

Of course, it's depressing that a packaging system requires so much  
experimentation to understand.

--
Jim Fulton
Zope Corporation



From chris at simplistix.co.uk  Thu Jul  2 12:10:22 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 02 Jul 2009 11:10:22 +0100
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>	
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
Message-ID: <4A4C878E.3000509@simplistix.co.uk>

Tarek Ziad? wrote:
> At distutils level, that's not true anymore with the current distutils
> trunk though, which includes
> package_data files without having to put them in the MANIFEST template

Yes, unfortunately setuptools replaces all this code with its own stuff, 
so that would need to change too...

Chris



From chris at simplistix.co.uk  Thu Jul  2 12:09:40 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 02 Jul 2009 11:09:40 +0100
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <20090702024200.5F2883A4109@sparrow.telecommunity.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
Message-ID: <4A4C8764.4010706@simplistix.co.uk>

P.J. Eby wrote:
> At 10:33 AM 7/1/2009 +0100, Chris Withers wrote:
>> http://svn.python.org/projects/sandbox/trunk/setuptools
>>
>> ...but this has no tags, branches, etc. So is this it?
> 
> Yes.  The branches are in /sandbox/branches.

Hmmm... what's the development process? Anyone with python core 
privileges can commit? What's the release process?
(I don't think I will, but if I fixed the subversion stuff for 1.6, how 
would a new release go about happening?)

> (Btw, 'package_data' will cause things to get included at install time, 
> but it does not put them into sdist.

Sorry for being dumb, but how is stuff going to be available at install 
time if it's not included in the sdist?!

> You'll need to use MANIFEST.in or 
> a revision-control plugin to get data files included in an sdist.)

OK.

Chris



From chris at simplistix.co.uk  Thu Jul  2 12:15:06 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 02 Jul 2009 11:15:06 +0100
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
Message-ID: <4A4C88AA.8050900@simplistix.co.uk>

Jim Fulton wrote:
> Interesting.  I didn't realize that this changed.  This works at least 
> as far back as Python 2.4, so if it changed, 

Chatting with Christian Theune, I believe this is because you put all 
your packages in 'src' directory. I don't like to lay my code out like 
that, and it should work with just your python packages in the root of 
the distribution.

 From what PJE has said, it works if you put a MANIFEST.in file in 
place, but the fact that you need to do that if you don't put your 
packages in a src directory feels like a bug to me...

Chris



From david at ar.media.kyoto-u.ac.jp  Thu Jul  2 12:48:15 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 02 Jul 2009 19:48:15 +0900
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <4A4C8764.4010706@simplistix.co.uk>
References: <4A4B2D4F.9070702@simplistix.co.uk>	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<4A4C8764.4010706@simplistix.co.uk>
Message-ID: <4A4C906F.3050905@ar.media.kyoto-u.ac.jp>

Chris Withers wrote:
>
> Sorry for being dumb, but how is stuff going to be available at
> install time if it's not included in the sdist?!

It does if you install from sources under the VCS.

This reminds me that it would be nice for distutils to have an
equivalent to the make distcheck command in autotools, which rebuilds
the package from scratch, using the sources generated by sdist instead
of the ones checked out from the VCS. This would somewhat avoids this
kind of problem.

David

From barry at python.org  Thu Jul  2 14:57:57 2009
From: barry at python.org (Barry Warsaw)
Date: Thu, 2 Jul 2009 08:57:57 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <4A4C88AA.8050900@simplistix.co.uk>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<4A4C88AA.8050900@simplistix.co.uk>
Message-ID: <AA156986-A55D-4052-9989-89527C206074@python.org>

On Jul 2, 2009, at 6:15 AM, Chris Withers wrote:

> Jim Fulton wrote:
>> Interesting.  I didn't realize that this changed.  This works at  
>> least as far back as Python 2.4, so if it changed,
>
> Chatting with Christian Theune, I believe this is because you put  
> all your packages in 'src' directory. I don't like to lay my code  
> out like that, and it should work with just your python packages in  
> the root of the distribution.

FWIW, I've found that buildout /only/ seems to work with your code in  
src (or some subdirectory of your main directory).  I can't remember  
the details but I think I've posted about that issue before.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090702/2077bd85/attachment.pgp>

From chris at simplistix.co.uk  Thu Jul  2 15:34:32 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 02 Jul 2009 14:34:32 +0100
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <AA156986-A55D-4052-9989-89527C206074@python.org>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<4A4C88AA.8050900@simplistix.co.uk>
	<AA156986-A55D-4052-9989-89527C206074@python.org>
Message-ID: <4A4CB768.6000809@simplistix.co.uk>

Barry Warsaw wrote:
> 
> FWIW, I've found that buildout /only/ seems to work with your code in 
> src (or some subdirectory of your main directory).  I can't remember the 
> details but I think I've posted about that issue before.

That's not been my experience, can you reproduce?

Chris


From jim at zope.com  Thu Jul  2 15:58:32 2009
From: jim at zope.com (Jim Fulton)
Date: Thu, 2 Jul 2009 09:58:32 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <AA156986-A55D-4052-9989-89527C206074@python.org>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<4A4C88AA.8050900@simplistix.co.uk>
	<AA156986-A55D-4052-9989-89527C206074@python.org>
Message-ID: <E7DF7F5C-7E0B-4963-B119-E57B371F89D8@zope.com>


On Jul 2, 2009, at 8:57 AM, Barry Warsaw wrote:

> On Jul 2, 2009, at 6:15 AM, Chris Withers wrote:
>
>> Jim Fulton wrote:
>>> Interesting.  I didn't realize that this changed.  This works at  
>>> least as far back as Python 2.4, so if it changed,
>>
>> Chatting with Christian Theune, I believe this is because you put  
>> all your packages in 'src' directory. I don't like to lay my code  
>> out like that, and it should work with just your python packages in  
>> the root of the distribution.
>
> FWIW, I've found that buildout /only/ seems to work with your code  
> in src (or some subdirectory of your main directory).  I can't  
> remember the details but I think I've posted about that issue before.


buildout works fine. The problem is the zope.testing test runner,  
which will find tests in your eggs directory if your buildout is in  
your software path.

Jim

--
Jim Fulton
Zope Corporation



From barry at python.org  Thu Jul  2 16:08:12 2009
From: barry at python.org (Barry Warsaw)
Date: Thu, 2 Jul 2009 10:08:12 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <E7DF7F5C-7E0B-4963-B119-E57B371F89D8@zope.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<4A4C88AA.8050900@simplistix.co.uk>
	<AA156986-A55D-4052-9989-89527C206074@python.org>
	<E7DF7F5C-7E0B-4963-B119-E57B371F89D8@zope.com>
Message-ID: <70264482-5863-4402-85A7-BCE44C93A4B2@python.org>

On Jul 2, 2009, at 9:58 AM, Jim Fulton wrote:

> buildout works fine. The problem is the zope.testing test runner,  
> which will find tests in your eggs directory if your buildout is in  
> your software path.

That sounds about right.  I do use both buildout and zope.testing.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090702/d0b5cf4e/attachment-0001.pgp>

From chris at simplistix.co.uk  Thu Jul  2 16:40:03 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 02 Jul 2009 15:40:03 +0100
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <E7DF7F5C-7E0B-4963-B119-E57B371F89D8@zope.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>	<20090702024200.5F2883A4109@sparrow.telecommunity.com>	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>	<4A4C88AA.8050900@simplistix.co.uk>	<AA156986-A55D-4052-9989-89527C206074@python.org>
	<E7DF7F5C-7E0B-4963-B119-E57B371F89D8@zope.com>
Message-ID: <4A4CC6C3.2070701@simplistix.co.uk>

Jim Fulton wrote:
> 
> buildout works fine. The problem is the zope.testing test runner, which 
> will find tests in your eggs directory if your buildout is in your 
> software path.

I'm safe from this one, since I store all my eggs in ~/buildout-eggs as 
specified in my ~/.buildout/default.cfg.

However, the same problem occurs with the contents of the build 
directory :-(

Christian, cc'ing you in hoping that you want to fix this bug ;-)

Chris


From ziade.tarek at gmail.com  Thu Jul  2 16:55:55 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 2 Jul 2009 16:55:55 +0200
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <4A4CC6C3.2070701@simplistix.co.uk>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<4A4C88AA.8050900@simplistix.co.uk>
	<AA156986-A55D-4052-9989-89527C206074@python.org>
	<E7DF7F5C-7E0B-4963-B119-E57B371F89D8@zope.com>
	<4A4CC6C3.2070701@simplistix.co.uk>
Message-ID: <94bdd2610907020755q984629od8f6a97ad6636ffc@mail.gmail.com>

On Thu, Jul 2, 2009 at 4:40 PM, Chris Withers<chris at simplistix.co.uk> wrote:
> Jim Fulton wrote:
>>
>> buildout works fine. The problem is the zope.testing test runner, which
>> will find tests in your eggs directory if your buildout is in your software
>> path.
>
> I'm safe from this one, since I store all my eggs in ~/buildout-eggs as
> specified in my ~/.buildout/default.cfg.
>
> However, the same problem occurs with the contents of the build directory
> :-(
>

You can give your test script options to ignore some dirs to avoid this,
that's what I do

> Christian, cc'ing you in hoping that you want to fix this bug ;-)
>
> Chris
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From chris at simplistix.co.uk  Thu Jul  2 16:57:16 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 02 Jul 2009 15:57:16 +0100
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <94bdd2610907020755q984629od8f6a97ad6636ffc@mail.gmail.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>	
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>	
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>	
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>	
	<4A4C88AA.8050900@simplistix.co.uk>	
	<AA156986-A55D-4052-9989-89527C206074@python.org>	
	<E7DF7F5C-7E0B-4963-B119-E57B371F89D8@zope.com>	
	<4A4CC6C3.2070701@simplistix.co.uk>
	<94bdd2610907020755q984629od8f6a97ad6636ffc@mail.gmail.com>
Message-ID: <4A4CCACC.4000305@simplistix.co.uk>

Tarek Ziad? wrote:
> You can give your test script options to ignore some dirs to avoid this,
> that's what I do

I shouldn't have to...

Chris


From ziade.tarek at gmail.com  Fri Jul  3 14:20:51 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 3 Jul 2009 14:20:51 +0200
Subject: [Distutils] RFC PEP 386 : Version comparisons
Message-ID: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>

Hello

back to that discussion, after re-reading all the threads I have a proposal :

1- let's add as we said "install_requires" in PEP 345 and describe in
it that people can define requirements,
  but without giving them rules for the version schemes.

  We will just write in that PEP that it's up to the *dependency
manager* (pip, setuptools, zc.buildout, etc)
  to provide a cmp() for the version.

  The only rule will be that each dependency is described like this :

     dist_name [<|>|==|!=|>=|<=] version

  where version is free and dist_name in [a-zA-Z0-9]

2- let's drop PEP 386 completely

3- I'll start a separate, standalone project that contains the less
controversial form of verlib.py, (the one that doesn't contains the
post-dev stuff)
    so we won't lose the work we all did in that.


Any thoughts ?

Tarek

From jim at zope.com  Fri Jul  3 14:39:07 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 3 Jul 2009 08:39:07 -0400
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
Message-ID: <C1B53E59-88F3-4C65-AA15-9D68E2E41F71@zope.com>


On Jul 3, 2009, at 8:20 AM, Tarek Ziad? wrote:

> Hello
>
> back to that discussion, after re-reading all the threads I have a  
> proposal :
>
> 1- let's add as we said "install_requires" in PEP 345 and describe in
> it that people can define requirements,
>  but without giving them rules for the version schemes.
>
>  We will just write in that PEP that it's up to the *dependency
> manager* (pip, setuptools, zc.buildout, etc)
>  to provide a cmp() for the version.

+1

>  The only rule will be that each dependency is described like this :
>
>     dist_name [<|>|==|!=|>=|<=] version
>
>  where version is free and dist_name in [a-zA-Z0-9]

s/dist_name/project_name/

Your restriction on dist/project name is too tight. Unfortunately, I  
don't think there are currently restrictions on project names, but  
that's a different battle. :)  I think there was some discussion  
recently about not allowing spaces in project names. Maybe we could  
get away with disallowing spaces in project names in install_requires.


> 2- let's drop PEP 386 completely

+1

>
> 3- I'll start a separate, standalone project that contains the less
> controversial form of verlib.py, (the one that doesn't contains the
> post-dev stuff)
>    so we won't lose the work we all did in that.
>
>
> Any thoughts ?


Big +1. :)

Getting install_requires would help me make progress on buildout for  
Python 3.

Jim

--
Jim Fulton
Zope Corporation



From ziade.tarek at gmail.com  Fri Jul  3 15:50:26 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 3 Jul 2009 15:50:26 +0200
Subject: [Distutils] Standalone version of Distutils - nighlty builds
Message-ID: <94bdd2610907030650w25869f4et23d08a376833cb28@mail.gmail.com>

Hello

I have done what's needed to be able install the current Distutils
trunk version as a standalone package in a Python installation.
I am not planning to publish it at this time but rather when 2.7/3.2
are about to be released.

If you are interested in working with the lasted Distutils version,
please install it and let me know how it goes ;)

I have a cron that build the distribution every night:

http://nightly.ziade.org/


Cheers
Tarek

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

From floris.bruynooghe at gmail.com  Fri Jul  3 22:25:23 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Fri, 3 Jul 2009 21:25:23 +0100
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
Message-ID: <20090703202523.GA25423@laurie.devork>

On Fri, Jul 03, 2009 at 02:20:51PM +0200, Tarek Ziad? wrote:
> 
> back to that discussion, after re-reading all the threads I have a proposal :
> 
> 1- let's add as we said "install_requires" in PEP 345 and describe in
> it that people can define requirements,
>   but without giving them rules for the version schemes.
> 
>   We will just write in that PEP that it's up to the *dependency
> manager* (pip, setuptools, zc.buildout, etc)
>   to provide a cmp() for the version.
> 
>   The only rule will be that each dependency is described like this :
> 
>      dist_name [<|>|==|!=|>=|<=] version
> 
>   where version is free and dist_name in [a-zA-Z0-9]

But does this not mean that you can end up with different results then
intended?  E.g. the developer uses pip but the user installs with
easy_install and because version comparison is not standardised the
user could end up with a version not intended by the developer.

Or did I miss an essential part of the discussion?

It was my impression that one, or even a few, incarnations of the
verlib.py where pretty close to something that most people could live
with.


Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From kevin at bud.ca  Fri Jul  3 23:03:41 2009
From: kevin at bud.ca (Kevin Teague)
Date: Fri, 3 Jul 2009 14:03:41 -0700 (PDT)
Subject: [Distutils] PEP 376: uninstall before upgrading an install?
Message-ID: <9b902c19-18ac-4ae7-a19c-1776570c60b5@y28g2000prd.googlegroups.com>

Currently, if you install a distribution via distutils (python
setup.py install), then later get a new version of that distribution
and upgrade your install, if the files to be installed change from one
version to the next the old, unused files get left in-place (generally
this is quite rare, since re-naming packages/modules means developers
need to change imports, etc. which is a hassle, but it is possible).

e.g. If "Spam-1.0" provides "ham.py, eggs.py" and "Spam-2.0" provides
"eggs.py, toast.py", then upgrading would leave an extra ham.py file
kicking around in site-packages, or vice-versa with toast.py if
downgrading.

At least, I'm being lazy and not actually testing this behaviour, but
I think that this is the current status with Distutils installs?

With a record of all installed files for a given version of a
distribution though, it would be possible to detect that a
distribution was already installed and that an upgrade/downgrade/
sidegrade is being performed, and if an uninstall was first done on
the old version before the new version was installed, this would
prevent any stray files from appearing in site-packages.

Has this already been considered? And if not, is there any reason why
an uninstall shouldn't happen before a distribution is upgraded in-
place?

From ziade.tarek at gmail.com  Sat Jul  4 01:45:07 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 4 Jul 2009 01:45:07 +0200
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090703202523.GA25423@laurie.devork>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<20090703202523.GA25423@laurie.devork>
Message-ID: <94bdd2610907031645q14aa7341n456b7173e4298977@mail.gmail.com>

On Fri, Jul 3, 2009 at 10:25 PM, Floris
Bruynooghe<floris.bruynooghe at gmail.com> wrote:
> On Fri, Jul 03, 2009 at 02:20:51PM +0200, Tarek Ziad? wrote:
>>
>> back to that discussion, after re-reading all the threads I have a proposal :
>>
>> 1- let's add as we said "install_requires" in PEP 345 and describe in
>> it that people can define requirements,
>> ? but without giving them rules for the version schemes.
>>
>> ? We will just write in that PEP that it's up to the *dependency
>> manager* (pip, setuptools, zc.buildout, etc)
>> ? to provide a cmp() for the version.
>>
>> ? The only rule will be that each dependency is described like this :
>>
>> ? ? ?dist_name [<|>|==|!=|>=|<=] version
>>
>> ? where version is free and dist_name in [a-zA-Z0-9]
>
> But does this not mean that you can end up with different results then
> intended? ?E.g. the developer uses pip but the user installs with
> easy_install and because version comparison is not standardised the
> user could end up with a version not intended by the developer.
>
> Or did I miss an essential part of the discussion?
>

Exactly so, because the version comparison is provided by the package
manager that
checks what's installed, what should be upgraded, etc. not by a
package alone or by distutils.

That is pip, or easy_install, or any tool that actually compares
versions. They are the one that can define
the rule.

So, as a developer, if your version scheme doesn't sort well when used
in one of the package
manager out there, you are screwed. And even if you are not screwed at
Python level,
and if your package make it to an os packager, you might get screwed then.

But it's OK as long as you stick with one package manager philosophy
and you adapt your version scheme
when packagers ask you to do so. For instances some developers don't
release but debian packages and don't care about the problems we are
trying to fix here.
Other are safe because they rely on setuptools scheme (wheter they us
pip or easy_install) in PythonLand.
And as soon as their distributions are turned into a deb/rpm, they fix
their version schemes if there's
a problem.

In other words, we are currently anoying all the python developers out
there that don't have a developement
cycle that generate dev. versions, or a lot of alphas, betas. They
don't understand why Python should force a
complex version scheme to version their packages when they have very
simple schemes like 1.0/1.1 etc..
which are fine.

If the whole Python community would find a consensus on a version
comparison scheme
*including* developement versions, we could have an unified tool. But
that's not the case
and people will always "dislike" the way we set the rule . So unless
Guido says : "this
is how we compare versions in Python", this unification won't happen I
believe. And
I don't think he'll ever say it because enforcing such a rule doesn't
sound right to
me from a pythonic point of view.

If distutils was a package manager I'd force a rule. I'd try to be a
dictator for PEP 386.
But it's not so it's hard to do so legitimately.

> It was my impression that one, or even a few, incarnations of the
> verlib.py where pretty close to something that most people could live
> with.

*pretty* close, but you will still get rants. That's what I've been
experiencing since the last Pycon.

PEP 345 is waiting for that versionning stuff, and I'd like to see it
moving forward.

From tseaver at palladion.com  Sat Jul  4 20:12:54 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 04 Jul 2009 14:12:54 -0400
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
Message-ID: <4A4F9BA6.6060304@palladion.com>

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

Tarek Ziad? wrote:

> back to that discussion, after re-reading all the threads I have a proposal :
> 
> 1- let's add as we said "install_requires" in PEP 345 and describe in
> it that people can define requirements,
>   but without giving them rules for the version schemes.
> 
>   We will just write in that PEP that it's up to the *dependency
> manager* (pip, setuptools, zc.buildout, etc)
>   to provide a cmp() for the version.
> 
>   The only rule will be that each dependency is described like this :
> 
>      dist_name [<|>|==|!=|>=|<=] version
> 
>   where version is free and dist_name in [a-zA-Z0-9]
> 
> 2- let's drop PEP 386 completely

- -1.  I would rather exclude some use cases (post releases), than drop
standardization altogether.



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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKT5um+gerLs4ltQ4RAgCsAJ9D0yLYkd4vkkVhZ81CMclJWO1T4ACgiVjd
bDq3s9KO/oV0LDtmYDeXHe0=
=gUpQ
-----END PGP SIGNATURE-----


From h.goebel at goebel-consult.de  Sat Jul  4 22:48:11 2009
From: h.goebel at goebel-consult.de (Hartmut Goebel)
Date: Sat, 04 Jul 2009 22:48:11 +0200
Subject: [Distutils] easy_install: fix for new Sourceforge download pages
Message-ID: <4A4FC00B.3080909@goebel-consult.de>

Hi,

since Sourceforge did change their download pages, easy_install is no
longer able to fetch files there-from. Shame in Sourceforge!

For one of my tools I fixed this using the following code:

......8<---------------
    def _download_html(self, url, headers, filename):
        if url.startswith('http://sourceforge.net/projects/'):
            if self._download_from_sf(url, filename):
                return
        return PackageIndex._download_html(self, url, headers, filename)

    def _download_from_sf(self, url, filename):
        page = open(filename).read()
        basename = os.path.basename(filename)
        for match in HREF.finditer(page):
            link = urlparse.urljoin(url, htmldecode(match.group(1)))
            if
link.startswith('http://downloads.sourceforge.net/sourceforge/'):
                path = urlparse.urlparse(url)[2]
                base = urllib2.unquote(path.split('/')[-1])
                if base == basename:
                    os.unlink(filename)
                    self._download_to(link, filename)
                    return True
        return False
......8<---------------

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

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

From ziade.tarek at gmail.com  Sun Jul  5 16:40:10 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 5 Jul 2009 16:40:10 +0200
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <4A4F9BA6.6060304@palladion.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
Message-ID: <94bdd2610907050740n26c50b94s719a20251d16b1f1@mail.gmail.com>

On Sat, Jul 4, 2009 at 8:12 PM, Tres Seaver<tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>
>> back to that discussion, after re-reading all the threads I have a proposal :
>>
>> 1- let's add as we said "install_requires" in PEP 345 and describe in
>> it that people can define requirements,
>> ? but without giving them rules for the version schemes.
>>
>> ? We will just write in that PEP that it's up to the *dependency
>> manager* (pip, setuptools, zc.buildout, etc)
>> ? to provide a cmp() for the version.
>>
>> ? The only rule will be that each dependency is described like this :
>>
>> ? ? ?dist_name [<|>|==|!=|>=|<=] version
>>
>> ? where version is free and dist_name in [a-zA-Z0-9]
>>
>> 2- let's drop PEP 386 completely
>
> - -1. ?I would rather exclude some use cases (post releases), than drop
> standardization altogether.

Would you be OK to say in PEP 345 that a suggested tool to compare
versions could be
verlib (released as a third-party software), but that any system could
also be used to compare versions ?

So we can move on and propose the PEP 345 change unindependantly from
a version comparison tool.

In conjunction, we could deprecate the existing version comparison
code in Distutils and
state that is not Distutils' role to provide such a feature. Then work
on PEP 386 separately and maybe
one day propose its inclusion.

From tseaver at palladion.com  Sun Jul  5 18:26:37 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Sun, 05 Jul 2009 12:26:37 -0400
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <94bdd2610907050740n26c50b94s719a20251d16b1f1@mail.gmail.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>	<4A4F9BA6.6060304@palladion.com>
	<94bdd2610907050740n26c50b94s719a20251d16b1f1@mail.gmail.com>
Message-ID: <h2qk82$7ir$1@ger.gmane.org>

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

Tarek Ziad? wrote:
> On Sat, Jul 4, 2009 at 8:12 PM, Tres Seaver<tseaver at palladion.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Tarek Ziad? wrote:
>>
>>> back to that discussion, after re-reading all the threads I have a proposal :
>>>
>>> 1- let's add as we said "install_requires" in PEP 345 and describe in
>>> it that people can define requirements,
>>>   but without giving them rules for the version schemes.
>>>
>>>   We will just write in that PEP that it's up to the *dependency
>>> manager* (pip, setuptools, zc.buildout, etc)
>>>   to provide a cmp() for the version.
>>>
>>>   The only rule will be that each dependency is described like this :
>>>
>>>      dist_name [<|>|==|!=|>=|<=] version
>>>
>>>   where version is free and dist_name in [a-zA-Z0-9]
>>>
>>> 2- let's drop PEP 386 completely
>> - -1.  I would rather exclude some use cases (post releases), than drop
>> standardization altogether.
> 
> Would you be OK to say in PEP 345 that a suggested tool to compare
> versions could be
> verlib (released as a third-party software), but that any system could
> also be used to compare versions ?

The purpose of defining the 'Requires-Dist' field in PEP 345 is to allow
for a standardized way of spelling dependences.  If we don't standardize
on the versioning, then we won't have gained any ground:  we might as
well punt and keep using setuptools, and *forbid* putting versions into
'Requires-Dist' at all.

> So we can move on and propose the PEP 345 change unindependantly from
> a version comparison tool.

I don't understand why we can't just settle on the reduced set:  the
exotic cases aren't supported today (in distutils), and are mappable
onto the verlib case with some effort.



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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKUNQ9+gerLs4ltQ4RAow8AKDRF1uhDPg6R+Fp3V++vr5XYarK1gCgwpGV
8X78X2PfsGU5JTA8YRGzf+U=
=aBye
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Sun Jul  5 20:40:37 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 05 Jul 2009 14:40:37 -0400
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <4A4F9BA6.6060304@palladion.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
Message-ID: <20090705183736.AAD703A4099@sparrow.telecommunity.com>

At 02:12 PM 7/4/2009 -0400, Tres Seaver wrote:
>- -1.  I would rather exclude some use cases (post releases), than drop
>standardization altogether.

And some people are the exact opposite, which means there's no 
consensus...  and thus no way to proceed.

(Incidentally, it was precisely some people's intolerance about 
supporting use cases other than their own that killed the consensus.)


From setuptools at bugs.python.org  Mon Jul  6 01:43:27 2009
From: setuptools at bugs.python.org (Jason R. Coombs)
Date: Sun, 05 Jul 2009 23:43:27 +0000
Subject: [Distutils] [issue79] SVN Entries parsing should use local svn
	command for	implementation
In-Reply-To: <1246837407.79.0.428114836768.issue79@psf.upfronthosting.co.za>
Message-ID: <1246837407.79.0.428114836768.issue79@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Per issue #64, there is a need for a more future-resistant SVN entries parsing
mechanism for setuptools.  The existing implementation is brittle and depends on
file formats which are internal to the SVN implementation.  @dw has proposed
setuptools use 'svn info --xml' to retrieve entry information.

I propose a patch must support the following:
1) Support fallback to native pure-python parsing if command is not found or
cannot be executed.
2) Use subprocess (requires Python 2.4) for broad platform support (including
Jython).
3) The current implementation appears to gather more detail from the entries
file than is exposed by 'svn info --xml'.  Ensure that the command-based
implementation provides the same logical result.
4) The implementation should have a well-defined and configurable means to
locate the SVN client. If there is no 'svn' command in the search path, there
should be an alternative means for setuptools to locate the command (such as one
or more of: a registry entry, environment variable, package manager callback, etc.).

Some features that may also be considered.
1) Support linking to the TortoiseSVN DLL for Windows users (use ctypes to avoid
compile-time dependencies).
2) Support shelling to a Java VM to support users of Subclipse.

Comments and suggestions are appreciated.  After there is a consensus, I'm
willing to draft an implementation.

----------
messages: 320
nosy: dw, jaraco
priority: feature
status: unread
title: SVN Entries parsing should use local svn command for implementation

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue79>
_______________________________________________

From tseaver at palladion.com  Mon Jul  6 04:29:48 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Sun, 05 Jul 2009 22:29:48 -0400
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090705183736.AAD703A4099@sparrow.telecommunity.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>	<4A4F9BA6.6060304@palladion.com>
	<20090705183736.AAD703A4099@sparrow.telecommunity.com>
Message-ID: <4A51619C.2010502@palladion.com>

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

P.J. Eby wrote:
> At 02:12 PM 7/4/2009 -0400, Tres Seaver wrote:
>> - -1.  I would rather exclude some use cases (post releases), than drop
>> standardization altogether.
> 
> And some people are the exact opposite, which means there's no 
> consensus...  and thus no way to proceed.
> 
> (Incidentally, it was precisely some people's intolerance about 
> supporting use cases other than their own that killed the consensus.)

I think we could settle on a reduced spelling / set of semantics which
could be used for the 'Requires-Dist' / 'Obsoletes-Dist' /
'Provides-Dist' fields called out in PEP 345.  Limiting the versions
which can be placed in those fields to a subset would allow us to move
forward on that PEP, without in any way requiring that people give up
using the more exotic spellings for their actual released versions.

Tools which encountered such version IDs should just "refuse to guess"
about their semantics, and require the user to disambiguate.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKUWGc+gerLs4ltQ4RAq5TAKCdTimgD+b77BEb31ytEJsvF/j19QCfXuOC
VVqxCTDHtgElzPNMpSBlc6M=
=pgfO
-----END PGP SIGNATURE-----


From ziade.tarek at gmail.com  Mon Jul  6 05:50:59 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 6 Jul 2009 05:50:59 +0200
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <h2qk82$7ir$1@ger.gmane.org>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<94bdd2610907050740n26c50b94s719a20251d16b1f1@mail.gmail.com>
	<h2qk82$7ir$1@ger.gmane.org>
Message-ID: <94bdd2610907052050u781d0f8arfd50f99fc5e2003c@mail.gmail.com>

On Sun, Jul 5, 2009 at 6:26 PM, Tres Seaver<tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>> On Sat, Jul 4, 2009 at 8:12 PM, Tres Seaver<tseaver at palladion.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Tarek Ziad? wrote:
>>>
>>>> back to that discussion, after re-reading all the threads I have a proposal :
>>>>
>>>> 1- let's add as we said "install_requires" in PEP 345 and describe in
>>>> it that people can define requirements,
>>>> ? but without giving them rules for the version schemes.
>>>>
>>>> ? We will just write in that PEP that it's up to the *dependency
>>>> manager* (pip, setuptools, zc.buildout, etc)
>>>> ? to provide a cmp() for the version.
>>>>
>>>> ? The only rule will be that each dependency is described like this :
>>>>
>>>> ? ? ?dist_name [<|>|==|!=|>=|<=] version
>>>>
>>>> ? where version is free and dist_name in [a-zA-Z0-9]
>>>>
>>>> 2- let's drop PEP 386 completely
>>> - -1. ?I would rather exclude some use cases (post releases), than drop
>>> standardization altogether.
>>
>> Would you be OK to say in PEP 345 that a suggested tool to compare
>> versions could be
>> verlib (released as a third-party software), but that any system could
>> also be used to compare versions ?
>
> The purpose of defining the 'Requires-Dist' field in PEP 345 is to allow
> for a standardized way of spelling dependences. ?If we don't standardize
> on the versioning, then we won't have gained any ground: ?we might as
> well punt and keep using setuptools, and *forbid* putting versions into
> 'Requires-Dist' at all.

The purpose of 'Requires-Dist' is to allow spelling dependencies so that
a package manager can use these declaration to work. Distutils is not
that package
manager. I don't see what is wrong in not forcing a version comparison
function, but just specifying the "dist_name [<|>|==|!=|>=|<=] version" field
where the "version" part sorting order is decided by a package manager.

>
>> So we can move on and propose the PEP 345 change unindependantly from
>> a version comparison tool.
>
> I don't understand why we can't just settle on the reduced set: ?the
> exotic cases aren't supported today (in distutils), and are mappable
> onto the verlib case with some effort.
>

To allow a developer that has created his own package manager on the
top of Distutils, to work with
his own way with versions numbers, without being forced by Distutils
to follow any particular
version scheme if he wants to use 'Requires-Dist'.

If we force the rule at distutils level, that means we are are saying
that distutils *is* a package manager .

From floris.bruynooghe at gmail.com  Mon Jul  6 10:28:57 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Mon, 6 Jul 2009 09:28:57 +0100
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090705183736.AAD703A4099@sparrow.telecommunity.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<20090705183736.AAD703A4099@sparrow.telecommunity.com>
Message-ID: <20090706082857.GA22871@laurie.devork>

On Sun, Jul 05, 2009 at 02:40:37PM -0400, P.J. Eby wrote:
> At 02:12 PM 7/4/2009 -0400, Tres Seaver wrote:
>> - -1.  I would rather exclude some use cases (post releases), than drop
>> standardization altogether.
>
> And some people are the exact opposite, which means there's no  
> consensus...  and thus no way to proceed.

I was under the impression that .devX and .postX where accepted, but
it got messy when .postX.devX got used.  But AFAIC (I'm not re-reading
the entire thread now) it was stated that .postX.devX was not actually
required (and if it was required just allowig exactly one each and it
that order was sufficient).

Also there is little harm in allowing .postX.devX you can simply
ignore it and use simple 1.0.0 if that's all you want (I for one would
ignore any .postX stuff).  As Tres says in another mail on this
thread, what's important is that you can compare versions of another
project and know what to expect as an outcome instead of hoping that
all package managers using your version will make sense out of it.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From floris.bruynooghe at gmail.com  Mon Jul  6 10:30:15 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Mon, 6 Jul 2009 09:30:15 +0100
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <h2qk82$7ir$1@ger.gmane.org>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<94bdd2610907050740n26c50b94s719a20251d16b1f1@mail.gmail.com>
	<h2qk82$7ir$1@ger.gmane.org>
Message-ID: <20090706083015.GB22871@laurie.devork>

On Sun, Jul 05, 2009 at 12:26:37PM -0400, Tres Seaver wrote:
> Tarek Ziad? wrote:
> > On Sat, Jul 4, 2009 at 8:12 PM, Tres Seaver<tseaver at palladion.com> wrote:
> >> Tarek Ziad? wrote:
> >>> 2- let's drop PEP 386 completely
> >> - -1.  I would rather exclude some use cases (post releases), than drop
> >> standardization altogether.
> > 
> > Would you be OK to say in PEP 345 that a suggested tool to compare
> > versions could be
> > verlib (released as a third-party software), but that any system could
> > also be used to compare versions ?
> 
> The purpose of defining the 'Requires-Dist' field in PEP 345 is to allow
> for a standardized way of spelling dependences.  If we don't standardize
> on the versioning, then we won't have gained any ground:  we might as
> well punt and keep using setuptools, and *forbid* putting versions into
> 'Requires-Dist' at all.

+1

From ziade.tarek at gmail.com  Mon Jul  6 11:04:31 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 6 Jul 2009 11:04:31 +0200
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090706082857.GA22871@laurie.devork>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<20090705183736.AAD703A4099@sparrow.telecommunity.com>
	<20090706082857.GA22871@laurie.devork>
Message-ID: <94bdd2610907060204v58d5fbbet5a1260be7e360e14@mail.gmail.com>

On Mon, Jul 6, 2009 at 10:28 AM, Floris
Bruynooghe<floris.bruynooghe at gmail.com> wrote:
> On Sun, Jul 05, 2009 at 02:40:37PM -0400, P.J. Eby wrote:
>> At 02:12 PM 7/4/2009 -0400, Tres Seaver wrote:
>>> - -1. ?I would rather exclude some use cases (post releases), than drop
>>> standardization altogether.
>>
>> And some people are the exact opposite, which means there's no
>> consensus... ?and thus no way to proceed.
>
> I was under the impression that .devX and .postX where accepted, but
> it got messy when .postX.devX got used. ?But AFAIC (I'm not re-reading
> the entire thread now) it was stated that .postX.devX was not actually
> required (and if it was required just allowig exactly one each and it
> that order was sufficient).
>
> Also there is little harm in allowing .postX.devX you can simply
> ignore it and use simple 1.0.0 if that's all you want (I for one would
> ignore any .postX stuff). ?As Tres says in another mail on this
> thread, what's important is that you can compare versions of another
> project and know what to expect as an outcome instead of hoping that
> all package managers using your version will make sense out of it.

Which means that *all* package managers will have to use the same standard, or
at least a compatible standard. And that all edge cases of each standard
will still have to work when they are used and compared in distutils.

I am not saying it's a bad thing, I am just saying that this should
not be enforced
by distutils because  :

- distutils doesn't have to compare versions (it's not a package manager)
- some developers won't buy that standard and use their own ways,
their own package manager

For the latter, should we forbid those developers the usage of the
requires-* fields ? Or should we let them
use those fields and let each package manager decide how to compare
the versions ?

Of course verlib can be added in distutils and provided as the default
cmp(), and we can state
in PEP 345 that's it's the default cmp() provided, and promote its usage.

But I'm not comfortable about forcing people to use that scheme, and
about writing in PEP 345 something
like 'you HAVE to be compatible with that scheme or your can't use that field'.

I am very uncomfortable with the word 'forbid' that has been used in
this thread.

Here's my updated proposal:

- add verlib in distutils; without the pos/dev stuff (and after
another round of re-work/feedback)
- add in PEP 345 the Requires field(s)
- say in PEP 345 that is *strongly encouraged* to use
distutils.verlib, but that a third-party package manager can use his
own.
  (in any case this will be possible so...)

Tarek

From jim at zope.com  Mon Jul  6 17:48:25 2009
From: jim at zope.com (Jim Fulton)
Date: Mon, 6 Jul 2009 11:48:25 -0400
Subject: [Distutils] [buildout] path usage and proposal
Message-ID: <1FFA912A-C6C2-4D11-8F31-9A3C206954D1@zope.com>

For buildout, there are a number of use cases relevant to using system  
Python:

U1
  Use a system Python with all of the goodies and changes it provides.
  This works now if a buildout is bootstrapped with a system Python.

U2
  Use a system python w/o 3rd-party additions.

U3
  Use a system python w/o 3rd-party additions but cherry-pick some
  3rd-part additions.  Note that this is especially attractive on
  system (like ubuntu) that make 3rd-party packages available in
  separate locations.

Right now, buildout deals with path in a somewhat ad-hoc manner. There
are two paths:

- The install path, which normally includes develop-eggs and eggs.  It
  may also include the buildout and setuptools distribution locations.

- The system path.

Buildout searches the install path for distributions that are already
installed. The intent is to skip searching external sources if a
distribution is already installed.  Unfortunately, buildout
unwittingly searches sys.path for installable packages.  This is
because indexes take a search_path argument that specifies a path to
search for installed distribtions.  This defaults to sys.path and
buildout doesn't pass it.  This means that buildout mistakingly
searches sys.path when looking for new packages.  This, of course, is
silly.

Paths are also used by running scripts to search for packages.  When
buildout generates a script, it generates a search path based on the
working set.  Note that it adds the working set locations to the base
path that the script starts with.

For existing behavior, we can work smarter by searching the base path
+ the current install paths for installed distribution and passing an
empty search path the index used to look for uninstalled distributions.

Note that not every distribution found on the base path is
importable.  In particular, an egg may be found on the base path, but
the egg itself must be added to the Python path to be importable.
The base path is used for 2 things:

- A place to look for installed distributions
- A place to import things from at run time.

It would be cleaner to separate these uses, although, for usability,
it might be simpler to keep them together.  There's probably little
harm in including a path in sys.path that *only* includes eggs.

So hear's a proposal:

1. Add an include-site-packages option, defaulting to true.  If false:
   set the base path to those paths not added by running site.py.
   We'll get this by evaling the output of:

     python -Sc "import sys; print (repr(sys.path))"

   The base path will be used for searching for distrbutions *and* for
   computing the run-time path.  The script preamble will become
   someting like::

      sys.path[:] = ... # set sys.path to the base path
      for path in ...: # iterate over working set using expression we  
use now
          if path not in sys.path:
              sys.path.insert(0, path)

   Note:
   a. We completely replace sys.path
   b. If a distro's location was already in the base path, we don't
      insert it.  This will help avoid accidently putting a base path
      ahead of egg-supplied paths.

2. Add a search-path option.  By default, it will be the base path.
   It can be manipulated in 2 ways:

   - It can be set.  If this is done, the base path will be ignored.

   - It can be incremented, for example, to cherry-pick the foo package
     on ubuntu:

       search-path += /usr/share/pycentral/foo/site-packages

So, in summary, we already handle U1. Proposal 1 addresses U2.
Proposal 1 and 2 together addresses U3.

Note that proposal 2 would also make it easier to share prebuilt eggs
with clean Pythons.  So, for example, if you already have an lxml egg
built for a clean Python, you could add it to the search path to use
it in a buildout.

Thoughts? Questions?

Jim

--
Jim Fulton
Zope Corporation



From pje at telecommunity.com  Mon Jul  6 19:09:34 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 06 Jul 2009 13:09:34 -0400
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090706082857.GA22871@laurie.devork>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<20090705183736.AAD703A4099@sparrow.telecommunity.com>
	<20090706082857.GA22871@laurie.devork>
Message-ID: <20090706170634.65D223A407B@sparrow.telecommunity.com>

At 09:28 AM 7/6/2009 +0100, Floris Bruynooghe wrote:
>On Sun, Jul 05, 2009 at 02:40:37PM -0400, P.J. Eby wrote:
> > At 02:12 PM 7/4/2009 -0400, Tres Seaver wrote:
> >> - -1.  I would rather exclude some use cases (post releases), than drop
> >> standardization altogether.
> >
> > And some people are the exact opposite, which means there's no
> > consensus...  and thus no way to proceed.
>
>I was under the impression that .devX and .postX where accepted, but
>it got messy when .postX.devX got used.  But AFAIC (I'm not re-reading
>the entire thread now) it was stated that .postX.devX was not actually
>required (and if it was required just allowig exactly one each and it
>that order was sufficient).

Not quite; it's .devX.postX that's not required.

It should be possible to implement all the development schemes I know 
of using something like:

     X(.X?)*([abc]X?)?(.postX?)?(.devX?)?

where "X" expands to (\d+).

Which is why I don't really understand what all the fuss is 
about.  If you're going to support a/b/c, you're not going to be able 
to do straight string comparison anyway, so there's little loss in 
allowing ONE post tag and ONE dev tag to be used as well.


From tseaver at palladion.com  Mon Jul  6 19:53:01 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 06 Jul 2009 13:53:01 -0400
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <94bdd2610907052050u781d0f8arfd50f99fc5e2003c@mail.gmail.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>	<4A4F9BA6.6060304@palladion.com>	<94bdd2610907050740n26c50b94s719a20251d16b1f1@mail.gmail.com>	<h2qk82$7ir$1@ger.gmane.org>
	<94bdd2610907052050u781d0f8arfd50f99fc5e2003c@mail.gmail.com>
Message-ID: <4A5239FD.90209@palladion.com>

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

Tarek Ziad? wrote:
> On Sun, Jul 5, 2009 at 6:26 PM, Tres Seaver<tseaver at palladion.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Tarek Ziad? wrote:
>>> On Sat, Jul 4, 2009 at 8:12 PM, Tres Seaver<tseaver at palladion.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Tarek Ziad? wrote:
>>>>
>>>>> back to that discussion, after re-reading all the threads I have a proposal :
>>>>>
>>>>> 1- let's add as we said "install_requires" in PEP 345 and describe in
>>>>> it that people can define requirements,
>>>>>   but without giving them rules for the version schemes.
>>>>>
>>>>>   We will just write in that PEP that it's up to the *dependency
>>>>> manager* (pip, setuptools, zc.buildout, etc)
>>>>>   to provide a cmp() for the version.
>>>>>
>>>>>   The only rule will be that each dependency is described like this :
>>>>>
>>>>>      dist_name [<|>|==|!=|>=|<=] version
>>>>>
>>>>>   where version is free and dist_name in [a-zA-Z0-9]
>>>>>
>>>>> 2- let's drop PEP 386 completely
>>>> - -1.  I would rather exclude some use cases (post releases), than drop
>>>> standardization altogether.
>>> Would you be OK to say in PEP 345 that a suggested tool to compare
>>> versions could be
>>> verlib (released as a third-party software), but that any system could
>>> also be used to compare versions ?
>> The purpose of defining the 'Requires-Dist' field in PEP 345 is to allow
>> for a standardized way of spelling dependences.  If we don't standardize
>> on the versioning, then we won't have gained any ground:  we might as
>> well punt and keep using setuptools, and *forbid* putting versions into
>> 'Requires-Dist' at all.
> 
> The purpose of 'Requires-Dist' is to allow spelling dependencies so that
> a package manager can use these declaration to work. Distutils is not
> that package
> manager. I don't see what is wrong in not forcing a version comparison
> function, but just specifying the "dist_name [<|>|==|!=|>=|<=] version" field
> where the "version" part sorting order is decided by a package manager.

If we allow versions in that field without defining their semantics, and
therefore constraining the available spellings, *nobody* can write tools
which use them, except perhaps for managing only the packages which the
author himself writes.

>>> So we can move on and propose the PEP 345 change unindependantly from
>>> a version comparison tool.
>> I don't understand why we can't just settle on the reduced set:  the
>> exotic cases aren't supported today (in distutils), and are mappable
>> onto the verlib case with some effort.
>>
> 
> To allow a developer that has created his own package manager on the
> top of Distutils, to work with
> his own way with versions numbers, without being forced by Distutils
> to follow any particular
> version scheme if he wants to use 'Requires-Dist'.
> 
> If we force the rule at distutils level, that means we are are saying
> that distutils *is* a package manager .

Not at all:  we are trying to make it possible to develop interoperable
packaging tools, which was the whole point of adding those fields to
PKG-INFO in the first place,  If *package authors* stick to the minimal
rules, and don't depend on / provide anything which can't be spelled
with standard rules, then *any* packaging tool which understands those
rules can manage their packages.

This was the point of PEPs 345 and 386:  Debian maintainers, RPM
packagers, people writing custom tools, all need a regular, uniform,
unambiguous scheme for representing versions.  I am arguing that the
overwhelming majority of released packages do fit into such constraints:
 dumping the constraints for the "benefit" of the tiny handful of
exceptions removes any motivation for having version info in those
fields at all.

Interoperable tools would just drop non-coforming versionson the floor,
with a warning, making the field equivalent to an unversioned distribution.



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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKUjn9+gerLs4ltQ4RAvRPAJ9BvsI5Em0l0D41mVKKyKXf1+w9VQCgvy5z
t1HC1rU5ANlIG5pwnNRA1WU=
=jmNE
-----END PGP SIGNATURE-----


From chris at simplistix.co.uk  Mon Jul  6 20:52:38 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 06 Jul 2009 19:52:38 +0100
Subject: [Distutils] introspecting package data
In-Reply-To: <94bdd2610906300818g20c82215g48601ad54767c985@mail.gmail.com>
References: <4A49FE13.2050902@simplistix.co.uk>	
	<94bdd2610906300523l39fc6189s55466cfcd12531d0@mail.gmail.com>	
	<4A4A120E.7070801@simplistix.co.uk>	
	<CDE24769-8203-4478-9CDA-5FFE39768251@zope.com>	
	<4A4A21A5.7010102@simplistix.co.uk>
	<94bdd2610906300818g20c82215g48601ad54767c985@mail.gmail.com>
Message-ID: <4A5247F6.3080407@simplistix.co.uk>

Tarek Ziad? wrote:
> Yes,  as long as the metadata are in a python file, you're in trouble
> to automate anything like you are mentioning.
> But a static metadata system needs to provide a registery mechanism,
> so we can call some arbitrary code
> when some metadata are generated at installation time for instance.

I don't follow this at all. Why is arbitrary code needed?

Chris

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

From floris.bruynooghe at gmail.com  Tue Jul  7 00:41:47 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Mon, 6 Jul 2009 23:41:47 +0100
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090706170634.65D223A407B@sparrow.telecommunity.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<20090705183736.AAD703A4099@sparrow.telecommunity.com>
	<20090706082857.GA22871@laurie.devork>
	<20090706170634.65D223A407B@sparrow.telecommunity.com>
Message-ID: <20090706224147.GA28100@laurie.devork>

On Mon, Jul 06, 2009 at 01:09:34PM -0400, P.J. Eby wrote:
> At 09:28 AM 7/6/2009 +0100, Floris Bruynooghe wrote:
>> On Sun, Jul 05, 2009 at 02:40:37PM -0400, P.J. Eby wrote:
>> > At 02:12 PM 7/4/2009 -0400, Tres Seaver wrote:
>> >> - -1.  I would rather exclude some use cases (post releases), than drop
>> >> standardization altogether.
>> >
>> > And some people are the exact opposite, which means there's no
>> > consensus...  and thus no way to proceed.
>>
>> I was under the impression that .devX and .postX where accepted, but
>> it got messy when .postX.devX got used.  But AFAIC (I'm not re-reading
>> the entire thread now) it was stated that .postX.devX was not actually
>> required (and if it was required just allowig exactly one each and it
>> that order was sufficient).
>
> Not quite; it's .devX.postX that's not required.
>
> It should be possible to implement all the development schemes I know of 
> using something like:
>
>     X(.X?)*([abc]X?)?(.postX?)?(.devX?)?
>
> where "X" expands to (\d+).
>
> Which is why I don't really understand what all the fuss is about.  If 
> you're going to support a/b/c, you're not going to be able to do straight 
> string comparison anyway, so there's little loss in allowing ONE post tag 
> and ONE dev tag to be used as well.

Eh well, almost got that right.  Point is this isn't an overly
complicated scheme and it allows most, if not all, sensible existing
schemes to be converted to it.  And as Tres argues very good in
another mail on this thread[0] this is actually important to make the
requires-dist of PEP 345 useful.

So I'm in favour not dropping PEP 386.

Regards
Floris

[0] http://mail.python.org/pipermail/distutils-sig/2009-July/012410.html

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From david.lyon at preisshare.net  Tue Jul  7 01:30:24 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 06 Jul 2009 19:30:24 -0400
Subject: [Distutils] introspecting package data
In-Reply-To: <4A5247F6.3080407@simplistix.co.uk>
References: <4A49FE13.2050902@simplistix.co.uk>
	<94bdd2610906300523l39fc6189s55466cfcd12531d0@mail.gmail.com>
	<4A4A120E.7070801@simplistix.co.uk>
	<CDE24769-8203-4478-9CDA-5FFE39768251@zope.com>
	<4A4A21A5.7010102@simplistix.co.uk>
	<94bdd2610906300818g20c82215g48601ad54767c985@mail.gmail.com>
	<4A5247F6.3080407@simplistix.co.uk>
Message-ID: <db631abbad069689a332015c6f2244b5@preisshare.net>

On Mon, 06 Jul 2009 19:52:38 +0100, Chris Withers <chris at simplistix.co.uk>
wrote:
> Tarek Ziad? wrote:
>> Yes,  as long as the metadata are in a python file, you're in trouble
>> to automate anything like you are mentioning.
>> But a static metadata system needs to provide a registery mechanism,
>> so we can call some arbitrary code
>> when some metadata are generated at installation time for instance.
> 
> I don't follow this at all. Why is arbitrary code needed?

I think what he means is that he doesn't like the way it is at the
moment and thinks that the version numbers and other metadata should 
sit in a config file somewhere.

Then the setup.py can be generated from the metadata..

David

From david.lyon at preisshare.net  Tue Jul  7 01:57:50 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 06 Jul 2009 19:57:50 -0400
Subject: [Distutils] [buildout] path usage and proposal
In-Reply-To: <1FFA912A-C6C2-4D11-8F31-9A3C206954D1@zope.com>
References: <1FFA912A-C6C2-4D11-8F31-9A3C206954D1@zope.com>
Message-ID: <b0b6463a0330047c216d39311b402d4d@preisshare.net>


Good Evening Jim,

On Mon, 6 Jul 2009 11:48:25 -0400, Jim Fulton <jim at zope.com> wrote:

> ..
> Paths are also used by running scripts to search for packages.  When
> buildout generates a script, it generates a search path based on the
> working set.  Note that it adds the working set locations to the base
> path that the script starts with.

True

> For existing behavior, we can work smarter by searching the base path
> + the current install paths for installed distribution and passing an
> empty search path the index used to look for uninstalled distributions.

That's already how it works.

> Note that not every distribution found on the base path is
> importable.  In particular, an egg may be found on the base path, but
> the egg itself must be added to the Python path to be importable.
> The base path is used for 2 things:
> 
> - A place to look for installed distributions
> - A place to import things from at run time.

Yes, and the importing is done via .PTH files...

> It would be cleaner to separate these uses, although, for usability,
> it might be simpler to keep them together.  There's probably little
> harm in including a path in sys.path that *only* includes eggs.

The only way to enforce that is to change the interpretor itself..

Within site.py... otherwise.. enforce it with some sort of packaging
tool.... lol

Are you suggesting something like a directory "SITE-EGGS" ?

> So hear's a proposal:
> 
> 1. Add an include-site-packages option, defaulting to true.  If false:
>    set the base path to those paths not added by running site.py.
>    We'll get this by evaling the output of:
> 
>      python -Sc "import sys; print (repr(sys.path))"
> 
>    The base path will be used for searching for distrbutions *and* for
>    computing the run-time path.  The script preamble will become
>    someting like::
> 
>       sys.path[:] = ... # set sys.path to the base path
>       for path in ...: # iterate over working set using expression we  
> use now
>           if path not in sys.path:
>               sys.path.insert(0, path)
> 
>    Note:
>    a. We completely replace sys.path
>    b. If a distro's location was already in the base path, we don't
>       insert it.  This will help avoid accidently putting a base path
>       ahead of egg-supplied paths.

It seems clunky....

> 2. Add a search-path option.  By default, it will be the base path.
>    It can be manipulated in 2 ways:
> 
>    - It can be set.  If this is done, the base path will be ignored.
> 
>    - It can be incremented, for example, to cherry-pick the foo package
>      on ubuntu:
> 
>        search-path += /usr/share/pycentral/foo/site-packages
> 
..

> Thoughts? Questions?

All the functionality you are asking for already exists within python
already... afiak there's already provision to add extra paths and do all
these extra things.

Under linux, there is this great place to put packages .. 
/usr/local/pythonx.x/.. and under windows there's also a spot in
\Documents and Settings\User\My Documents.

EasyInstall will let us install there if we ask it to....

The big problem is that we/users aren't doing any of this all that
well at the moment because we/they forget the command lines.

Maybe I don't know buildout too well... so I don't know the issue..

Maybe you just need a better tool for installing packages under
buildout.. maybe I could modify my python package manager in some
way to support buildout better....

http://sourceforge.net/projects/pythonpkgmgr/

In a future version of the python package manager, I will
probably add capabilities to move packages from one place
to another... haha... generate buildout files..

None of these things really require anything extra from
distutils than is already there....

Regards

David






From chris at simplistix.co.uk  Tue Jul  7 02:54:17 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 07 Jul 2009 01:54:17 +0100
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <5B5D8295-F9ED-40BA-A3DB-281304A8364D@zope.com>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<94bdd2610907020225w64ceec94k8ca51f8bc406ee9d@mail.gmail.com>
	<5B5D8295-F9ED-40BA-A3DB-281304A8364D@zope.com>
Message-ID: <4A529CB9.6010802@simplistix.co.uk>

Jim Fulton wrote:
> 
> Of course, it's depressing that a packaging system requires so much 
> experimentation to understand.

Worse still is when the implementation disagrees with the documentation...

And when we have two systems that purport to be the same (distutils and 
setuptools) in this respect, and neither work...

Chris

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

From chris at simplistix.co.uk  Tue Jul  7 03:18:38 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 07 Jul 2009 02:18:38 +0100
Subject: [Distutils] introspecting package data
In-Reply-To: <db631abbad069689a332015c6f2244b5@preisshare.net>
References: <4A49FE13.2050902@simplistix.co.uk>	<94bdd2610906300523l39fc6189s55466cfcd12531d0@mail.gmail.com>	<4A4A120E.7070801@simplistix.co.uk>	<CDE24769-8203-4478-9CDA-5FFE39768251@zope.com>	<4A4A21A5.7010102@simplistix.co.uk>	<94bdd2610906300818g20c82215g48601ad54767c985@mail.gmail.com>	<4A5247F6.3080407@simplistix.co.uk>
	<db631abbad069689a332015c6f2244b5@preisshare.net>
Message-ID: <4A52A26E.4060504@simplistix.co.uk>

David Lyon wrote:
> On Mon, 06 Jul 2009 19:52:38 +0100, Chris Withers <chris at simplistix.co.uk>
> wrote:
>> Tarek Ziad? wrote:
>>> Yes,  as long as the metadata are in a python file, you're in trouble
>>> to automate anything like you are mentioning.
>>> But a static metadata system needs to provide a registery mechanism,
>>> so we can call some arbitrary code
>>> when some metadata are generated at installation time for instance.
>> I don't follow this at all. Why is arbitrary code needed?
> 
> I think what he means is that he doesn't like the way it is at the
> moment and thinks that the version numbers and other metadata should 
> sit in a config file somewhere.
> 
> Then the setup.py can be generated from the metadata..

No, that's not what Tarek said at all, perhaps he can comment on why a 
static metadata system needs to provide a registry mechanism so that 
arbitrary code can be called?

cheers,

Chris

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

From jim at zope.com  Tue Jul  7 11:30:03 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 7 Jul 2009 05:30:03 -0400
Subject: [Distutils] [buildout] path usage and proposal
In-Reply-To: <b0b6463a0330047c216d39311b402d4d@preisshare.net>
References: <1FFA912A-C6C2-4D11-8F31-9A3C206954D1@zope.com>
	<b0b6463a0330047c216d39311b402d4d@preisshare.net>
Message-ID: <9A5F6506-58AB-4803-8CE4-F9C50F7FDA75@zope.com>

This proposal is limited to buildout and how buildout handles paths.

Jim

On Jul 6, 2009, at 7:57 PM, David Lyon wrote:

>
> Good Evening Jim,
>
> On Mon, 6 Jul 2009 11:48:25 -0400, Jim Fulton <jim at zope.com> wrote:
>
>> ..
>> Paths are also used by running scripts to search for packages.  When
>> buildout generates a script, it generates a search path based on the
>> working set.  Note that it adds the working set locations to the base
>> path that the script starts with.
>
> True
>
>> For existing behavior, we can work smarter by searching the base path
>> + the current install paths for installed distribution and passing an
>> empty search path the index used to look for uninstalled  
>> distributions.
>
> That's already how it works.
>
>> Note that not every distribution found on the base path is
>> importable.  In particular, an egg may be found on the base path, but
>> the egg itself must be added to the Python path to be importable.
>> The base path is used for 2 things:
>>
>> - A place to look for installed distributions
>> - A place to import things from at run time.
>
> Yes, and the importing is done via .PTH files...
>
>> It would be cleaner to separate these uses, although, for usability,
>> it might be simpler to keep them together.  There's probably little
>> harm in including a path in sys.path that *only* includes eggs.
>
> The only way to enforce that is to change the interpretor itself..
>
> Within site.py... otherwise.. enforce it with some sort of packaging
> tool.... lol
>
> Are you suggesting something like a directory "SITE-EGGS" ?
>
>> So hear's a proposal:
>>
>> 1. Add an include-site-packages option, defaulting to true.  If  
>> false:
>>   set the base path to those paths not added by running site.py.
>>   We'll get this by evaling the output of:
>>
>>     python -Sc "import sys; print (repr(sys.path))"
>>
>>   The base path will be used for searching for distrbutions *and* for
>>   computing the run-time path.  The script preamble will become
>>   someting like::
>>
>>      sys.path[:] = ... # set sys.path to the base path
>>      for path in ...: # iterate over working set using expression we
>> use now
>>          if path not in sys.path:
>>              sys.path.insert(0, path)
>>
>>   Note:
>>   a. We completely replace sys.path
>>   b. If a distro's location was already in the base path, we don't
>>      insert it.  This will help avoid accidently putting a base path
>>      ahead of egg-supplied paths.
>
> It seems clunky....
>
>> 2. Add a search-path option.  By default, it will be the base path.
>>   It can be manipulated in 2 ways:
>>
>>   - It can be set.  If this is done, the base path will be ignored.
>>
>>   - It can be incremented, for example, to cherry-pick the foo  
>> package
>>     on ubuntu:
>>
>>       search-path += /usr/share/pycentral/foo/site-packages
>>
> ..
>
>> Thoughts? Questions?
>
> All the functionality you are asking for already exists within python
> already... afiak there's already provision to add extra paths and do  
> all
> these extra things.
>
> Under linux, there is this great place to put packages ..
> /usr/local/pythonx.x/.. and under windows there's also a spot in
> \Documents and Settings\User\My Documents.
>
> EasyInstall will let us install there if we ask it to....
>
> The big problem is that we/users aren't doing any of this all that
> well at the moment because we/they forget the command lines.
>
> Maybe I don't know buildout too well... so I don't know the issue..
>
> Maybe you just need a better tool for installing packages under
> buildout.. maybe I could modify my python package manager in some
> way to support buildout better....
>
> http://sourceforge.net/projects/pythonpkgmgr/
>
> In a future version of the python package manager, I will
> probably add capabilities to move packages from one place
> to another... haha... generate buildout files..
>
> None of these things really require anything extra from
> distutils than is already there....
>
> Regards
>
> David
>
>
>
>
>

--
Jim Fulton
Zope Corporation



From jim at zope.com  Tue Jul  7 11:36:15 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 7 Jul 2009 05:36:15 -0400
Subject: [Distutils] Where is the setuptools source repository?
In-Reply-To: <4A529CB9.6010802@simplistix.co.uk>
References: <4A4B2D4F.9070702@simplistix.co.uk>
	<20090702024200.5F2883A4109@sparrow.telecommunity.com>
	<94bdd2610907020116n166c31e3w196958c7f652b548@mail.gmail.com>
	<0F86AD4F-AF13-4F5D-B112-BB787DF8191B@zope.com>
	<94bdd2610907020225w64ceec94k8ca51f8bc406ee9d@mail.gmail.com>
	<5B5D8295-F9ED-40BA-A3DB-281304A8364D@zope.com>
	<4A529CB9.6010802@simplistix.co.uk>
Message-ID: <0572DAE0-8177-47E9-A17D-C134AA6E92E2@zope.com>


On Jul 6, 2009, at 8:54 PM, Chris Withers wrote:

> Jim Fulton wrote:
>> Of course, it's depressing that a packaging system requires so much  
>> experimentation to understand.
>
> Worse still is when the implementation disagrees with the  
> documentation...
>
> And when we have two systems that purport to be the same (distutils  
> and setuptools) in this respect, and neither work...


The approach that setuptools took was reasonable in many ways and it  
achieves quite a bit.  It's reasonable to try to work "within the  
system".  Distutils intends to provide an extensible architecture and  
setuptools builds on that.  It achieves major improvements over  
distutils.  With all it's warts, I'm still very thankful for it.

Jim

--
Jim Fulton
Zope Corporation



From floris.bruynooghe at gmail.com  Tue Jul  7 11:52:44 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 7 Jul 2009 10:52:44 +0100
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090706170634.65D223A407B@sparrow.telecommunity.com>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<20090705183736.AAD703A4099@sparrow.telecommunity.com>
	<20090706082857.GA22871@laurie.devork>
	<20090706170634.65D223A407B@sparrow.telecommunity.com>
Message-ID: <20090707095244.GA32247@laurie.devork>

Hi

On Mon, Jul 06, 2009 at 01:09:34PM -0400, P.J. Eby wrote:
> It should be possible to implement all the development schemes I know of 
> using something like:
>
>     X(.X?)*([abc]X?)?(.postX?)?(.devX?)?
>
> where "X" expands to (\d+).

I've made a fork of verlib implementing this simplified postdev
handling: http://bitbucket.org/flub/verlib/

Tarek has write access to it too, but it's probably best if it gets
merged at least into a branch on the original repo if this needs to
live for any decent length of time.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From ziade.tarek at gmail.com  Tue Jul  7 11:57:20 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 7 Jul 2009 11:57:20 +0200
Subject: [Distutils] RFC PEP 386 : Version comparisons
In-Reply-To: <20090707095244.GA32247@laurie.devork>
References: <94bdd2610907030520x49ede2dfq5a4ae1f35c4fc36c@mail.gmail.com>
	<4A4F9BA6.6060304@palladion.com>
	<20090705183736.AAD703A4099@sparrow.telecommunity.com>
	<20090706082857.GA22871@laurie.devork>
	<20090706170634.65D223A407B@sparrow.telecommunity.com>
	<20090707095244.GA32247@laurie.devork>
Message-ID: <94bdd2610907070257j6442e22ep8617d1870ad1e255@mail.gmail.com>

On Tue, Jul 7, 2009 at 11:52 AM, Floris
Bruynooghe<floris.bruynooghe at gmail.com> wrote:
> Hi
>
> On Mon, Jul 06, 2009 at 01:09:34PM -0400, P.J. Eby wrote:
>> It should be possible to implement all the development schemes I know of
>> using something like:
>>
>> ? ? X(.X?)*([abc]X?)?(.postX?)?(.devX?)?
>>
>> where "X" expands to (\d+).
>
> I've made a fork of verlib implementing this simplified postdev
> handling: http://bitbucket.org/flub/verlib/
>
> Tarek has write access to it too, but it's probably best if it gets
> merged at least into a branch on the original repo if this needs to
> live for any decent length of time.
>

Hey Floris,

I've added your account so you can write directly into the original repo
please feel free to merge, this change is something wel wanted to do in any case

btw: we need to work on the documentation that goes with the module
to explain all uses cases


Regards


>
> Regards
> Floris
>
> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From ben+freedesktop at benfinney.id.au  Tue Jul  7 15:21:05 2009
From: ben+freedesktop at benfinney.id.au (Ben Finney)
Date: Tue, 07 Jul 2009 23:21:05 +1000
Subject: [Distutils] Python package distribution standards
Message-ID: <87bpnwpr26.fsf@benfinney.id.au>

Howdy all,

I'm cross-posting between the Python distutils discussion forum and the
Freedesktop distributions discussion forum. If you think any OS-specific
discussion forums need to be involved, please ask a representative to
join one or more of these forums so the discussion doesn't get too
attenuated.

For a number of weeks now, the Python package distribution standards
have been undergoing intensive scrutiny in the wake of much face-to-face
discussion at Pycon 2009. Many goals are being juggled in an attempt to
get a beneficial result for everyone affected by these standards.

The discussion has reached a point of some ?open questions?
<URL:http://article.gmane.org/gmane.comp.python.devel/105237> on the
current draft of PEP 376 <URL:http://www.python.org/dev/peps/pep-0376/>,
which has re-raised the issue of how Python distribution standards could
be improved with regard to OS distribution packaging requirements.

I've made a case for metadata that would be beneficial to OS packagers
<URL:http://thread.gmane.org/gmane.comp.python.devel/105237/focus=105270>,
but I am not very cognizant of the needs of specific OS packaging
systems. We need input from others who know and care about how Python
packages should fit into specific operating system package management
systems.

If you feel you have constructive input on how Python's package
distribution metadata can be improved for the needs of OS packagers
(along with other needs being targeted by such metadata), please read
the standards drafts, join this discussion, and weigh in now while the
topic is hot.

-- 
 \        ?The industrial system is profoundly dependent on commercial |
  `\   television and could not exist in its present form without it.? |
_o__)        ?John Kenneth Galbraith, _The New Industrial State_, 1967 |
Ben Finney


From david.lyon at preisshare.net  Tue Jul  7 16:54:45 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 07 Jul 2009 10:54:45 -0400
Subject: [Distutils] Python package distribution standards
In-Reply-To: <87bpnwpr26.fsf@benfinney.id.au>
References: <87bpnwpr26.fsf@benfinney.id.au>
Message-ID: <b4a1fe6677a33fe4c1b2e525178685b1@preisshare.net>

On Tue, 07 Jul 2009 23:21:05 +1000, Ben Finney

> If you feel you have constructive input on how Python's package
> distribution metadata can be improved for the needs of OS packagers
> (along with other needs being targeted by such metadata), please read
> the standards drafts, join this discussion, and weigh in now while the
> topic is hot.

The metadata is there for the reading.....

What I've found so far is that it can exist in many places but eventually
it can be found, loaded and displayed (in a package manager gui)

(thanks python globs... + two nights of coding and done)

Like why after so many years of setuptools we can't read metadata
I'll never know - but that's not my problem....

Basically, you're suggesting that all effort should go into the *nix
side of packaging, supporting OS style packaging....

But what if people aren't using *nix.... and are using Windows?

Let me describe it more succinctly.... in *nix terms...

You're placing a bias on package installation within:

 - /usr/lib/pythonX.X/site-packages

That's very deep in a *nix operating system.. H*ll that is the
operating system.....

You want the packages to easily be built for say ubuntu.. and 
sent to packages.ubuntu.com or wherever...

But in *nix, there's another place being completely ignored...

The python back-yard...

That is:

 - /usr/local/lib/pythonX.X/site-packages

Point?

this directory is *our workbench*, not /usr/lib....

If everybody gets drawn off to work on OS packaging nobody
gets left to work on local packaging stuff. And all the
packages keep on being stale.. and blah blah blah

Looking at PEP-376... who needs the metadata?

A Package Manager? maybe.. but if there's been no api
it can go find everything it needs.... it's hanging
around somewhere... takes 0.1 seconds to find..

Then there is setup.py and the metadata.....

It's crazy generating the metadata from the setup.py....

It is far more logical to generate the setup.py from the
metadata...... if you think about it...

And then.....

We're led to ask the question.. why have a setup.py at all...?

(What really does it accomplish apart from cause headaches)

Just use the api and the metadata to install your packages...

A side benefit, every time there is a build.. the version/build
numbers get auto-incremented in the metadata... Things start
to make more sense..

On topic.. which has run out of time now... is PYPI....

My suggestions on improving the metadata are really simple..

 - Specify either Package or App

 - specify documentation

 - specify program shortcuts (in the desktop x-plat for win+mac+lin)

 - kill setup.py (except for exceptional circumstances)

 - build for more python versions

 - build for more operating systems

 - assist developers with -1 and -2

David














From josepharmbruster at gmail.com  Tue Jul  7 19:05:58 2009
From: josepharmbruster at gmail.com (Joseph Armbruster)
Date: Tue, 7 Jul 2009 13:05:58 -0400
Subject: [Distutils] setuptools inquiry
Message-ID: <938f42d70907071005i3df1b26fnb1aff89b9fcd2aff@mail.gmail.com>

Phillip,

I just downloaded setuptools from:
http://svn.python.org/projects/sandbox/trunk/setuptools

I am interested in creating the windows .exe installer but could not find
any materials for doing so in the repo.  Is there someplace else I should be
looking?

In addition, there are two binary utilities, cli.exe and gui.exe that are
distributed with the tool.  Is the source for these utilities stored
somewhere on svn.python.org?


Thank You in advance,
Joseph Armbruster
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090707/6d7228f1/attachment.htm>

From josepharmbruster at gmail.com  Tue Jul  7 19:56:14 2009
From: josepharmbruster at gmail.com (Joseph Armbruster)
Date: Tue, 7 Jul 2009 13:56:14 -0400
Subject: [Distutils] windows installer questions
Message-ID: <938f42d70907071056s615f1ba2w14b4838b3e6c1ce7@mail.gmail.com>

All,

Who builds the setuptools .exe installer that is available via
pypi.python.org?
Is the source for the installer published somewhere (nsis/.msi/etc..)?

I'm interested in building an installer for this myself and would like to
obtain the installer source if possible.

In addition, there are two binaries that are part of the source tree,
cli.exe and gui.exe.
Where can the source for these utilities be found?

I checked the svn longs and could not find a hint as to where they came
from.

Thank You in advance,
Joseph Armbruster
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090707/1a9a34da/attachment.htm>

From pje at telecommunity.com  Tue Jul  7 20:38:06 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 07 Jul 2009 14:38:06 -0400
Subject: [Distutils] setuptools inquiry
In-Reply-To: <938f42d70907071005i3df1b26fnb1aff89b9fcd2aff@mail.gmail.co
 m>
References: <938f42d70907071005i3df1b26fnb1aff89b9fcd2aff@mail.gmail.com>
Message-ID: <20090707183507.4683A3A407B@sparrow.telecommunity.com>

At 01:05 PM 7/7/2009 -0400, Joseph Armbruster wrote:
>I am interested in creating the windows .exe installer but could not 
>find any materials for doing so in the repo.  Is there someplace 
>else I should be looking?

python setup.py bdist_wininst 


From david.lyon at preisshare.net  Wed Jul  8 05:25:53 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 07 Jul 2009 23:25:53 -0400
Subject: [Distutils] random testing..
In-Reply-To: <20090707183507.4683A3A407B@sparrow.telecommunity.com>
References: <938f42d70907071005i3df1b26fnb1aff89b9fcd2aff@mail.gmail.com>
	<20090707183507.4683A3A407B@sparrow.telecommunity.com>
Message-ID: <6df6bfd1196dade2d850f1d32c4f8936@preisshare.net>


Platform: Windows 2K, Python2.6

Running installer ... C:\Python26\scripts\easy_install.exe asciiporn
ERRORS: Traceback (most recent call last):
  File "C:\Python26\scripts\easy_install-script.py", line 8, in <module>
    load_entry_point('setuptools==0.6c9', 'console_scripts',
'easy_install')()
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 1671, in main
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 1659, in with_ei_usage
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 1675, in <lambda>
  File "C:\Python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "C:\Python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 211, in run
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 446, in easy_install
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 476, in install_item
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 655, in install_eggs
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 930, in build_and_install
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\command\easy_install.py",
line 919, in run_setup
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\sandbox.py",
line 27, in run_setup
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\sandbox.py",
line 63, in run
  File
"C:\Python26\lib\site-packages\setuptools-0.6c9-py2.6.egg\setuptools\sandbox.py",
line 29, in <lambda>
  File "setup.py", line 466, in <module>
    
  File "setup.py", line 464, in missing_dependency
    
Exception: 

  asciiporn requires Python Imaging Library
  please download & install Python Imaging Library from:

  http://www.pythonware.com/products/pil/

  or from ur os distro.
  then quit this shell & rerun setup in a new shell


Searching for asciiporn
Reading http://pypi.python.org/simple/asciiporn/
Reading http://www-rcf.usc.edu/~kaizhu/work/asciiporn
Best match: asciiporn 2009.05.01
Downloading
http://pypi.python.org/packages/source/a/asciiporn/asciiporn-2009.05.01.tar.gz#md5=4ee8276f6e0bb3f3b7fb9b089d4a26e2
Processing asciiporn-2009.05.01.tar.gz
Running asciiporn-2009.05.01\setup.py -q bdist_egg --dist-dir
c:\docume~1\dl\locals~1\temp\easy_install-tnmnuu\asciiporn-2009.05.01\egg-dist-tmp-fghpam

  asciiporn requires:
    Python 2.6
    Python Imaging Library
    numpy
  make sure these packages are installed before running setup


From christianmbrodbeck at gmail.com  Wed Jul  8 16:39:27 2009
From: christianmbrodbeck at gmail.com (Christian Brodbeck)
Date: Wed, 8 Jul 2009 16:39:27 +0200
Subject: [Distutils] easy_install MySQL_python error
Message-ID: <40C7A79F-2EC9-429A-8F41-ED3D6C8DC9C7@gmail.com>

Hi there,

I am trying to install MySQL_python, but I get the following error:  
"EnvironmentError: mysql_config not found" (complete terminal readout  
below). I am using python 2.5 and the latest version of os X on a  
macbook. I could not find anything in the mailinglist archive (using  
google's site: search - is there a better way to search it?) and  
easy_install page advises to write to this mailinglist if there are  
problems, so I was wondering if anyone could help.

Thanks,
Christian





Christian$ sudo easy_install-2.5 MySQL_python
Password:
Searching for MySQL-python
Reading http://pypi.python.org/simple/MySQL_python/
Reading http://sourceforge.net/projects/mysql-python
Best match: MySQL-python 1.2.3c1
Downloading http://osdn.dl.sourceforge.net/sourceforge/mysql-python/MySQL-python-1.2.3c1.tar.gz
Processing MySQL-python-1.2.3c1.tar.gz
Running MySQL-python-1.2.3c1/setup.py -q bdist_egg --dist-dir /tmp/ 
easy_install-xtH6un/MySQL-python-1.2.3c1/egg-dist-tmp-8rW4eF
sh: mysql_config: command not found
Traceback (most recent call last):
   File "/opt/local/bin/easy_install-2.5", line 8, in <module>
     load_entry_point('setuptools==0.6c9', 'console_scripts',  
'easy_install-2.5')()
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 1671, in main

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 1659, in  
with_ei_usage

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 1675, in <lambda>

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/distutils/core.py", line 151, in setup
     dist.run_commands()
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/distutils/dist.py", line 986, in run_commands
     self.run_command(cmd)
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/distutils/dist.py", line 1006, in run_command
     cmd_obj.run()
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 211, in run

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 446, in easy_install

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 476, in install_item

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 655, in install_eggs

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 930, in  
build_and_install

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/easy_install.py", line 919, in run_setup

   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/ 
sandbox.py", line 27, in run_setup
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/ 
sandbox.py", line 63, in run
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/ 
sandbox.py", line 29, in <lambda>
   File "setup.py", line 15, in <module>
     setup(name="pbrain",
   File "/tmp/easy_install-xtH6un/MySQL-python-1.2.3c1/ 
setup_posix.py", line 43, in get_config
   File "/tmp/easy_install-xtH6un/MySQL-python-1.2.3c1/ 
setup_posix.py", line 24, in mysql_config
EnvironmentError: mysql_config not found


From tseaver at palladion.com  Wed Jul  8 17:21:55 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 08 Jul 2009 11:21:55 -0400
Subject: [Distutils] easy_install MySQL_python error
In-Reply-To: <40C7A79F-2EC9-429A-8F41-ED3D6C8DC9C7@gmail.com>
References: <40C7A79F-2EC9-429A-8F41-ED3D6C8DC9C7@gmail.com>
Message-ID: <h32dim$rc6$1@ger.gmane.org>

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

Christian Brodbeck wrote:
> Hi there,
> 
> I am trying to install MySQL_python, but I get the following error:  
> "EnvironmentError: mysql_config not found" (complete terminal readout  
> below). I am using python 2.5 and the latest version of os X on a  
> macbook. I could not find anything in the mailinglist archive (using  
> google's site: search - is there a better way to search it?) and  
> easy_install page advises to write to this mailinglist if there are  
> problems, so I was wondering if anyone could help.

Likely you need to arrange for the 'mysql_config' utility to be on the
PATH when you run the script:  if the utility doesn't exist, that would
indicate that you need to install the MySQL client libraries for your
system.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKVLmT+gerLs4ltQ4RArZ+AKCWX7dDu3j+1Vhmi9JnFRlu3Mv1jACfXyE4
fxME8cUTC5qZQeQGk3xlXyI=
=m9wj
-----END PGP SIGNATURE-----


From nad at acm.org  Wed Jul  8 22:04:30 2009
From: nad at acm.org (Ned Deily)
Date: Wed, 08 Jul 2009 13:04:30 -0700
Subject: [Distutils] easy_install MySQL_python error
References: <40C7A79F-2EC9-429A-8F41-ED3D6C8DC9C7@gmail.com>
	<h32dim$rc6$1@ger.gmane.org>
Message-ID: <nad-2864F5.13043008072009@news.gmane.org>

In article <h32dim$rc6$1 at ger.gmane.org>,
 Tres Seaver <tseaver at palladion.com> wrote:
> Christian Brodbeck wrote:
> > I am trying to install MySQL_python, but I get the following error:  
> > "EnvironmentError: mysql_config not found" (complete terminal readout  
> > below). I am using python 2.5 and the latest version of os X on a  
> > macbook. I could not find anything in the mailinglist archive (using  
> > google's site: search - is there a better way to search it?) and  
> > easy_install page advises to write to this mailinglist if there are  
> > problems, so I was wondering if anyone could help.
> 
> Likely you need to arrange for the 'mysql_config' utility to be on the
> PATH when you run the script:  if the utility doesn't exist, that would
> indicate that you need to install the MySQL client libraries for your
> system.

Also, from the /opt/local/Library path in the traceback, it appears that 
you're using the MacPorts python2.5.  If you don't need the absolutely 
latest MySQL_python, you should be able to install everything you need 
using MacPorts:

   sudo port install py25-mysql

That should pull in all the dependencies, including the necessary MySQL 
client libs.

-- 
 Ned Deily,
 nad at acm.org


From christianmbrodbeck at gmail.com  Wed Jul  8 23:23:48 2009
From: christianmbrodbeck at gmail.com (Christian Brodbeck)
Date: Wed, 8 Jul 2009 23:23:48 +0200
Subject: [Distutils] easy_install MySQL_python error
In-Reply-To: <nad-2864F5.13043008072009@news.gmane.org>
References: <40C7A79F-2EC9-429A-8F41-ED3D6C8DC9C7@gmail.com>
	<h32dim$rc6$1@ger.gmane.org>
	<nad-2864F5.13043008072009@news.gmane.org>
Message-ID: <46363F1E-9BF1-404C-B83E-DE8690BCEC54@gmail.com>

Thanks to Tres and Ned for the quick help, installing form macports  
did get me a step further. Now it's having another problem which I  
can't find a solution for (readout below), but that probably belongs  
to the macports mailing list.

Cheers!
Christian


Python 2.5.4 (r254:67916, Jul  3 2009, 03:05:02)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import MySQLdb
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/MySQL_python-1.2.3c1-py2.5-linux-i686.egg/ 
MySQLdb/__init__.py", line 19, in <module>
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/MySQL_python-1.2.3c1-py2.5-linux-i686.egg/ 
_mysql.py", line 7, in <module>
   File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/MySQL_python-1.2.3c1-py2.5-linux-i686.egg/ 
_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/Christian/.python-eggs/MySQL_python-1.2.3c1- 
py2.5-linux-i686.egg-tmp/_mysql.so, 2): no suitable image found.  Did  
find:
	/Users/Christian/.python-eggs/MySQL_python-1.2.3c1-py2.5-linux- 
i686.egg-tmp/_mysql.so: unknown file type, first eight bytes: 0x7F  
0x45 0x4C 0x46 0x01 0x01 0x01 0x00
 >>>



On Jul 8, 2009, at 10:04 PM, Ned Deily wrote:

> In article <h32dim$rc6$1 at ger.gmane.org>,
> Tres Seaver <tseaver at palladion.com> wrote:
>> Christian Brodbeck wrote:
>>> I am trying to install MySQL_python, but I get the following error:
>>> "EnvironmentError: mysql_config not found" (complete terminal  
>>> readout
>>> below). I am using python 2.5 and the latest version of os X on a
>>> macbook. I could not find anything in the mailinglist archive (using
>>> google's site: search - is there a better way to search it?) and
>>> easy_install page advises to write to this mailinglist if there are
>>> problems, so I was wondering if anyone could help.
>>
>> Likely you need to arrange for the 'mysql_config' utility to be on  
>> the
>> PATH when you run the script:  if the utility doesn't exist, that  
>> would
>> indicate that you need to install the MySQL client libraries for your
>> system.
>
> Also, from the /opt/local/Library path in the traceback, it appears  
> that
> you're using the MacPorts python2.5.  If you don't need the absolutely
> latest MySQL_python, you should be able to install everything you need
> using MacPorts:
>
>   sudo port install py25-mysql
>
> That should pull in all the dependencies, including the necessary  
> MySQL
> client libs.
>
> -- 
> Ned Deily,
> nad at acm.org
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From p.f.moore at gmail.com  Thu Jul  9 10:32:52 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 9 Jul 2009 09:32:52 +0100
Subject: [Distutils] [Python-Dev] PEP 376 - Open questions
In-Reply-To: <94bdd2610907090122x12a3f25s13bba018240f331d@mail.gmail.com>
References: <79990c6b0907061138o3fe12709vc39876256f38e6fe@mail.gmail.com>
	<loom.20090708T121713-308@post.gmane.org>
	<4A54984D.4020305@trueblade.com>
	<79990c6b0907080628r50e569aaue0261c422d2710c@mail.gmail.com>
	<4A54AF4F.9080800@trueblade.com>
	<79990c6b0907080757y576599bav3aa8c93904722e07@mail.gmail.com>
	<20090708151647.9E0703A407B@sparrow.telecommunity.com>
	<79990c6b0907080922v4242672fg1abb3eb02a8004d9@mail.gmail.com>
	<op.uwr1phe9brrvlq@double>
	<94bdd2610907090122x12a3f25s13bba018240f331d@mail.gmail.com>
Message-ID: <79990c6b0907090132m52db8771p463e00ec4d8db04a@mail.gmail.com>

2009/7/9 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
> Ratnakumar<SridharR at activestate.com> wrote:
>> Other than easy_install/pip, there is also PyPM which is being developed at
>> ActiveState. PyPM is the Python package manager much like what ppm is for
>> ActivePerl.
>>
>
> Great ! besides the RECORD file, anything remark on the PEP from a
> PyPM point of view ?
> Once Paul has finished to work on the PEP 302 part of the prototype,
> maybe we could try it out
> on PyPM to see how it fits ?

Note: the "pkgutil2" implementation I pushed to Tarek's bitbucket
repository a day or so ago includes PEP 302 support (using a few new
finder methods, as proposed). It's ready to go now. It's as compliant
with the PEP as possible given the outstanding questions (I've
implemented some things on the basis of what I thought was consensus
here, even though the PEP has not changed yet to reflect that - using
"metadata" rather than "egginfo" in method names, and removing the
local= parameter from some of the methods, being the 2 I can recall
immediately).

I'd like to add a test case using a non-standard PEP 302 importer, but
that's a small detail.

There are bound to be holes in the implementation, especially around
the areas of the open questions that started this thread. I'd
appreciate feedback, but I'm not expecting to make code changes until
the PEP is changed - it's too much like trying to hit a moving target
at the moment!

Paul.

PS I've added distutils-sig back into the cc list. Please keep "PEP
376" in the subject of any subsequent threads on that list if you want
my input, as I don't follow all the traffic on there.

From david at ar.media.kyoto-u.ac.jp  Thu Jul  9 11:04:46 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 09 Jul 2009 18:04:46 +0900
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
Message-ID: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>

I am moving this discussion out of python-dev, as it is outside the
thread topic, but an important discussion nonetheless:

2009/7/9 Eric Smith <eric at trueblade.com <mailto:eric at trueblade.com>>:
> P.J. Eby wrote:
>>>
>>> ISTM that the problem that it solves is uninstall in the absence of
>>> the original installer.
>>
>> Or uninstall where the installer is "setup.py install", actually.
>
> I think we need to move away from "setup.py install". It's the
antithesis of
> static metadata. setup.py needs to go away.
>
> If we have a static metadata file called, say "setup.info
<http://setup.info>", then I'd like to
> see:
> "bdist_rpm setup.info <http://setup.info>" produce a .rpm
> "bdist_msi setup.info <http://setup.info>" produce a .msi
> "bdist_deb setup.info <http://setup.info>" produce a .deb
> "bdist_egg setup.info <http://setup.info>" produce a .egg
> and so on.
>
> There might be a library (and I call dibs on the name "distlib" :) that
> provides support routines to parse setup.info <http://setup.info>, but
there's no framework
> involved. And no need for a plugin system.

I too would like to see this kind of system, and have been thinking
quite a bit about it. Looks like I am not the only one. P.J. Eby
mentioned  that designing such a thing by comity is not likely to work
well. But I think we can inspire ourselves from existing designs.

One such system is the haskell build system, cabal:

http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/

Among other things:
    - It is based on a mostly static file, parsed by the cabal package.
    - Installation of 'libraries' (equivalent of our modules and
packages) and executables (scripts) is covered.
    - Debug and normal build for compiled extensions is handled,
metadata as well. Simple conditional for different platforms support.
    - Optional haskell code ala setup.py can be executed for the
complicated cases.
    - optional integration with source control systems
    - it has command lines option compatible with autotools ->
FHS-compliant packages would be easier as well.
    - cabal is integrated with a db of packages, to form hackage: it
handles installations, dependency handling (but not uninstallation it
seems). I don't have much experience with this part of the design, though.

I think it is a good and strong baseline as a starting point. Reusing
this design in a python equivalent should be much easier than starting a
system from scratch. Under this scheme, backward compatibility with
distutils could be attempted by automatically converting setup.py files
to this system, and vice et versa. The development could be gradual,
reusing some parts of distutils during the development phase.

My own motivation comes from my experience in maintaining and
'improving' distutils extensions used in numpy and scipy. I have a
pretty good idea of the flaws and internals of distutils, and care about
every platform that numpy supports (that is most if not all the ones
supported by python).

cheers,

David

From az at zitc.de  Thu Jul  9 11:05:24 2009
From: az at zitc.de (Andreas Zeidler)
Date: Thu, 09 Jul 2009 11:05:24 +0200
Subject: [Distutils] [Buildout] Download API and extends caching -
	please review
In-Reply-To: <89FA5D8A-970A-49F2-95F9-E1C0B823B194@zope.com>
References: <pan.2009.06.11.06.55.07.449140@ID-174572.user.uni-berlin.de>	<pan.2009.06.24.15.51.01.221130@ID-174572.user.uni-berlin.de>
	<89FA5D8A-970A-49F2-95F9-E1C0B823B194@zope.com>
Message-ID: <h34bsk$9cj$1@ger.gmane.org>

Jim Fulton wrote:
> On Jun 24, 2009, at 1:04 PM, Thomas Lotze wrote:
>> I'd like to ask again for a code review of both projects' feature 
>> branches
>> (the recipe's being at
>> <svn://svn.zope.org/repos/main/zc.buildout/branches/tlotze-download-api>)
>> before merging them to the respective trunks. Jim, as you've responded to
>> questions on the subject before, would you be willing and find some time
>> to have a look at the code?
> 
> Yup

this would be a great new feature to see merged and released! ;)  plone 
buildouts have started "extending" remote `version.cfg`s for some time 
now, and full offline capabilities would make this so much more 
convenient...

cheers,


andi

-- 
zeidler it consulting - http://zitc.de/ - info at zitc.de
friedelstra?e 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.3rc4 released! -- http://plone.org/products/plone/


From david.lyon at preisshare.net  Thu Jul  9 14:50:49 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 09 Jul 2009 08:50:49 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
Message-ID: <5493920e75be4f5e1258a369d22fc78f@preisshare.net>


On Thu, 09 Jul 2009 18:04:46 +0900, David Cournapeau
> I am moving this discussion out of python-dev, as it is outside the
> thread topic, but an important discussion nonetheless:
..
>> I think we need to move away from "setup.py install". It's the
> antithesis of static metadata. setup.py needs to go away.
>>
>> If we have a static metadata file called, say "setup.info
> <http://setup.info>", then I'd like to
>> see:
>> "bdist_rpm setup.info <http://setup.info>" produce a .rpm
>> "bdist_msi setup.info <http://setup.info>" produce a .msi
>> "bdist_deb setup.info <http://setup.info>" produce a .deb
>> "bdist_egg setup.info <http://setup.info>" produce a .egg
>> and so on.

Makes perfect sense..

> One such system is the haskell build system, cabal:
> 
> http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/

Yes, It is well laid out..

> I think it is a good and strong baseline as a starting point. Reusing
> this design in a python equivalent should be much easier than starting a
> system from scratch. 

Yes I agree.

> Under this scheme, backward compatibility with
> distutils could be attempted by automatically converting setup.py files
> to this system, and vice et versa. 

Conversion is a *really* good option.

After examining a small sample of around 120 packages so far, I can
make a generalisation that packages always seem to live either in
their own directory or an .EGG within a package path.

What this means, in simple terms, is that most* packages can be
installed into python simply by a) copying the egg or extracting
the archive (into site-packages) then b) then updating the '
system' (pth, site.path etc)

I concede.. setup.py does look a little magical..

But really, it does no magic.. 

little more than shutil.copytree() and a .pth update...

ok - I'm over simplifying.. but not by much.

My point ? A copytree command is still good for doing a package
installation imho. It means you don't have to worry about specifying
all the files that you want in the package and so forth. That means
a lot less work for the package developer.. a lot less..

PEP 376 on the other hand, does make a lot of good suggestions 
for the internal package format, deinstallation and so forth.

Let's even think about throwing it away yet...

However, he only chronic logic failure that remains now, is 
package dependencies.

That needs to be in metadata somewhere. Easily accessible. Maybe 
it already is. But I thought it was going to be in setup.py. 

Before a package is downloaded, its dependencies need to be 
determined. Not after.. by looking in the setup.py

The easiest solution imho is to extend the PKG-INFO files.

This metadata is on pypi and available via rpc. That's good.

Lets extend it..

So instead of generating the PKG-INFO file (somewhere) as a
result of setup.py running, have the developer or build tool 
(gui2exe,boa,eclipse etc) make it as the first step.

Then, for the 95% of cases that don't do tricky stuff 
with their setup.py, it will mean that setup.py isn't
required.

So let me summarise it all, with one addtion:

 - specify package depends in the PKG-INFO file
   (so we can determine dependencies before download)

 - there's no need for a package manifest (Adds extra 
   developer work - and the system can so easily remove 
   the .egg or directory tree. Why punish the developer)

 - there's no need for setup.py except in complex
   cases. Replace with a post_setup.py

 - (specify) a "doc" directory inside a package to
   hold documentation.

 - keep all the other good things in PEP 376

In closing, I can see all the good work done by lots of people
over time. PEP 376 looks like a pretty challenging piece of work
but its better that it goes ahead rather than the other option in
which nothing gets done.

David





From p.f.moore at gmail.com  Thu Jul  9 15:45:22 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 9 Jul 2009 14:45:22 +0100
Subject: [Distutils] [Python-Dev] PEP 376 - Open questions
In-Reply-To: <79990c6b0907090132m52db8771p463e00ec4d8db04a@mail.gmail.com>
References: <79990c6b0907061138o3fe12709vc39876256f38e6fe@mail.gmail.com>
	<4A54984D.4020305@trueblade.com>
	<79990c6b0907080628r50e569aaue0261c422d2710c@mail.gmail.com>
	<4A54AF4F.9080800@trueblade.com>
	<79990c6b0907080757y576599bav3aa8c93904722e07@mail.gmail.com>
	<20090708151647.9E0703A407B@sparrow.telecommunity.com>
	<79990c6b0907080922v4242672fg1abb3eb02a8004d9@mail.gmail.com>
	<op.uwr1phe9brrvlq@double>
	<94bdd2610907090122x12a3f25s13bba018240f331d@mail.gmail.com>
	<79990c6b0907090132m52db8771p463e00ec4d8db04a@mail.gmail.com>
Message-ID: <79990c6b0907090645q7468f0dj4b32e89f70306022@mail.gmail.com>

2009/7/9 Paul Moore <p.f.moore at gmail.com>:
> I'd like to add a test case using a non-standard PEP 302 importer, but
> that's a small detail.

I've just pushed a PEP 302 importer test case.

The level of boilerplate needed is a bit painful, but it's fine as a
prototype. When we get consensus on some of the remaining details,
I'll tidy up the implementation and streamline the importer
requirements at that time.

Paul.

From pje at telecommunity.com  Thu Jul  9 19:27:56 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 09 Jul 2009 13:27:56 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
Message-ID: <20090709172515.1801C3A407B@sparrow.telecommunity.com>

At 06:04 PM 7/9/2009 +0900, David Cournapeau wrote:
>I too would like to see this kind of system, and have been thinking
>quite a bit about it. Looks like I am not the only one.

For reference, here are some previous posts on this topic, suggesting 
some requirements and approaches:

http://mail.python.org/pipermail/distutils-sig/2008-October/010288.html
http://mail.python.org/pipermail/distutils-sig/2008-October/010343.html


>One such system is the haskell build system, cabal:
>
>http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/
>
>Among other things:
>     - It is based on a mostly static file, parsed by the cabal package.
>     - Installation of 'libraries' (equivalent of our modules and
>packages) and executables (scripts) is covered.
>     - Debug and normal build for compiled extensions is handled,
>metadata as well. Simple conditional for different platforms support.
>     - Optional haskell code ala setup.py can be executed for the
>complicated cases.
>     - optional integration with source control systems
>     - it has command lines option compatible with autotools ->
>FHS-compliant packages would be easier as well.
>     - cabal is integrated with a db of packages, to form hackage: it
>handles installations, dependency handling (but not uninstallation it
>seems). I don't have much experience with this part of the design, though.
>
>I think it is a good and strong baseline as a starting point.

If we really want setup.py to go away, the starting point *can't* be 
replacing it with something else, otherwise all of setup.py's 
requirements will infect it.  The BUILDS concept I proposed is a way 
of separating "build" features from "install" features in such a way 
that neither a standard build system *nor* a standard installation 
system are required in order to achieve interoperability.


>Under this scheme, backward compatibility with
>distutils could be attempted by automatically converting setup.py files
>to this system,

In BUILDS, I suggested that instead offering a distutils command to 
generate the metadata is a more implementable idea, with improved 
backward compatibility.


From eric at trueblade.com  Thu Jul  9 19:56:30 2009
From: eric at trueblade.com (Eric Smith)
Date: Thu, 09 Jul 2009 13:56:30 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <20090709172515.1801C3A407B@sparrow.telecommunity.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
Message-ID: <4A562F4E.60209@trueblade.com>

P.J. Eby wrote:
> At 06:04 PM 7/9/2009 +0900, David Cournapeau wrote:
>> I too would like to see this kind of system, and have been thinking
>> quite a bit about it. Looks like I am not the only one.
> 
> For reference, here are some previous posts on this topic, suggesting 
> some requirements and approaches:
> 
> http://mail.python.org/pipermail/distutils-sig/2008-October/010288.html
> http://mail.python.org/pipermail/distutils-sig/2008-October/010343.html

That's a great thread, thanks. I'm currently slogging through it.

It looks like it was winding up just as I joined distutils-sig. Had I 
seen it earlier, I'd have spent less time writing confusing emails recently!

Eric.

From david at ar.media.kyoto-u.ac.jp  Fri Jul 10 07:21:49 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 10 Jul 2009 14:21:49 +0900
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <20090709172515.1801C3A407B@sparrow.telecommunity.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
Message-ID: <4A56CFED.1030505@ar.media.kyoto-u.ac.jp>

P.J. Eby wrote:
> At 06:04 PM 7/9/2009 +0900, David Cournapeau wrote:
>> I too would like to see this kind of system, and have been thinking
>> quite a bit about it. Looks like I am not the only one.
>
> For reference, here are some previous posts on this topic, suggesting
> some requirements and approaches:
>
> http://mail.python.org/pipermail/distutils-sig/2008-October/010288.html
> http://mail.python.org/pipermail/distutils-sig/2008-October/010343.html
>

Thanks, I was looking for this discussion and could not find it.
Concerning your PEP proposition:

1: what's wrong with distutils. I have written a lengthy blog post about
this

http://cournape.wordpress.com/2009/04/01/python-packaging-a-few-observations-cabal-for-a-solution

but this is from the POV of a numpy/scipy developer, that it someone
with build needs beyond what most people will ever need - so this may
not appeal much to the whole community ? I can work on making this part
(distutils limitation) more formal if you think that would be useful,
but it does not address every issue. I have spent enough hours in
distutils and numpy.distutils to fill several PEP on distutils
annoyances, though :)

I think it is important that people who come from different communities
participate to this: people who work on web development have problems
which are mostly orthogonal to mine, but I get the impression that most
people on distutils-sig fall in this category.

2: I have no idea what wsgi is, so cannot comment on that

3: I agree with every goal stated there, but that would a PEP by itself,
no ?

4: Non-goal: I agree it should not be more complicated than it is now
with distutils.  And something which requires code changes outside
setup* would not only be unproductive, but really weird. One of my pet
project, numscons, shows that it is at least possible to do complicated
things outside distutils while involving no code change. Numscons is a
build tool which uses scons to build numpy and scipy; it works quite
well alongside the currently default tool based on distutils. You can
still build a numpy egg but using numscons to do the build part, you can
still use the develop command of setuptools, etc... but with scons
goodies (dependencies tracking, parallel builds, relatively painless
compiler flags customization, etc...). Both build infrastructures live
alongside without any problem (interop with distutils was a real PITA,
though).

5: I am not sure I understand why this is important. But then, as a non
native speaker, I am not in the best position anyway.

6: Do you mean you do not want to specify the metadata format for this
PEP, or that it should not be specified at all ?

7: See below

8: this should follow from 1 to 7, hopefully.


>
> If we really want setup.py to go away, the starting point *can't* be
> replacing it with something else, otherwise all of setup.py's
> requirements will infect it.

I am not sure I understand why. The way I have been thinking about this
was totally independent of distutils.

> The BUILDS concept I proposed is a way of separating "build" features
> from "install" features in such a way that neither a standard build
> system *nor* a standard installation system are required in order to
> achieve interoperability.

I think this part is uncontroversial, at least within people who want to
get rid of distutils :) I want the format to be powerful enough so that
it can be used to drive scons/waf, but obviously, a standard
implementation should be available without any such dependencies
(reusing distutils, at least at first). And of course, build and install
have to be as independent as possible. Distutils commands, their tight
coupling and imperative nature is by far the most annoying feature for
me. That's the source of much of distutils inflexibility.

> In BUILDS, I suggested that instead offering a distutils command to
> generate the metadata is a more implementable idea, with improved
> backward compatibility.

I think both can be useful. But generating the metadata from setup.py
cannot be the only solution: I want to tag my data so that packages
become FHS-compatible, I want to tag doc, generated sources vs templated
sources, etc... I understand that those things are unneeded in most
packages, though.

My main point was that the design for a purely static metadata which
support almost everything support by distutils already exists, has been
used for several years. One of the big mistake in distutils was the NIH.

David


From jim at zope.com  Fri Jul 10 12:48:35 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 10 Jul 2009 06:48:35 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
In-Reply-To: <4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
Message-ID: <3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>


On Jul 10, 2009, at 1:21 AM, David Cournapeau wrote:
> I think it is important that people who come from different  
> communities
> participate to this: people who work on web development have problems
> which are mostly orthogonal to mine, but I get the impression that  
> most
> people on distutils-sig fall in this category.


I don't think this perspective is reflective so much of web  
development as of application development.  Those of us who work on  
web applications need to provide working applications, often with hard  
scalability and reliability requirements.  We need to have control  
over how our applications are assembled so we can test known  
configurations and deploy them in a repeatable way. I think this would  
apply equally well to other sorts of applications.

Other folks are focussed on making libraries available to a large  
audience of developers and sometimes even end users.  For example, I  
guess that numpy and a lot of related tools are often or usually used  
in ad hoc one-off scripts for analysis of data.  Here flexibility is  
king.  System Python installations tend to serve these needs fairly  
well, especially if certain packages are tricky to install.  I often  
use matplotlib to do data analysis.  For this, using my ubuntu system  
Python's install works pretty well.  (This is partly because  
matplotlib is hard to install using normal egg mechanisms due to some  
sniffing it does.)

I agree that distutils is a mess and with your desire to separate  
concerns so that people can make progress in different areas without  
stepping on each other.

Jim

--
Jim Fulton
Zope Corporation



From david at ar.media.kyoto-u.ac.jp  Fri Jul 10 13:39:56 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 10 Jul 2009 20:39:56 +0900
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
Message-ID: <4A57288C.5060804@ar.media.kyoto-u.ac.jp>

Jim Fulton wrote:
>
> On Jul 10, 2009, at 1:21 AM, David Cournapeau wrote:
>> I think it is important that people who come from different communities
>> participate to this: people who work on web development have problems
>> which are mostly orthogonal to mine, but I get the impression that most
>> people on distutils-sig fall in this category.
>
>
> I don't think this perspective is reflective so much of web
> development as of application development.  Those of us who work on
> web applications need to provide working applications, often with hard
> scalability and reliability requirements.  We need to have control
> over how our applications are assembled so we can test known
> configurations and deploy them in a repeatable way. I think this would
> apply equally well to other sorts of applications.

>From what I read on this ML and elsewhere, it seems that there is a key
difference between 'webapp' and conventional applications deployment.
For webapp, the developer and the one who install is often the same
person, or at least a person with the same 'culture'. Normal
applications are targeted at end users and that makes for a lot of
difference.

On the end user side, .pth, eggs, sys.path hacks are a never-ending
source of troubles. For this reasons I am very skeptical about things
which encourage to install multiple, 'system-wide', packages, because it
does not go into the right direction for the end-user IMO. Not in the
current state of python and its import system, at least.

Controlling how the application is assembled, in which configuration is
important - but it should not have consequences on other packages. If an
application needs a very precise version of a given library, when
deployed, this library should not be visible to other packages IMHO. It
would make a lot of issues easier: uninstall support, 'queryable'
system, etc... would stay tractable. Because with the current situation
with eggs, sys.path hacks and co, I don't see how it is possible to have
a reliable system which support uninstall and rollback. That's already a
difficult enough problem as it is. Flexibility at this level is an
anti-goal.

>
> Other folks are focussed on making libraries available to a large
> audience of developers and sometimes even end users.  For example, I
> guess that numpy and a lot of related tools are often or usually used
> in ad hoc one-off scripts for analysis of data.

Yes, but it is also used as a basis for applications as well. One of the
thing I would really like to see is something ala cran (related to the
statistical software R), where people could, inside a numpy/scipy
environment, ask for a list of packages according to a list of keywords,
install them and uninstall them reliably. Without the need to be an
admin on their machine. From this perspective, I think there are a lot
of common goals with people who use easy_install and co. But at least I
am not satisfied with the current implementations and their lack of
robustness.

cheers,

David

From marius at pov.lt  Fri Jul 10 14:58:32 2009
From: marius at pov.lt (Marius Gedminas)
Date: Fri, 10 Jul 2009 15:58:32 +0300
Subject: [Distutils] Single version number
Message-ID: <20090710125832.GA12437@fridge.pov.lt>

What do people use to avoid repeating the version number both in the
setup.py as well as in application/library code, when the
application/library wants to know its own version number?

I've seen several options:

  1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
     do from yourpackage import __version__ and pass that to setup()

  2) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
     execfile(os.path.join(os.path.dirname(__file__), 'src', 'yourpackage',
                           '__init__.py'), d), then use d['__version__']

  3) put a file called version.txt in yourpackage/, have setup.py read
     it, make sure it's included in MANIFEST.in

  4) I don't recall actually ever seeing this one, but it should be
     possible to use pkg_resources to query the version of yourpackage
     (downside: if you're running from a source checkout without
     installing, you won't get the right version number)

Marius Gedminas
-- 
In order to get a loan you must first prove you don't need it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090710/0e928f39/attachment.pgp>

From p.f.moore at gmail.com  Fri Jul 10 15:20:53 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 10 Jul 2009 14:20:53 +0100
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
In-Reply-To: <3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
Message-ID: <79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>

2009/7/10 Jim Fulton <jim at zope.com>:
> I don't think this perspective is reflective so much of web development as
> of application development. ?Those of us who work on web applications need
> to provide working applications, often with hard scalability and reliability
> requirements. ?We need to have control over how our applications are
> assembled so we can test known configurations and deploy them in a
> repeatable way. I think this would apply equally well to other sorts of
> applications.

On Windows, desktop applications generally use py2exe. While there are
issues for the *developer* in setting up a reproducible build
environment for py2exe, for the *end user* the application is
self-contained and as such the sort of deployment issues I assume you
are referring to don't exist.

So, from my POV, all of the machinery to manage multiple versions of
packages, isolated environments, etc, is inapplicable.

I'm not saying this means such concerns are invalid, merely supporting
David's point that different communities have different issues.

Paul

From barry at python.org  Fri Jul 10 15:24:24 2009
From: barry at python.org (Barry Warsaw)
Date: Fri, 10 Jul 2009 09:24:24 -0400
Subject: [Distutils] Single version number
In-Reply-To: <20090710125832.GA12437@fridge.pov.lt>
References: <20090710125832.GA12437@fridge.pov.lt>
Message-ID: <C4D668A2-139A-4E91-91EC-059223852147@python.org>

On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:

> What do people use to avoid repeating the version number both in the
> setup.py as well as in application/library code, when the
> application/library wants to know its own version number?
>
> I've seen several options:
>
>  1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>     do from yourpackage import __version__ and pass that to setup()

This is generally what I do and it seems to work pretty well for me.   
I remember talking with Gary Poster about some problems with this,  
related to our open source lazr packages, but I don't recall the  
details.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090710/2113260d/attachment.pgp>

From exarkun at divmod.com  Fri Jul 10 15:29:51 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Fri, 10 Jul 2009 09:29:51 -0400
Subject: [Distutils] Single version number
In-Reply-To: <20090710125832.GA12437@fridge.pov.lt>
Message-ID: <20090710132951.2543.74752654.divmod.quotient.843@henry.divmod.com>

On Fri, 10 Jul 2009 15:58:32 +0300, Marius Gedminas <marius at pov.lt> wrote:
>What do people use to avoid repeating the version number both in the
>setup.py as well as in application/library code, when the
>application/library wants to know its own version number?
>
>I've seen several options:
>
>  1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>     do from yourpackage import __version__ and pass that to setup()
>
>  2) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>     execfile(os.path.join(os.path.dirname(__file__), 'src', 'yourpackage',
>                           '__init__.py'), d), then use d['__version__']
>
>  3) put a file called version.txt in yourpackage/, have setup.py read
>     it, make sure it's included in MANIFEST.in
>
>  4) I don't recall actually ever seeing this one, but it should be
>     possible to use pkg_resources to query the version of yourpackage
>     (downside: if you're running from a source checkout without
>     installing, you won't get the right version number)
>

There was some discussion of this here a couple months ago:

http://mail.python.org/pipermail/distutils-sig/2009-May/011913.html

Jean-Paul

From jim at zope.com  Fri Jul 10 15:44:24 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 10 Jul 2009 09:44:24 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
In-Reply-To: <4A57288C.5060804@ar.media.kyoto-u.ac.jp>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<4A57288C.5060804@ar.media.kyoto-u.ac.jp>
Message-ID: <46D0C65E-1030-40D1-96CB-88B42BC48E0A@zope.com>


On Jul 10, 2009, at 7:39 AM, David Cournapeau wrote:

> Jim Fulton wrote:
>>
>> On Jul 10, 2009, at 1:21 AM, David Cournapeau wrote:
>>> I think it is important that people who come from different  
>>> communities
>>> participate to this: people who work on web development have  
>>> problems
>>> which are mostly orthogonal to mine, but I get the impression that  
>>> most
>>> people on distutils-sig fall in this category.
>>
>>
>> I don't think this perspective is reflective so much of web
>> development as of application development.  Those of us who work on
>> web applications need to provide working applications, often with  
>> hard
>> scalability and reliability requirements.  We need to have control
>> over how our applications are assembled so we can test known
>> configurations and deploy them in a repeatable way. I think this  
>> would
>> apply equally well to other sorts of applications.
>
>> From what I read on this ML and elsewhere, it seems that there is a  
>> key
> difference between 'webapp' and conventional applications deployment.
> For webapp, the developer and the one who install is often the same
> person, or at least a person with the same 'culture'. Normal
> applications are targeted at end users and that makes for a lot of
> difference.

I don't think that makes much difference wrt this discussion. See below.

> On the end user side, .pth, eggs, sys.path hacks are a never-ending
> source of troubles. For this reasons I am very skeptical about things
> which encourage to install multiple, 'system-wide', packages,  
> because it
> does not go into the right direction for the end-user IMO. Not in the
> current state of python and its import system, at least.

I couldn't agree more.  As an application developer, I want to deliver  
complete self-enclosed applications.  I think that's why many  
application developers gravitate towards systems like buildout and  
virtualenv/pip. In fact, the tendency of system Python's to be  
customized by system packagers or system administrators often make the  
unsuitable for supporting applications.  When delivering applications  
to be installed by end users, I try to include everything needed,  
generally including Python. (I haven't been in this position for quite  
some time.)

> Controlling how the application is assembled, in which configuration  
> is
> important - but it should not have consequences on other packages.  
> If an
> application needs a very precise version of a given library, when
> deployed, this library should not be visible to other packages IMHO.

Agreed.

> It
> would make a lot of issues easier: uninstall support, 'queryable'
> system, etc... would stay tractable. Because with the current  
> situation
> with eggs, sys.path hacks and co, I don't see how it is possible to  
> have
> a reliable system which support uninstall and rollback. That's  
> already a
> difficult enough problem as it is. Flexibility at this level is an
> anti-goal.

Ironically, easy_install really doesn't meet the needs of application  
developers, at least not without virtualenv for many of these same  
reasons.

Really, many (I'd guess most) web developers who gravitate to  
setuptools are drawn by the ability to express and manage  
dependencies.  They use tools like buildout or virtualenv that avoid  
the pitfalls you mention above. I suspect you have more in common with  
us than you think. :)

>> Other folks are focussed on making libraries available to a large
>> audience of developers and sometimes even end users.  For example, I
>> guess that numpy and a lot of related tools are often or usually used
>> in ad hoc one-off scripts for analysis of data.
>
> Yes, but it is also used as a basis for applications as well. One of  
> the
> thing I would really like to see is something ala cran (related to the
> statistical software R), where people could, inside a numpy/scipy
> environment, ask for a list of packages according to a list of  
> keywords,
> install them and uninstall them reliably. Without the need to be an
> admin on their machine. From this perspective, I think there are a lot
> of common goals with people who use easy_install and co. But at  
> least I
> am not satisfied with the current implementations and their lack of
> robustness.


Buildout gives you this.  I think pip with virtualenv might as well.   
(Buildout tends to fall down when packages make assumptions about the  
environment they're being installed into. Matplotlib has this  
problem.  I can't use it with a clean python. I have to use a Python  
that has numpy installed first because matplotlib sniffs for numpy.)

Jim

--
Jim Fulton
Zope Corporation



From jim at zope.com  Fri Jul 10 15:58:57 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 10 Jul 2009 09:58:57 -0400
Subject: [Distutils] Single version number
In-Reply-To: <20090710125832.GA12437@fridge.pov.lt>
References: <20090710125832.GA12437@fridge.pov.lt>
Message-ID: <98C3AFAD-A88F-42C9-A41A-2751C0742F81@zope.com>


On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:

> What do people use to avoid repeating the version number both in the
> setup.py as well as in application/library code, when the
> application/library wants to know its own version number?

...

>  4) I don't recall actually ever seeing this one, but it should be
>     possible to use pkg_resources to query the version of yourpackage

Yup. I've recommended this to folks in the past.


>     (downside: if you're running from a source checkout without
>     installing, you won't get the right version number)


I think you do as long as you run setup.py develop.

Jim

--
Jim Fulton
Zope Corporation



From jim at zope.com  Fri Jul 10 16:02:39 2009
From: jim at zope.com (Jim Fulton)
Date: Fri, 10 Jul 2009 10:02:39 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
In-Reply-To: <79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>
Message-ID: <5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com>


On Jul 10, 2009, at 9:20 AM, Paul Moore wrote:

> 2009/7/10 Jim Fulton <jim at zope.com>:
>> I don't think this perspective is reflective so much of web  
>> development as
>> of application development.  Those of us who work on web  
>> applications need
>> to provide working applications, often with hard scalability and  
>> reliability
>> requirements.  We need to have control over how our applications are
>> assembled so we can test known configurations and deploy them in a
>> repeatable way. I think this would apply equally well to other  
>> sorts of
>> applications.
>
> On Windows, desktop applications generally use py2exe. While there are
> issues for the *developer* in setting up a reproducible build
> environment for py2exe, for the *end user* the application is
> self-contained and as such the sort of deployment issues I assume you
> are referring to don't exist.

Actually, they exist and are addressed by py2exe.  On other platforms,  
they're addressed with tools like buildout, and virtualenv, and  
probably others.


> So, from my POV, all of the machinery to manage multiple versions of
> packages, isolated environments, etc, is inapplicable.
>
> I'm not saying this means such concerns are invalid, merely supporting
> David's point that different communities have different issues.


I don't disagree. I was really just pointing out that there isn't  
anythin special about web developers.  Really the need relates to  
application development.  That is, wen application developer's needs  
aren't really different from other application developers' needs.

Jim

--
Jim Fulton
Zope Corporation



From ben+python at benfinney.id.au  Fri Jul 10 16:31:25 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 11 Jul 2009 00:31:25 +1000
Subject: [Distutils] Single version number
References: <20090710125832.GA12437@fridge.pov.lt>
Message-ID: <87prc8mwxu.fsf@benfinney.id.au>

Marius Gedminas <marius at pov.lt> writes:

> What do people use to avoid repeating the version number both in the
> setup.py as well as in application/library code, when the
> application/library wants to know its own version number?
> 
> I've seen several options:
> 
>   1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>      do from yourpackage import __version__ and pass that to setup()

I do a variant on this: ?mainpackage/version.py? contains attributes for
version string, author details, copyright license, and so on. The
?mainpackage/__init__.py? docstring is parsed for the short and long
description; it often has the project URL too.

Using Bazaar, I can also (with ?bzr version-info --format=python?)
automatically generate an importable module with information about the
current VCS head revision; sometimes I use that to put the revision
number in the version string, or to get the end-year of a copyright year
range, etc.

-- 
 \          ?Judge: A law student who marks his own papers.? ?Henry L. |
  `\                                                           Mencken |
_o__)                                                                  |
Ben Finney
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090711/bf7d3e0c/attachment.pgp>

From gary.poster at canonical.com  Fri Jul 10 16:19:56 2009
From: gary.poster at canonical.com (Gary Poster)
Date: Fri, 10 Jul 2009 10:19:56 -0400
Subject: [Distutils] Single version number
In-Reply-To: <C4D668A2-139A-4E91-91EC-059223852147@python.org>
References: <20090710125832.GA12437@fridge.pov.lt>
	<C4D668A2-139A-4E91-91EC-059223852147@python.org>
Message-ID: <8B195995-FEB1-4640-9C61-286594317DC7@canonical.com>


On Jul 10, 2009, at 9:24 AM, Barry Warsaw wrote:

> On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:
>
>> What do people use to avoid repeating the version number both in the
>> setup.py as well as in application/library code, when the
>> application/library wants to know its own version number?
>>
>> I've seen several options:
>>
>> 1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>>    do from yourpackage import __version__ and pass that to setup()
>
> This is generally what I do and it seems to work pretty well for  
> me.  I remember talking with Gary Poster about some problems with  
> this, related to our open source lazr packages, but I don't recall  
> the details.

Basically, this means that your setup.py has to be able to import your  
package's __init__.py without any of the dependencies.

If your __init__.py only has a __version__ then this is fine.   
However, if you want your __init__ to reexport something to avoid  
clients having to do foo.foo.Foo-style imports from your package, or  
if you want to put any other code in your __init__ that might need  
dependencies, this breaks.

Gary


From Fadhley.Salim at uk.calyon.com  Fri Jul 10 17:24:45 2009
From: Fadhley.Salim at uk.calyon.com (Fadhley Salim)
Date: Fri, 10 Jul 2009 16:24:45 +0100
Subject: [Distutils] easy_install from behind an http proxy which requires
	authentication
In-Reply-To: <8B195995-FEB1-4640-9C61-286594317DC7@canonical.com>
References: <20090710125832.GA12437@fridge.pov.lt><C4D668A2-139A-4E91-91EC-059223852147@python.org>
	<8B195995-FEB1-4640-9C61-286594317DC7@canonical.com>
Message-ID: <EA01B91FBE6B7F49AAB45B11702937AD0A48E4@MXCU13MX1.MSX.CIB>

Dear Distutils SIG,

I note that easy_install can be used behind a proxy simply by setting
the "HTTP_PROXY" environment variable. 

But what of a proxy which requires authentication? Is there a technique
that will allow me to specify some kind of authentication credentials in
addition to the address & port of the proxy-server?

Thanks!

Sal
-------------- next part --------------
Disclaimer CALYON UK:
This email does not create a legal relationship between any member of the 
Cr=E9dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Comit=e9 des Etablissements de Cr=e9dit et des
Entreprises d'Investissement (CECEI) and supervised by the Commission Bancaire
in France and subject to limited regulation by the Financial Services Authority.
Details about the extent of our regulation by the Financial Services Authority
are available from us on request. Calyon is incorporated in France with limited
liability and registered in England & Wales. Registration number: FC008194.
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
Disclaimer CALYON France:
This message and/or any attachments is intended for the sole use of its addressee.
If you are not the addressee, please immediately notify the sender and then destroy the message.
As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Cr?dit Agricole CIB.
All rights reserved.

Ce message et ses pi?ces jointes est destin? ? l'usage exclusif de son destinataire.
Si vous recevez ce message par erreur, merci d'en aviser imm?diatement l'exp?diteur et de le d?truire ensuite.
Le pr?sent message pouvant ?tre alt?r? ? notre insu, CALYON Cr?dit Agricole CIB ne peut pas ?tre engag? par son contenu.
Tous droits r?serv?s.

From Fadhley.Salim at uk.calyon.com  Fri Jul 10 17:44:26 2009
From: Fadhley.Salim at uk.calyon.com (Fadhley Salim)
Date: Fri, 10 Jul 2009 16:44:26 +0100
Subject: [Distutils] easy_install from behind an http proxy which
	requires authentication
In-Reply-To: <EA01B91FBE6B7F49AAB45B11702937AD0A48E4@MXCU13MX1.MSX.CIB>
References: <20090710125832.GA12437@fridge.pov.lt><C4D668A2-139A-4E91-91EC-059223852147@python.org>
	<8B195995-FEB1-4640-9C61-286594317DC7@canonical.com>
	<EA01B91FBE6B7F49AAB45B11702937AD0A48E4@MXCU13MX1.MSX.CIB>
Message-ID: <EA01B91FBE6B7F49AAB45B11702937AD0A48E5@MXCU13MX1.MSX.CIB>

One additional fact:

I just discovered that the proxy uses NTLM authentication. There's a
plugin here: 
http://code.google.com/p/python-ntlm/

Which allows me to do an NTLM auth on the proxy server - but is there a
way to hook this auth-handler into easy_install, but is that even
possible? Could this be done as some kind of easy_install plugin? 

Sal

-----Original Message-----
From: Salim, Fadhley (CALYON) 
Sent: 10 July 2009 16:25
To: 'Distutils-SIG at python.org'
Subject: easy_install from behind an http proxy which requires
authentication

Dear Distutils SIG,

I note that easy_install can be used behind a proxy simply by setting
the "HTTP_PROXY" environment variable. 

But what of a proxy which requires authentication? Is there a technique
that will allow me to specify some kind of authentication credentials in
addition to the address & port of the proxy-server?

Thanks!

Sal
-------------- next part --------------
Disclaimer CALYON UK:
This email does not create a legal relationship between any member of the 
Cr=E9dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Comit=e9 des Etablissements de Cr=e9dit et des
Entreprises d'Investissement (CECEI) and supervised by the Commission Bancaire
in France and subject to limited regulation by the Financial Services Authority.
Details about the extent of our regulation by the Financial Services Authority
are available from us on request. Calyon is incorporated in France with limited
liability and registered in England & Wales. Registration number: FC008194.
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
Disclaimer CALYON France:
This message and/or any attachments is intended for the sole use of its addressee.
If you are not the addressee, please immediately notify the sender and then destroy the message.
As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Cr?dit Agricole CIB.
All rights reserved.

Ce message et ses pi?ces jointes est destin? ? l'usage exclusif de son destinataire.
Si vous recevez ce message par erreur, merci d'en aviser imm?diatement l'exp?diteur et de le d?truire ensuite.
Le pr?sent message pouvant ?tre alt?r? ? notre insu, CALYON Cr?dit Agricole CIB ne peut pas ?tre engag? par son contenu.
Tous droits r?serv?s.

From pje at telecommunity.com  Fri Jul 10 20:02:04 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 10 Jul 2009 14:02:04 -0400
Subject: [Distutils] Single version number
In-Reply-To: <20090710125832.GA12437@fridge.pov.lt>
References: <20090710125832.GA12437@fridge.pov.lt>
Message-ID: <20090710175902.0DB873A4754@sparrow.telecommunity.com>

At 03:58 PM 7/10/2009 +0300, Marius Gedminas wrote:
>What do people use to avoid repeating the version number both in the
>setup.py as well as in application/library code, when the
>application/library wants to know its own version number?
>
>I've seen several options:
>
>   1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>      do from yourpackage import __version__ and pass that to setup()
>
>   2) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>      execfile(os.path.join(os.path.dirname(__file__), 'src', 'yourpackage',
>                            '__init__.py'), d), then use d['__version__']
>
>   3) put a file called version.txt in yourpackage/, have setup.py read
>      it, make sure it's included in MANIFEST.in
>
>   4) I don't recall actually ever seeing this one, but it should be
>      possible to use pkg_resources to query the version of yourpackage
>      (downside: if you're running from a source checkout without
>      installing, you won't get the right version number)

You'll get the right version number if you use "setup.py develop" to 
add it to your global sys.path, and/or run "setup.py egg_info" to 
update the version info whenever it changes.

The simplest formula for retrieving the version in that case is 
'pkg_resources.require("Projectname")[0].version'. 


From pje at telecommunity.com  Fri Jul 10 20:07:18 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 10 Jul 2009 14:07:18 -0400
Subject: [Distutils] Single version number
In-Reply-To: <C4D668A2-139A-4E91-91EC-059223852147@python.org>
References: <20090710125832.GA12437@fridge.pov.lt>
	<C4D668A2-139A-4E91-91EC-059223852147@python.org>
Message-ID: <20090710180416.05B413A4755@sparrow.telecommunity.com>

At 09:24 AM 7/10/2009 -0400, Barry Warsaw wrote:
>On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:
>
>>What do people use to avoid repeating the version number both in the
>>setup.py as well as in application/library code, when the
>>application/library wants to know its own version number?
>>
>>I've seen several options:
>>
>>  1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>>     do from yourpackage import __version__ and pass that to setup()
>
>This is generally what I do and it seems to work pretty well for me.
>I remember talking with Gary Poster about some problems with this,
>related to our open source lazr packages, but I don't recall the
>details.

You'll have problems with this in the case where your __init__.py 
imports any of your dependencies (directly or indirectly), since it 
will effectively mean your setup.py will need its dependencies 
installed before it even says what they are.  ;-)

In such cases, putting a separate version.py or version.txt in the 
package, and execfile-ing it from setup.py is a better choice.

Personally, I don't even bother putting version info in the package 
code; that's what pkg_resources is for.  ;-)


From barry at python.org  Fri Jul 10 20:15:55 2009
From: barry at python.org (Barry Warsaw)
Date: Fri, 10 Jul 2009 14:15:55 -0400
Subject: [Distutils] Single version number
In-Reply-To: <20090710180416.05B413A4755@sparrow.telecommunity.com>
References: <20090710125832.GA12437@fridge.pov.lt>
	<C4D668A2-139A-4E91-91EC-059223852147@python.org>
	<20090710180416.05B413A4755@sparrow.telecommunity.com>
Message-ID: <1128C61B-B9C1-4AF6-B47A-F65008EEEF10@python.org>

On Jul 10, 2009, at 2:07 PM, P.J. Eby wrote:

> At 09:24 AM 7/10/2009 -0400, Barry Warsaw wrote:
>> On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:
>>
>>> What do people use to avoid repeating the version number both in the
>>> setup.py as well as in application/library code, when the
>>> application/library wants to know its own version number?
>>>
>>> I've seen several options:
>>>
>>> 1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>>>    do from yourpackage import __version__ and pass that to setup()
>>
>> This is generally what I do and it seems to work pretty well for me.
>> I remember talking with Gary Poster about some problems with this,
>> related to our open source lazr packages, but I don't recall the
>> details.
>
> You'll have problems with this in the case where your __init__.py  
> imports any of your dependencies (directly or indirectly), since it  
> will effectively mean your setup.py will need its dependencies  
> installed before it even says what they are.  ;-)
>
> In such cases, putting a separate version.py or version.txt in the  
> package, and execfile-ing it from setup.py is a better choice.
>
> Personally, I don't even bother putting version info in the package  
> code; that's what pkg_resources is for.  ;-)

Gotcha.  I generally don't put /anything/ except __version__ in my top  
level package __init__.py, but this is good to keep in mind.  Still, I  
should probably be using pkg_resources instead.

Thanks,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090710/99fd951a/attachment.pgp>

From floris.bruynooghe at gmail.com  Fri Jul 10 22:00:25 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Fri, 10 Jul 2009 21:00:25 +0100
Subject: [Distutils] Single version number
In-Reply-To: <8B195995-FEB1-4640-9C61-286594317DC7@canonical.com>
References: <20090710125832.GA12437@fridge.pov.lt>
	<C4D668A2-139A-4E91-91EC-059223852147@python.org>
	<8B195995-FEB1-4640-9C61-286594317DC7@canonical.com>
Message-ID: <20090710200025.GA9592@laurie.devork>

On Fri, Jul 10, 2009 at 10:19:56AM -0400, Gary Poster wrote:
>
> On Jul 10, 2009, at 9:24 AM, Barry Warsaw wrote:
>
>> On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:
>>
>>> What do people use to avoid repeating the version number both in the
>>> setup.py as well as in application/library code, when the
>>> application/library wants to know its own version number?
>>>
>>> I've seen several options:
>>>
>>> 1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>>>    do from yourpackage import __version__ and pass that to setup()
>>
>> This is generally what I do and it seems to work pretty well for me.  I 
>> remember talking with Gary Poster about some problems with this, 
>> related to our open source lazr packages, but I don't recall the 
>> details.
>
> Basically, this means that your setup.py has to be able to import your  
> package's __init__.py without any of the dependencies.
>
> If your __init__.py only has a __version__ then this is fine.  However, 
> if you want your __init__ to reexport something to avoid clients having 
> to do foo.foo.Foo-style imports from your package, or if you want to put 
> any other code in your __init__ that might need dependencies, this 
> breaks.

My __init__.py does "from _version import version as __version__" to
solve this problem, setup.py then imports _version.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From david.lyon at preisshare.net  Sat Jul 11 11:58:05 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Sat, 11 Jul 2009 05:58:05 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>
	<5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com>
Message-ID: <02f30a119597a6bbacf2926429f14f67@preisshare.net>

On Fri, 10 Jul 2009 10:02:39 -0400, Jim Fulton <jim at zope.com> wrote:
> I was really just pointing out that there isn't  
> anythin special about web developers.  Really the need relates to  
> application development.  That is, wen application developer's needs  
> aren't really different from other application developers' needs.

Just for my own education..

Why is there so many problems with python hosting? What I mean
is that any linux host that can run python should be able to
do web hosting easily. Say like run zope/plone.

Is this due to difficulties in getting packages onto a web host?

What could be done in an ideal world to make it a snap to
run zope on my cheapy linux web hosting service (that already
has python)?

David

From marius at pov.lt  Sat Jul 11 12:54:14 2009
From: marius at pov.lt (Marius Gedminas)
Date: Sat, 11 Jul 2009 13:54:14 +0300
Subject: [Distutils] Single version number
In-Reply-To: <20090710132951.2543.74752654.divmod.quotient.843@henry.divmod.com>
References: <20090710125832.GA12437@fridge.pov.lt>
	<20090710132951.2543.74752654.divmod.quotient.843@henry.divmod.com>
Message-ID: <20090711105414.GC2540@fridge.pov.lt>

On Fri, Jul 10, 2009 at 09:29:51AM -0400, Jean-Paul Calderone wrote:
> On Fri, 10 Jul 2009 15:58:32 +0300, Marius Gedminas <marius at pov.lt> wrote:
>> What do people use to avoid repeating the version number both in the
>> setup.py as well as in application/library code, when the
>> application/library wants to know its own version number?
>>
>> I've seen several options:
>>
>>  1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>>     do from yourpackage import __version__ and pass that to setup()
>>
>>  2) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>>     execfile(os.path.join(os.path.dirname(__file__), 'src', 'yourpackage',
>>                           '__init__.py'), d), then use d['__version__']
>>
>>  3) put a file called version.txt in yourpackage/, have setup.py read
>>     it, make sure it's included in MANIFEST.in
>>
>>  4) I don't recall actually ever seeing this one, but it should be
>>     possible to use pkg_resources to query the version of yourpackage
>>     (downside: if you're running from a source checkout without
>>     installing, you won't get the right version number)
>>
>
> There was some discussion of this here a couple months ago:
>
> http://mail.python.org/pipermail/distutils-sig/2009-May/011913.html

Thank you for the link.  I shoud've thought to do a search before
asking.

Marius Gedminas
-- 
If the code and the comments disagree, then both are probably wrong.
                -- Norm Schryer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090711/e0d1ad1b/attachment.pgp>

From jim at zope.com  Sat Jul 11 12:54:53 2009
From: jim at zope.com (Jim Fulton)
Date: Sat, 11 Jul 2009 06:54:53 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
In-Reply-To: <02f30a119597a6bbacf2926429f14f67@preisshare.net>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>
	<5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com>
	<02f30a119597a6bbacf2926429f14f67@preisshare.net>
Message-ID: <B73FF020-E372-48EF-B7C7-0977E0404946@zope.com>

This is really off topic.  I'll reply but I'll switch the list to web- 
sig.

Jim

On Jul 11, 2009, at 5:58 AM, David Lyon wrote:

> On Fri, 10 Jul 2009 10:02:39 -0400, Jim Fulton <jim at zope.com> wrote:
>> I was really just pointing out that there isn't
>> anythin special about web developers.  Really the need relates to
>> application development.  That is, wen application developer's needs
>> aren't really different from other application developers' needs.
>
> Just for my own education..
>
> Why is there so many problems with python hosting? What I mean
> is that any linux host that can run python should be able to
> do web hosting easily. Say like run zope/plone.
>
> Is this due to difficulties in getting packages onto a web host?
>
> What could be done in an ideal world to make it a snap to
> run zope on my cheapy linux web hosting service (that already
> has python)?
>
> David

--
Jim Fulton
Zope Corporation



From david.lyon at preisshare.net  Sat Jul 11 13:04:24 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Sat, 11 Jul 2009 07:04:24 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <B73FF020-E372-48EF-B7C7-0977E0404946@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>
	<5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com>
	<02f30a119597a6bbacf2926429f14f67@preisshare.net>
	<B73FF020-E372-48EF-B7C7-0977E0404946@zope.com>
Message-ID: <583aac0ce9c850d9decf7cd9ba4459ab@preisshare.net>

On Sat, 11 Jul 2009 06:54:53 -0400, Jim Fulton <jim at zope.com> wrote:
> This is really off topic.  I'll reply but I'll switch the list to web- 
> sig.

>>
>> Why is there so many problems with python hosting? What I mean
>> is that any linux host that can run python should be able to
>> do web hosting easily. Say like run zope/plone.
>>
>> Is this due to difficulties in getting packages onto a web host?
>>
>> What could be done in an ideal world to make it a snap to
>> run zope on my cheapy linux web hosting service (that already
>> has python)?

No it is not OT. It's totally on-topic...

I'm asking how an application developer using a cheapy web hosting
plan (who cannot run setup.py)... could do a package installation.

Therefore, allowing "setup.py needs to go away"

I can't keep on-topic anymore than that...

It is a valid question...

David


From jim at zope.com  Sat Jul 11 13:25:10 2009
From: jim at zope.com (Jim Fulton)
Date: Sat, 11 Jul 2009 07:25:10 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
In-Reply-To: <583aac0ce9c850d9decf7cd9ba4459ab@preisshare.net>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>
	<5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com>
	<02f30a119597a6bbacf2926429f14f67@preisshare.net>
	<B73FF020-E372-48EF-B7C7-0977E0404946@zope.com>
	<583aac0ce9c850d9decf7cd9ba4459ab@preisshare.net>
Message-ID: <89B409B8-C78F-4851-BF5F-3C85E59ED1EB@zope.com>


On Jul 11, 2009, at 7:04 AM, David Lyon wrote:

> On Sat, 11 Jul 2009 06:54:53 -0400, Jim Fulton <jim at zope.com> wrote:
>> This is really off topic.  I'll reply but I'll switch the list to  
>> web-
>> sig.
>
>>>
>>> Why is there so many problems with python hosting? What I mean
>>> is that any linux host that can run python should be able to
>>> do web hosting easily. Say like run zope/plone.
>>>
>>> Is this due to difficulties in getting packages onto a web host?
>>>
>>> What could be done in an ideal world to make it a snap to
>>> run zope on my cheapy linux web hosting service (that already
>>> has python)?
>
> No it is not OT. It's totally on-topic...
>
> I'm asking how an application developer using a cheapy web hosting
> plan (who cannot run setup.py)... could do a package installation.
>
> Therefore, allowing "setup.py needs to go away"
>
> I can't keep on-topic anymore than that...
>
> It is a valid question...


Well, I think it's still better asked over on web-sig, as I don't  
*think* it's primarily a packaging question.  I'll try to make a more  
packaging-centric reply here. A major problem with the low cost  
providers is that you don't get a shell prompt, so you can't use any  
packaging tools.  More importantly, you can't run long-running  
processes.

Lots of people are being drawn to Google App Engine.  It also doesn't  
give you a shell prompt, but it has a tool for uploading software that  
then runs in long-running processes.  There are packaging tools that  
let you assemble software in the needed format on your server for  
upload to GAE.  For example:

   http://pypi.python.org/pypi/rod.recipe.appengine

Of course, lots of relatively inexpensive co-lo providers give you a  
VM that it's straightforward, I asume, to install Python web  
applications on.

Jim

--
Jim Fulton
Zope Corporation



From david.lyon at preisshare.net  Sat Jul 11 13:54:11 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Sat, 11 Jul 2009 07:54:11 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <89B409B8-C78F-4851-BF5F-3C85E59ED1EB@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<79990c6b0907100620x36fdcdeejef3be90b1e228d25@mail.gmail.com>
	<5CF06853-D47B-4FAA-8E61-25B1066551C4@zope.com>
	<02f30a119597a6bbacf2926429f14f67@preisshare.net>
	<B73FF020-E372-48EF-B7C7-0977E0404946@zope.com>
	<583aac0ce9c850d9decf7cd9ba4459ab@preisshare.net>
	<89B409B8-C78F-4851-BF5F-3C85E59ED1EB@zope.com>
Message-ID: <97c2caa017cd1d423ec479dbacdcd1e3@preisshare.net>

On Sat, 11 Jul 2009 07:25:10 -0400, Jim Fulton <jim at zope.com> wrote:
> Well, I think it's still better asked over on web-sig, as I don't  
> *think* it's primarily a packaging question.  I'll try to make a more  
> packaging-centric reply here. A major problem with the low cost  
> providers is that you don't get a shell prompt, so you can't use any  
> packaging tools.  More importantly, you can't run long-running  
> processes.

Thanks. That's very informative and confirmed my suspicions.

So making an observation (which somebody will shoot me soon for haha) from 
a packaging perspective, setuptools and perphaps distutils themselves have
some way to go to really adapt themselves to running from within
the popular web environments of today.

More succinctly.. we can't use distutils/setuptools in a gui or a
web environment out of the box.

Being a prehistoric myself.. I don't have a problem with that.

But for the future, it might be present issues..

David




From zooko at zooko.com  Sat Jul 11 16:42:28 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sat, 11 Jul 2009 08:42:28 -0600
Subject: [Distutils] Single version number
In-Reply-To: <20090710125832.GA12437@fridge.pov.lt>
References: <20090710125832.GA12437@fridge.pov.lt>
Message-ID: <009F7F62-11F8-4389-94F9-935DB641E5CC@zooko.com>

On Jul 10, 2009, at 6:58 AM, Marius Gedminas wrote:

> What do people use to avoid repeating the version number both in  
> the setup.py as well as in application/library code, when the  
> application/library wants to know its own version number?

I have a script that reads revision control history and writes out a  
_version.py file with just "verstr='1.2.3'" in it.

Then my setup.py does this:

PKG = "zfec"
VERSIONFILE = PKG+"/_version.py"
verstr = "unknown"
try:
     verstrline = open(VERSIONFILE, "rt").read()
except EnvironmentError:
     pass # Okay, there is no version file.
else:
     VSRE = r"^verstr = ['\"]([^'\"]*)['\"]"
     mo = re.search(VSRE, verstrline, re.M)
     if mo:
         verstr = mo.group(1)
     else:
         print "unable to find version in %s" % (VERSIONFILE,)
         raise RuntimeError("if %s.py exists, it is required to be  
well-formed" % (VERSIONFILE,))


I packaged up the script that reads revision control history (darcs)  
and writes out the _version.py file as "darcsver": http:// 
pypi.python.org/pypi/darcsver .  It can be invoked as a command-line  
tool or a setuptools plugin.

I also then extended the darcsver setuptools plugin so that it would  
do effectively the same thing as the above code, so that I don't have  
to copy that code into each of my setup.py files.  Unfortunately  
issue20 of setuptools (http://bugs.python.org/setuptools/msg235 )  
means that at most one of my packages can use darcsver to do that in  
the same build, so currently my Tahoe project uses darcsver to set  
the "version" attribute and doesn't have that code snippet that I  
pasted above, but my other projects (many of which Tahoe depends on)  
have that code snippet in the setup.py.

Regards,

Zooko

From zooko at zooko.com  Sat Jul 11 16:56:41 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sat, 11 Jul 2009 08:56:41 -0600
Subject: [Distutils] Single version number
In-Reply-To: <C4D668A2-139A-4E91-91EC-059223852147@python.org>
References: <20090710125832.GA12437@fridge.pov.lt>
	<C4D668A2-139A-4E91-91EC-059223852147@python.org>
Message-ID: <4D5ACDD7-E385-49BA-8D05-82C3AF7A83EE@zooko.com>

On Jul 10, 2009, at 7:24 AM, Barry Warsaw wrote:

> On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:
>
>>  1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
>>     do from yourpackage import __version__ and pass that to setup()
>
> This is generally what I do and it seems to work pretty well for  
> me.  I remember talking with Gary Poster about some problems with  
> this, related to our open source lazr packages, but I don't recall  
> the details.

This idiom seems to cause problem for building Nevow, when it isn't  
being built in a fresh process all by itself (i.e. "python ./setup.py  
build") but is instead being built inside a more complicated setting,  
such as when it is one of the module being packaged up by py2exe, or  
when it is the dependency of something which is being built by  
setuptools:

http://divmod.org/trac/ticket/2699

Regards,

Zooko

From david at ar.media.kyoto-u.ac.jp  Sun Jul 12 12:24:47 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sun, 12 Jul 2009 19:24:47 +0900
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <46D0C65E-1030-40D1-96CB-88B42BC48E0A@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<4A57288C.5060804@ar.media.kyoto-u.ac.jp>
	<46D0C65E-1030-40D1-96CB-88B42BC48E0A@zope.com>
Message-ID: <4A59B9EF.9040805@ar.media.kyoto-u.ac.jp>

Jim Fulton wrote:
> I couldn't agree more.  As an application developer, I want to deliver
> complete self-enclosed applications.  I think that's why many
> application developers gravitate towards systems like buildout and
> virtualenv/pip. In fact, the tendency of system Python's to be
> customized by system packagers or system administrators often make the
> unsuitable for supporting applications.  When delivering applications
> to be installed by end users, I try to include everything needed,
> generally including Python. (I haven't been in this position for quite
> some time.)

That relates to the "python needs to be a platform" idea.Taking again
the numpy/scipy case, I would love to get something like a robust
easy_install, where scientific toolboxes can be installed, queries,
uninstalled from pypi. Having our own 'python' for installation, would
make this much easier - but we loose what makes numpy/scipy so
attractive in the first place, that is using a lot of great packages
outside the numpy/scipy community. Those two goals kind of contradict
with each other, I am not sure where the trade-off should be. Maybe
python makes this impossible. I would be surprised if this problem were
limited to numpy/scipy.

>
>
> Really, many (I'd guess most) web developers who gravitate to
> setuptools are drawn by the ability to express and manage
> dependencies.  They use tools like buildout or virtualenv that avoid
> the pitfalls you mention above. I suspect you have more in common with
> us than you think. :)

I know about virtualenv, pip, yolk (much less about buildout). I even
use them sometimes (I never use setuptools outside a virtualenv, for
example). But I don't see how this solve the deployment problem. How is
virtualenv useful for distribution of software to end users ? On the
robustness side of things, I cannot say I am satisfied with the solution
either. It is almost always workable, but not good enough for people who
do not care much about programming (which I think is the case of a lot
of researchers/scientists). We have tons of user problems related to
installation/deployment issues.

cheers,

David

From jim at zope.com  Sun Jul 12 13:14:48 2009
From: jim at zope.com (Jim Fulton)
Date: Sun, 12 Jul 2009 07:14:48 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
	questions on python-dev)
In-Reply-To: <4A59B9EF.9040805@ar.media.kyoto-u.ac.jp>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<4A57288C.5060804@ar.media.kyoto-u.ac.jp>
	<46D0C65E-1030-40D1-96CB-88B42BC48E0A@zope.com>
	<4A59B9EF.9040805@ar.media.kyoto-u.ac.jp>
Message-ID: <E49A011B-7279-4BC5-878B-9238E47A11FE@zope.com>


On Jul 12, 2009, at 6:24 AM, David Cournapeau wrote:
...
> That relates to the "python needs to be a platform" idea.Taking again
> the numpy/scipy case, I would love to get something like a robust
> easy_install, where scientific toolboxes can be installed, queries,
> uninstalled from pypi.

I don't understand what you mean by "queries, uinstalled from pypi".

> Having our own 'python' for installation, would
> make this much easier - but we loose what makes numpy/scipy so
> attractive in the first place, that is using a lot of great packages
> outside the numpy/scipy community.

Why would you lose anything? You can include any additional tools you  
want.

> Those two goals kind of contradict
> with each other, I am not sure where the trade-off should be.

I'm not sure exactly what you mean, but I think this gets back to my  
original point.  Sometimes you want to provide people a robust   
application that addresses a fixed set of use cases. Sometime you want  
to provide a toolbox that allows people to address ad hoc problems.   
In the later case, you will often trade off robustness for  
flexibility. My impression is that numpy is often used as part of a  
toolbox for ad hoc numerical analysis.

> Maybe
> python makes this impossible.

I doubt it has anything to do with Python.

> I would be surprised if this problem were
> limited to numpy/scipy.

Me too.  For example, a database interface is useful both  in closed  
(from the users point of views) applications, and in open computing  
toolboxes.  The "system python" tends to be used like a open computing  
platform for ad hoc computing and small scripts.  It's not well suited  
to supporting large applications. For ad hoc computing, the  
flexibility that the system Python provides is very useful.   
Applications need a lot more control and predictability than a system  
Python can typically provide.

>> Really, many (I'd guess most) web developers who gravitate to
>> setuptools are drawn by the ability to express and manage
>> dependencies.  They use tools like buildout or virtualenv that avoid
>> the pitfalls you mention above. I suspect you have more in common  
>> with
>> us than you think. :)
>
> I know about virtualenv, pip, yolk (much less about buildout). I even
> use them sometimes (I never use setuptools outside a virtualenv, for
> example). But I don't see how this solve the deployment problem. How  
> is
> virtualenv useful for distribution of software to end users ?

Well, I'm more familiar with buildout. :) Buildout makes it  
straightforward to control precisely the packages in your  
application.  A tool named zc.sourcerelease, let's you build a release  
that contains a particular configuration of packages with an install  
script that installs them.  (This isn't limited to Python packages  
either.  It can include 3rd-party applications such as libraries,  
database servers, etc. -- anything that's installed with a configure- 
make-make-install dance.)  This source release then becomes the basis  
for an installer.  We use it to create RPMs for our applications.   
Because we use RPM, our applications can share a common "clean" Python  
RPM that has what you'd get from a source install of Python.  We don't  
include Python in the application RPMs, although it would be pretty  
easy to do so.

I think something like this is possible with pip/virtualenv.  I could  
be wrong.

> On the
> robustness side of things, I cannot say I am satisfied with the  
> solution
> either. It is almost always workable, but not good enough for people  
> who
> do not care much about programming (which I think is the case of a lot
> of researchers/scientists). We have tons of user problems related to
> installation/deployment issues.

I think buildout might help a lot.  It doesn't give you an installer,  
as that is very platform specific, but it gives you a starting point  
to make building an installer pretty straightforward.

Jim

--
Jim Fulton
Zope Corporation



From tseaver at palladion.com  Sun Jul 12 14:34:20 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Sun, 12 Jul 2009 08:34:20 -0400
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <E49A011B-7279-4BC5-878B-9238E47A11FE@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>	<20090709172515.1801C3A407B@sparrow.telecommunity.com>	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>	<4A57288C.5060804@ar.media.kyoto-u.ac.jp>	<46D0C65E-1030-40D1-96CB-88B42BC48E0A@zope.com>	<4A59B9EF.9040805@ar.media.kyoto-u.ac.jp>
	<E49A011B-7279-4BC5-878B-9238E47A11FE@zope.com>
Message-ID: <4A59D84C.9090606@palladion.com>

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

Jim Fulton wrote:
> On Jul 12, 2009, at 6:24 AM, David Cournapeau wrote:
>> I know about virtualenv, pip, yolk (much less about buildout). I even
>> use them sometimes (I never use setuptools outside a virtualenv, for
>> example). But I don't see how this solve the deployment problem. How  
>> is virtualenv useful for distribution of software to end users ?
> 
> Well, I'm more familiar with buildout. :) Buildout makes it  
> straightforward to control precisely the packages in your  
> application.  A tool named zc.sourcerelease, let's you build a release  
> that contains a particular configuration of packages with an install  
> script that installs them.  (This isn't limited to Python packages  
> either.  It can include 3rd-party applications such as libraries,  
> database servers, etc. -- anything that's installed with a configure- 
> make-make-install dance.)  This source release then becomes the basis  
> for an installer.  We use it to create RPMs for our applications.   
> Because we use RPM, our applications can share a common "clean" Python  
> RPM that has what you'd get from a source install of Python.  We don't  
> include Python in the application RPMs, although it would be pretty  
> easy to do so.
> 
> I think something like this is possible with pip/virtualenv.  I could  
> be wrong.

virtualenv doesn't focus on the repeatability part:  it just gets you an
isolated Python environment where you can install packages without
affecting other users of Python on your system, and (as an option) where
you can be unaffected by packages installed to the "base" Python's
site-packages.

I often create muliple virtualenvs in a single day, just so that I can
test that packages install cleanly, have their dependencies specified
correctly etc., and then just throw them away.

WRT David's question about using virtualenv for distribution:  it has a
feature which allows you to generate a clone of the virtualenv.py
script, adding additional post-creation steps, such as installing
packages.  We use this feature to build tutorial DVDs, so that people
can install an application using the pacakges in the index on the DVD,
without requiring network connectivity:  all they need is to run the
script with an already-installed Python, and point at the target directory.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKWdhL+gerLs4ltQ4RAs9lAJ9nE62nWJebEJVPkEVXXhRDJ2Ud8gCfQSxg
L2Q7q3TPY3NhkPpioIU8i0g=
=s9Qv
-----END PGP SIGNATURE-----


From cmsdew at googlemail.com  Sat Jul 11 09:32:49 2009
From: cmsdew at googlemail.com (Chris Dew)
Date: Sat, 11 Jul 2009 00:32:49 -0700 (PDT)
Subject: [Distutils] Low Level API for translating distutils/setuptools
	metatdata to Debian metadata
In-Reply-To: <b94538deaf36b06f35b6b78a89cb989e@preisshare.net>
References: <20090529091202.GB22620@Boo.lan> <4A2000B4.90501@astraw.com> 
	<b94538deaf36b06f35b6b78a89cb989e@preisshare.net>
Message-ID: <d72a4022-ae1f-4321-a546-7bd5ab5c58d8@d32g2000yqh.googlegroups.com>

On May 31, 12:27?am, David Lyon <david.l... at preisshare.net> wrote:
> ?1) create a three page "wizard" style app in wxpython

After spending a three hours trying to figure out how to correctly
build a debian package from Python sources, I agree it needs to be a
lot easier.

But scripts allow for continuous integration, which is a very good
thing, as servers build packages and run tests nearly for free.

GUIs require an expensive person to click buttons, which is also not
an interesting task for the person.

If anyone's tempted to go down this route and create a GUI system for
Python distro-packaging, please build in a scriptable/headless option.

All the best,

Chris.

From david.lyon at preisshare.net  Mon Jul 13 02:13:26 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Sun, 12 Jul 2009 20:13:26 -0400
Subject: [Distutils] Low Level API for translating distutils/setuptools
 metatdata to Debian metadata
In-Reply-To: <d72a4022-ae1f-4321-a546-7bd5ab5c58d8@d32g2000yqh.googlegroups.com>
References: <20090529091202.GB22620@Boo.lan> <4A2000B4.90501@astraw.com>
	<b94538deaf36b06f35b6b78a89cb989e@preisshare.net>
	<d72a4022-ae1f-4321-a546-7bd5ab5c58d8@d32g2000yqh.googlegroups.com>
Message-ID: <6527ce2b79aceabdf653c9445f86421e@preisshare.net>


Hi Chris,

I started prototyping of this a month or so ago but haven't had a chance
to do much more on it too now. Maybe in the next I'll put more effort into
this multi-platform package builder and register it as a project somewhere.


If you want to send me your scripts offline, I'd be interested seeing
them. 

Unfortunately, I've been busy writing documentation for the Package Manager

and trying  to figure out how to use distutils myself. It's a steep 
learning curve.

I get the point about having some web based app (pypi? haha) where
you type in a package name, click the platforms.. and out come all
the different packages for all the different python versions and
operating systems.

That's all I ever asked for.... :-) but I only know backend stuff
and gui programming. I kindof know how to seperate the two so doing
a web based one is totally impossible.

Hopefully I'll find enough hacking time in the next few months..


David

On Sat, 11 Jul 2009 00:32:49 -0700 (PDT), Chris Dew <cmsdew at googlemail.com>
wrote:
> On May 31, 12:27?am, David Lyon <david.l... at preisshare.net> wrote:
>> ?1) create a three page "wizard" style app in wxpython
> 
> After spending a three hours trying to figure out how to correctly
> build a debian package from Python sources, I agree it needs to be a
> lot easier.
> 
> But scripts allow for continuous integration, which is a very good
> thing, as servers build packages and run tests nearly for free.
> 
> GUIs require an expensive person to click buttons, which is also not
> an interesting task for the person.
> 
> If anyone's tempted to go down this route and create a GUI system for
> Python distro-packaging, please build in a scriptable/headless option.


From david at ar.media.kyoto-u.ac.jp  Mon Jul 13 05:13:35 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Mon, 13 Jul 2009 12:13:35 +0900
Subject: [Distutils] "setup.py needs to go away" (was [PEP 376] - Open
 questions on python-dev)
In-Reply-To: <E49A011B-7279-4BC5-878B-9238E47A11FE@zope.com>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<4A57288C.5060804@ar.media.kyoto-u.ac.jp>
	<46D0C65E-1030-40D1-96CB-88B42BC48E0A@zope.com>
	<4A59B9EF.9040805@ar.media.kyoto-u.ac.jp>
	<E49A011B-7279-4BC5-878B-9238E47A11FE@zope.com>
Message-ID: <4A5AA65F.2010102@ar.media.kyoto-u.ac.jp>

Jim Fulton wrote:
>
> On Jul 12, 2009, at 6:24 AM, David Cournapeau wrote:
> ...
>> That relates to the "python needs to be a platform" idea.Taking again
>> the numpy/scipy case, I would love to get something like a robust
>> easy_install, where scientific toolboxes can be installed, queries,
>> uninstalled from pypi.
>
> I don't understand what you mean by "queries, uinstalled from pypi".

Sorry, the bad grammar did not help to make the point very clearly. My
ideal scenario would be, inside a python session:

>>> pkgs = look_for_packages(keywords=['image', 'signal', '3d']) #
return a list of packages related to those keywords
>>> for p in pkgs: print p.description # Get the description
>>> install_package('some_package')
>>> ....
>>> upgrade_world() # Upgrade every package and their dependencies
>>> uninstall('some_useless_package')

This would work as a normal user (no admin privileges required), and it
has to be robust. It should (up to some point, there will always be some
friction here) play happily with the system packager if there is any.

>
>> Having our own 'python' for installation, would
>> make this much easier - but we loose what makes numpy/scipy so
>> attractive in the first place, that is using a lot of great packages
>> outside the numpy/scipy community.
>
> Why would you lose anything? You can include any additional tools you
> want.

The user would loose the ability to install packages whose binaries are
built against the python distributed by python.org. Especially on
windows (compilation issues), and on a less degree, mac os x, that's a
killer.

>
>> Those two goals kind of contradict
>> with each other, I am not sure where the trade-off should be.
>
> I'm not sure exactly what you mean, but I think this gets back to my
> original point.  Sometimes you want to provide people a robust 
> application that addresses a fixed set of use cases. Sometime you want
> to provide a toolbox that allows people to address ad hoc problems.  

And sometimes, we want both :)

> I doubt it has anything to do with Python.

I can already cite two python shortcomings which cause issues for the
above scenarios: ABI issues and no "versioned import" support.

> Well, I'm more familiar with buildout. :) Buildout makes it
> straightforward to control precisely the packages in your
> application.  A tool named zc.sourcerelease, let's you build a release
> that contains a particular configuration of packages with an install
> script that installs them.  (This isn't limited to Python packages
> either.  It can include 3rd-party applications such as libraries,
> database servers, etc. -- anything that's installed with a
> configure-make-make-install dance.)

This sounds a bit like the gar system:

http://www.lnx-bbc.com/garticle.html

Except gar is based on makefiles.

> This source release then becomes the basis for an installer.  We use
> it to create RPMs for our applications.  Because we use RPM, our
> applications can share a common "clean" Python RPM that has what you'd
> get from a source install of Python.  We don't include Python in the
> application RPMs, although it would be pretty easy to do so.

Ok. That sounds indeed like one step in the good direction. Although
deployment issues will always be difficult, repeatability helps a lot
toward making it less painful. I see repeatability as the common ground,
and precise requirements as a 'special case' of repeatability.

David

From jdmain at comcast.net  Mon Jul 13 17:01:08 2009
From: jdmain at comcast.net (J.D. Main)
Date: Mon, 13 Jul 2009 09:01:08 -0600
Subject: [Distutils] py2exe - COM Server DLL can't be referenced by VB6 or
	VS2003
Message-ID: <4A5AF7D4.18308.D3F2915@jdmain.comcast.net>

Hi Guys,

Hopefully this is the place to ask this question.  

I have written a COM server with a few trivial string methods to test the 
integration of Python and VB (and Visual Studio).  I have run it through 
py2exe and created a DLL that actually does register and Windows seems 
to be happy with it.  I can access the methods of this COM object with 
Python and VBA and, sure enough, it works.    That's awesome.

However, it can not be added as a reference to a VB6 or a VS2003 project.  
Both say it's not a valid DLL and it doesn't show up in any of their "reference 
object" lists.  That basically means it's not available for use in that 
environment.  In addition, any sort of code completion or call tips will never 
function.

So my question is this:  is there some special interface vodoo that needs to 
be put in my code or my py2exe setup in order to get this COM server truly 
visible and accessible within VB6 or Visual Studio?  

Also, is there even more interface stuff so the code completion/call-tips stuff 
works?

I would love to hear about any experience you may have with all this.  

Best Regards,

J.D.

From me at rpatterson.net  Tue Jul 14 01:22:21 2009
From: me at rpatterson.net (Ross Patterson)
Date: Mon, 13 Jul 2009 16:22:21 -0700
Subject: [Distutils] mr.developer: share checkouts between buildouts
Message-ID: <87hbxg2moi.fsf@transitory.lefae.org>

I often end up doing development on the same distribution for multiple
projects and have long wished for a simple way to share the same
clone/checkout between these multiple buildouts.

What would you think about supporting a shared sources directory much in
the same vein of zc.buildout's use of eggs-directory, zc.recipe.cmmi's
use of download-cache, and plone.recipe.zope2install's use of
zope-directory all of which can be set in the users
~/.buildout/default.cfg?

If the option is set, we could do the clone/checkout into the shared
sources directory and then symlink them into sources-dir.

Thoughts?
Ross


From sridharr at activestate.com  Tue Jul 14 02:07:02 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 13 Jul 2009 17:07:02 -0700
Subject: [Distutils] [Python-Dev] PEP 376 - Open questions
In-Reply-To: <94bdd2610907090122x12a3f25s13bba018240f331d@mail.gmail.com>
References: <79990c6b0907061138o3fe12709vc39876256f38e6fe@mail.gmail.com>
	<79990c6b0907080513g6f9c9318i92d3e7624a9c388f@mail.gmail.com>
	<loom.20090708T121713-308@post.gmane.org>
	<4A54984D.4020305@trueblade.com>
	<79990c6b0907080628r50e569aaue0261c422d2710c@mail.gmail.com>
	<4A54AF4F.9080800@trueblade.com>
	<79990c6b0907080757y576599bav3aa8c93904722e07@mail.gmail.com>
	<20090708151647.9E0703A407B@sparrow.telecommunity.com>
	<79990c6b0907080922v4242672fg1abb3eb02a8004d9@mail.gmail.com>
	<op.uwr1phe9brrvlq@double>
	<94bdd2610907090122x12a3f25s13bba018240f331d@mail.gmail.com>
Message-ID: <op.uw06l0gv1q4jlt@whymac.activestate.com>

On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
> Ratnakumar<SridharR at activestate.com> wrote:
>> Other than easy_install/pip, there is also PyPM which is being  
>> developed at
>> ActiveState. PyPM is the Python package manager much like what ppm is  
>> for
>> ActivePerl.
>>
>
> Great ! besides the RECORD file, anything remark on the PEP from a
> PyPM point of view ?

I'll shortly send an email I composed regarding this.

> Once Paul has finished to work on the PEP 302 part of the prototype,
> maybe we could try it out
> on PyPM to see how it fits ?

I took a look at PEP 302 and Paul's new implemention in pkgutil2.py

   http://bitbucket.org/tarek/pep376/src/tip/pkgutil2.py

And yes, I'd happy to try the new pkgutil API on PyPM .. keeping  
interoperability with pip/easy_install installed packages in mind.

-srid





From sridharr at activestate.com  Tue Jul 14 02:12:32 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 13 Jul 2009 17:12:32 -0700
Subject: [Distutils] PEP 376 - from PyPM's point of view
Message-ID: <op.uw06u6px1q4jlt@whymac.activestate.com>

Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)


Multiple versions: I understand that the PEP does not support
installation (thus uninstallation) of multiple versions of the same
package. Should this be explicitly mentioned in the PEP -- as
`get_distribution` API accepts only `name` argument, and not a `version`
argument?

> get_distribution(name) -> Distribution or None.
>Scans all elements in sys.path and looks for all directories ending
> with .egg-info. Returns a Distribution corresponding to the .egg-info
> directory that contains a PKG-INFO that matches name for the name
> metadata.
>Notice that there should be at most one result. The first result
> founded is returned. If the directory is not found, returns None.

Some packages have package names with mixed case. Example: ConfigObj
.. as registered in setup.py. However, other packages such as turbogears
specifies "configobj" (lowercase) in their install_requires.

Is `get_distribution(name)` supposed to handle mixed cases? Will it
match both 'ConfigObj' and 'configobj'?

> get_installed_files(local=False) -> iterator of (path, md5, size)

Will this also return the directories /created/ during the installation?
For example, will it also contain the entry "docutils" .. along with
"docutils/__init__.py"?

If not, how is the installer (pip, pypm, etc..) supposed to know which
directories to remove (docutils/) and which directories not to remove
(site-packages/, bin/, etc..)?

> The new version of PEP 345 (XXX work in progress) extends the Metadata
> standard and fullfills the requirements described in PEP 262, like the
> REQUIRES section.

Can you tell more about this?

I see that PEP 262 allows both distributions names ('docutils') and
modules/packages ('roman.py') in the 'Requires:' section. Is this how
the new PEP is going to adhere to? Or, is it going to adhere to PEP
345's way of allowing *only* modules/packages?

In practice, I noticed that packages usually specify distribution names
in their 'Requires:' file (or install_requires.txt in the case of
setuptools). Hence, PyPM *assumes* the install requirements to be
distribution name. But then .. most distributions have the same name as
their primary module/package.

Ok, so PEP 345 also specifies the 'Provides:' header. Does
easy_install/pip make use 'Provides:' at all when resolving
dependencies? For example, does 'pip install sphinx' go look for all
distributions that 'provides' the 'docutils' provision.. or does it
simply get the distribution named 'docutils'?

-srid

From fuzzyman at voidspace.org.uk  Tue Jul 14 03:15:22 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 14 Jul 2009 02:15:22 +0100
Subject: [Distutils] [Python-Dev] PEP 376 - from PyPM's point of view
In-Reply-To: <op.uw06u6px1q4jlt@whymac.activestate.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
Message-ID: <E52F1994-E8C2-477B-83E8-7503D5BA769C@voidspace.org.uk>




--
http://www.ironpythoninaction.com

On 14 Jul 2009, at 01:12, "Sridhar Ratnakumar"  
<sridharr at activestate.com> wrote:

> Here are my comments regarding PEP 376 with respect to PyPM (the  
> Python
> package manager being developd at ActiveState)
>
>
> Multiple versions: I understand that the PEP does not support
> installation (thus uninstallation) of multiple versions of the same
> package. Should this be explicitly mentioned in the PEP -- as
> `get_distribution` API accepts only `name` argument, and not a  
> `version`
> argument?
>
>> get_distribution(name) -> Distribution or None.
>> Scans all elements in sys.path and looks for all directories ending
>> with .egg-info. Returns a Distribution corresponding to the .egg-info
>> directory that contains a PKG-INFO that matches name for the name
>> metadata.
>> Notice that there should be at most one result. The first result
>> founded is returned. If the directory is not found, returns None.
>
> Some packages have package names with mixed case. Example: ConfigObj
> .. as registered in setup.py. However, other packages such as  
> turbogears
> specifies "configobj" (lowercase) in their install_requires.
>
> Is `get_distribution(name)` supposed to handle mixed cases? Will it
> match both 'ConfigObj' and 'configobj'?
>

An abomination for which I am truly sorry - however to be precise I'm  
pretty sure the setup.py specifies configobj and it is only registered  
on PyPI with mixed case (which I don't believe I can change).

Michael




>> get_installed_files(local=False) -> iterator of (path, md5, size)
>
> Will this also return the directories /created/ during the  
> installation?
> For example, will it also contain the entry "docutils" .. along with
> "docutils/__init__.py"?
>
> If not, how is the installer (pip, pypm, etc..) supposed to know which
> directories to remove (docutils/) and which directories not to remove
> (site-packages/, bin/, etc..)?
>
>> The new version of PEP 345 (XXX work in progress) extends the  
>> Metadata
>> standard and fullfills the requirements described in PEP 262, like  
>> the
>> REQUIRES section.
>
> Can you tell more about this?
>
> I see that PEP 262 allows both distributions names ('docutils') and
> modules/packages ('roman.py') in the 'Requires:' section. Is this how
> the new PEP is going to adhere to? Or, is it going to adhere to PEP
> 345's way of allowing *only* modules/packages?
>
> In practice, I noticed that packages usually specify distribution  
> names
> in their 'Requires:' file (or install_requires.txt in the case of
> setuptools). Hence, PyPM *assumes* the install requirements to be
> distribution name. But then .. most distributions have the same name  
> as
> their primary module/package.
>
> Ok, so PEP 345 also specifies the 'Provides:' header. Does
> easy_install/pip make use 'Provides:' at all when resolving
> dependencies? For example, does 'pip install sphinx' go look for all
> distributions that 'provides' the 'docutils' provision.. or does it
> simply get the distribution named 'docutils'?
>
> -srid
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

From david.lyon at preisshare.net  Wed Jul 15 05:29:29 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 14 Jul 2009 23:29:29 -0400
Subject: [Distutils] Questions about virtual-python on ubuntu
In-Reply-To: <4A59B9EF.9040805@ar.media.kyoto-u.ac.jp>
References: <4A55B2AE.90805@ar.media.kyoto-u.ac.jp>
	<20090709172515.1801C3A407B@sparrow.telecommunity.com>
	<4A56CFED.1030505@ar.media.kyoto-u.ac.jp>
	<3462798A-BAC5-4701-B8BB-FAFC7012DCE8@zope.com>
	<4A57288C.5060804@ar.media.kyoto-u.ac.jp>
	<46D0C65E-1030-40D1-96CB-88B42BC48E0A@zope.com>
	<4A59B9EF.9040805@ar.media.kyoto-u.ac.jp>
Message-ID: <2323de1166667ac4258d32ddf994b077@preisshare.net>

Hi All,

I'm trying to find a way to install packages on ubuntu as a normal user.

Being from windows but knowing some unix maybe I don't know all the python
tricks..

So I try this...

http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-python

It all runs ok and I get this.. at the bottom...

You're now ready to download ez_setup.py, and run
/home/dlyon/bin/python ez_setup.py

So I do that... and get a whole lot of errors....

I don't want to go su... the whole point is not to... what am I
doing wrong?

--------------------------------------------------------------------------
dlyon at ubuntu-8:~/Desktop$ python ez_setup.py
Downloading
http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c9-py2.5.egg
error: can't create or remove files in install directory

The following error occurred while trying to add or remove files in the
installation directory:

    [Errno 13] Permission denied:
'/usr/lib/python2.5/site-packages/test-easy-install-5325.write-test'

The installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    /usr/lib/python2.5/site-packages/

Perhaps your account does not have write access to this directory?  If the
installation directory is a system-owned directory, you may need to sign in
as the administrator or "root" account.  If you do not have administrative
access to this machine, you may wish to choose a different installation
directory, preferably one that is listed in your PYTHONPATH environment
variable.

For information on other options, you may wish to consult the
documentation at:

  http://peak.telecommunity.com/EasyInstall.html

Please make the appropriate changes for your system and try again.




From chris at simplistix.co.uk  Wed Jul 15 09:15:02 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 15 Jul 2009 08:15:02 +0100
Subject: [Distutils] mr.developer: share checkouts between buildouts
In-Reply-To: <87hbxg2moi.fsf@transitory.lefae.org>
References: <87hbxg2moi.fsf@transitory.lefae.org>
Message-ID: <4A5D81F6.6050208@simplistix.co.uk>

Ross Patterson wrote:
> I often end up doing development on the same distribution for multiple
> projects and have long wished for a simple way to share the same
> clone/checkout between these multiple buildouts.

What's stopping you from just putting the same checkout path in the 
develop line of your buildout.cfg? Works for me...

> Thoughts?

I wouldn't use this myself, while my different projects use the same 
packages, and it's handy be able to run from an svn checkout during 
development using the method I describe above, I never want to run code 
that's gone live that depends on an svn checkout of another package.
If there really isn't a suitable release, I cut a dev egg myself.

cheers,

Chris

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

From ziade.tarek at gmail.com  Wed Jul 15 11:01:24 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 15 Jul 2009 11:01:24 +0200
Subject: [Distutils] PEP 376 - from PyPM's point of view
In-Reply-To: <op.uw06u6px1q4jlt@whymac.activestate.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
Message-ID: <94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>

On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumar<sridharr at activestate.com> wrote:
> Here are my comments regarding PEP 376 with respect to PyPM (the Python
> package manager being developd at ActiveState)
>
>
> Multiple versions: I understand that the PEP does not support
> installation (thus uninstallation) of multiple versions of the same
> package. Should this be explicitly mentioned in the PEP -- as
> `get_distribution` API accepts only `name` argument, and not a `version`
> argument?

That's another can of worms ;)

Before I answer here's a bit of background, i's a bit long but required, sorry

For people that don't want to read the rest, here's the idea :
multiple version support imho should
be introduced later, if they are to be introduced, by extending PEP
302 protocol.

The long explanantion now:

given a "foo" package, containing a "bar" module, multiple versions
support implies to do one of these:

1 - a custom PEP 302-like loader/importer that picks a version of
"foo" when the code imports the "bar" module.
  this works if the "foo" package is not directly available in
sys.path, and if the custom loader/importer is put in sys.meta_path
  for example.  If "foo 0.9" is located in /var/packages/foo/0.9 and
if "foo 1.0" is in  /var/packages/foo/1.0,
  The loader will select the right foo package to load and return with
through a loader that scans   /var/packages/foo/*

  To make it work it requires 2 things :
        a/ a version comparison system (see PEP 386) that will make
the loader pick the "latest" version by default
        b/ an API that will force the loader to pick one particular version

2 - changing the paths in sys.path to include the path containing the
right version, and let the existing importer/loader do the work.
That's what setuptools does with its multiple version system: an API
called "require" will let you change sys.path on the fly

           >>> from pkg_resources import require
           >>> require('docutils==0.4')     <--- looks for a docutils
egg distribution and adds it in the path

So if we support multiple versions in Python, (I'd love too). PEP 376
would need to be able to find the various versions
of each distribution, not by scanning sys.path but rather by scanning
a arbitrary collection of directories, then publishing the
right ones in sys.path (with a PEP 302 loader, or ala setuptools by
inserting them in sys.path)

In other words this would require changing the way the distributions
are stored. e.g. in self-contained eggs or in a brand-new
storage tree. (I am currently experimenting this with "virtual
site-packages" see http://bitbucket.org/tarek/vsp/src/tip/README.txt)

But as we said earlier, people might want to store their modules
anywhere (on a sql database, on Mars, etc.) and provide
a PEP 302-like loader for them. PJE has "eggs" but John Doe might want
to store its packages differently and provide an importer/loader for
them.

So each one of them provides a "package manager", which should composed of :

A- a loader/importer system
B- an installation system (that is easy_install -m for setuptools)
C- query APIs
D- a version comparison system
E- an uninstaller

So the real solution is to work with PEP 302 importers/loaders (A)
(e.g. "package managers")

Which means that PEP 302 need to be changed to become
'distribution-aware' as Paul said.
Because we would then be able to browse distributions (C) that are not
already loaded in sys.path, so work on two versions
of the same distribution.

but some open questions remains:

It also implies that each package manager provides its installer (B)
and a version comparison system (D)

I'm not sure about the way package installers could be declared. Plus,
how people would deal with several installers ?
For the version comparison system I am not sure either, but it would
require to have one global version comparison
system to rule them all otherwise some conflicts may occur.

So there's no plan to support multiple versions yet, because that
requires another PEP imho.

Since distutils is a package manager in some ways (it provides an
installer, and stores distributions that are made
available in sys.path) My feeling is that we need first to finish
what's missing to make it fully usable (eg query apis + uninstaller)

Then maybe think about extending PEP 302

>
>> get_distribution(name) -> Distribution or None.
>> Scans all elements in sys.path and looks for all directories ending
>> with .egg-info. Returns a Distribution corresponding to the .egg-info
>> directory that contains a PKG-INFO that matches name for the name
>> metadata.
>> Notice that there should be at most one result. The first result
>> founded is returned. If the directory is not found, returns None.
>
> Some packages have package names with mixed case. Example: ConfigObj
> .. as registered in setup.py. However, other packages such as turbogears
> specifies "configobj" (lowercase) in their install_requires.
>
> Is `get_distribution(name)` supposed to handle mixed cases? Will it
> match both 'ConfigObj' and 'configobj'?

As PJE said, we need normalization here yes.

Right now PyPI is case insensitive for its index:

http://pypi.python.org/simple/ConfigObj ==
http://pypi.python.org/simple/configobj

But in the meantime, IIRC, the XML-RPC apis are case sensitive, and so the
html browsing. easy_install is case insensitive though, because it
uses the index.

So we should be case-insensitive everywhere, so in PEP 376 too.

>
>> get_installed_files(local=False) -> iterator of (path, md5, size)
>
> Will this also return the directories /created/ during the installation?
> For example, will it also contain the entry "docutils" .. along with
> "docutils/__init__.py"?

I don't think it's necessary to add "docutils" if
"docutils/__init__.py" is present

But for empty directories added during installation we should add the I guess.

So, I'll add a note.

>
> If not, how is the installer (pip, pypm, etc..) supposed to know which
> directories to remove (docutils/) and which directories not to remove
> (site-packages/, bin/, etc..)?
>
>> The new version of PEP 345 (XXX work in progress) extends the Metadata
>> standard and fullfills the requirements described in PEP 262, like the
>> REQUIRES section.
>
> Can you tell more about this?
>
> I see that PEP 262 allows both distributions names ('docutils') and
> modules/packages ('roman.py') in the 'Requires:' section. Is this how
> the new PEP is going to adhere to? Or, is it going to adhere to PEP
> 345's way of allowing *only* modules/packages?

The plan is to add what setuptools called "installed_requires", so
you can tell which *distributions* should be installed, no matter if
they are composed
of a single module, or many packages.

>
> In practice, I noticed that packages usually specify distribution names
> in their 'Requires:' file (or install_requires.txt in the case of
> setuptools). Hence, PyPM *assumes* the install requirements to be
> distribution name. But then .. most distributions have the same name as
> their primary module/package.

That's it yes: it will be distribution aware. If a module or package
has the same name
than the distribution name, it will make no difference.

>
> Ok, so PEP 345 also specifies the 'Provides:' header. Does
> easy_install/pip make use 'Provides:' at all when resolving
> dependencies? For example, does 'pip install sphinx' go look for all
> distributions that 'provides' the 'docutils' provision.. or does it
> simply get the distribution named 'docutils'?

setuptools doesn't. I don't think pip does.

btw: is PyPM a public project ?

Regards
Tarek

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

From setuptools at bugs.python.org  Wed Jul 15 11:45:52 2009
From: setuptools at bugs.python.org (raybaut)
Date: Wed, 15 Jul 2009 09:45:52 +0000
Subject: [Distutils] [issue80] sys.path corruption in pkg_resource.py
In-Reply-To: <1247651152.52.0.118813169398.issue80@psf.upfronthosting.co.za>
Message-ID: <1247651152.52.0.118813169398.issue80@psf.upfronthosting.co.za>


New submission from raybaut <pierre.raybaut at gmail.com>:

Tested on Windows XP with setuptools 0.6c9:
1. Open a Python intepreter in "C:\Python25\Lib\site-packages":
    a) run cmd.exe
    b) change directory to "C:\Python25\Lib\site-packages"
    c) run python.exe
2. type "from pkg_resources import resource_stream"
3. type "import sys; sys.path" -> you will see that
"C:\Python25\Lib\site-packages" has been removed from sys.path


The "C:\Python25\Lib\site-packages" sys.path entry is removed abusively by
"C:\Python25\lib\site-packages\pkg_resources.py", at line 2250, in insert_on:
del npath[np], path[np].

The reason is that, in interactive mode, the first entry of sys.path is '' - and
pkg_resources.py replace it by "C:\Python25\Lib\site-packages" at line 2228:
npath= map(_normalize_cached, path)
...and then considers it as a replicate to be removed at line 2250.

----------
messages: 327
nosy: raybaut
priority: bug
status: unread
title: sys.path corruption in pkg_resource.py

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue80>
_______________________________________________

From p.f.moore at gmail.com  Wed Jul 15 12:10:13 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 15 Jul 2009 11:10:13 +0100
Subject: [Distutils] PEP 376 - from PyPM's point of view
In-Reply-To: <94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
Message-ID: <79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>

2009/7/15 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
> Ratnakumar<sridharr at activestate.com> wrote:
>> Here are my comments regarding PEP 376 with respect to PyPM (the Python
>> package manager being developd at ActiveState)
>>
>>
>> Multiple versions: I understand that the PEP does not support
>> installation (thus uninstallation) of multiple versions of the same
>> package. Should this be explicitly mentioned in the PEP -- as
>> `get_distribution` API accepts only `name` argument, and not a `version`
>> argument?
>
> That's another can of worms ;)

:-)

> Before I answer here's a bit of background, i's a bit long but required, sorry
>
> For people that don't want to read the rest, here's the idea :
> multiple version support imho should
> be introduced later, if they are to be introduced, by extending PEP
> 302 protocol.

Disclaimer: I've only read the short version, so if some of this is
covered in the longer explanation, I apologise now.

-1.

In my view, multiple version support is not at all related to PEP 302
- or to core Python in general. The import statement has no concept of
versions, any version handling is done by explicit user manipulation
of sys.path.

PEP 302 is currently purely an import protocol. As such, it only cares
about locating the correct code to run to populate sys.modules['foo'].
Once the code has been located, there are a number of other details
that might be useful, hence the extensions like get_data,
get_filename, etc. But note that these are all *loader* extensions -
their starting point is an imported module.

The PEP 376 support I've just added is a *finder* extension, which is
working alongside the scanning of the container - but rather than
looking for modules, it's looking for distributions. Disappointingly
(for me) it turned out not to give much opportunity to share code -
the finder extensions could just as easily have been a completely
independent protocol.

PEP 376 support has added a requirement for 3 additional methods to
the existing 1 finder method in PEP 302. That's already a 300%
increase in complexity. I'm against adding any further complexity to
PEP 302 - in all honesty, I'd rather move towards PEP 376 defining its
*own* locator protocol and avoid any extra burden on PEP 302. I'm not
sure implementers of PEP 302 importers will even provide the current
PEP 376 extensions.

I propose that before the current prototype is turned into a final
(spec and) implementation, the PEP 302 extensions are extracted and
documented as an independent protocol, purely part of PEP 376. (This
*helps* implementers, as they can write support for, for example,
eggs, without needing to modify the existing egg importer). I'll
volunteer to do that work - but I won't start until the latest
iteration of questions and discussions has settled down and PEP 376
has achieved a stable form with the known issues addressed.

Of course, this is moving more and more towards saying that the design
of setuptools, with its generic means for locating distributions, etc
etc, is the right approach. We're reinventing the wheel here. But the
problem is that too many people dislike setuptools as it stands for it
to gain support. My understanding is that the current set of PEPs were
intended to be a stripped down, more generally acceptable subset of
setuptools. Let's keep them that way (and omit the complexities of
multi-version support).

If you want setuptools, you know where to get it...

Paul.

From fuzzyman at voidspace.org.uk  Wed Jul 15 12:17:38 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 15 Jul 2009 11:17:38 +0100
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
Message-ID: <4A5DACC2.5030609@voidspace.org.uk>

Paul Moore wrote:
> 2009/7/15 Tarek Ziad? <ziade.tarek at gmail.com>:
>   
>> On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
>> Ratnakumar<sridharr at activestate.com> wrote:
>>     
>>> Here are my comments regarding PEP 376 with respect to PyPM (the Python
>>> package manager being developd at ActiveState)
>>>
>>>
>>> Multiple versions: I understand that the PEP does not support
>>> installation (thus uninstallation) of multiple versions of the same
>>> package. Should this be explicitly mentioned in the PEP -- as
>>> `get_distribution` API accepts only `name` argument, and not a `version`
>>> argument?
>>>       
>> That's another can of worms ;)
>>     
>
> :-)
>
>   
>> Before I answer here's a bit of background, i's a bit long but required, sorry
>>
>> For people that don't want to read the rest, here's the idea :
>> multiple version support imho should
>> be introduced later, if they are to be introduced, by extending PEP
>> 302 protocol.
>>     
>
> Disclaimer: I've only read the short version, so if some of this is
> covered in the longer explanation, I apologise now.
>
> -1.
>   

I agree. People with versioning issues *should* be using virtualenv.

Michael Foord

> In my view, multiple version support is not at all related to PEP 302
> - or to core Python in general. The import statement has no concept of
> versions, any version handling is done by explicit user manipulation
> of sys.path.
>
> PEP 302 is currently purely an import protocol. As such, it only cares
> about locating the correct code to run to populate sys.modules['foo'].
> Once the code has been located, there are a number of other details
> that might be useful, hence the extensions like get_data,
> get_filename, etc. But note that these are all *loader* extensions -
> their starting point is an imported module.
>
> The PEP 376 support I've just added is a *finder* extension, which is
> working alongside the scanning of the container - but rather than
> looking for modules, it's looking for distributions. Disappointingly
> (for me) it turned out not to give much opportunity to share code -
> the finder extensions could just as easily have been a completely
> independent protocol.
>
> PEP 376 support has added a requirement for 3 additional methods to
> the existing 1 finder method in PEP 302. That's already a 300%
> increase in complexity. I'm against adding any further complexity to
> PEP 302 - in all honesty, I'd rather move towards PEP 376 defining its
> *own* locator protocol and avoid any extra burden on PEP 302. I'm not
> sure implementers of PEP 302 importers will even provide the current
> PEP 376 extensions.
>
> I propose that before the current prototype is turned into a final
> (spec and) implementation, the PEP 302 extensions are extracted and
> documented as an independent protocol, purely part of PEP 376. (This
> *helps* implementers, as they can write support for, for example,
> eggs, without needing to modify the existing egg importer). I'll
> volunteer to do that work - but I won't start until the latest
> iteration of questions and discussions has settled down and PEP 376
> has achieved a stable form with the known issues addressed.
>
> Of course, this is moving more and more towards saying that the design
> of setuptools, with its generic means for locating distributions, etc
> etc, is the right approach. We're reinventing the wheel here. But the
> problem is that too many people dislike setuptools as it stands for it
> to gain support. My understanding is that the current set of PEPs were
> intended to be a stripped down, more generally acceptable subset of
> setuptools. Let's keep them that way (and omit the complexities of
> multi-version support).
>
> If you want setuptools, you know where to get it...
>
> Paul.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>   


-- 
http://www.ironpythoninaction.com/


From peterbe at gmail.com  Wed Jul 15 13:29:05 2009
From: peterbe at gmail.com (Peter Bengtsson)
Date: Wed, 15 Jul 2009 04:29:05 -0700 (PDT)
Subject: [Distutils] Not installing the install_requires
Message-ID: <23d88c97-093e-405e-b971-24e90e563062@r2g2000yqm.googlegroups.com>

I've just made a package
http://pypi.python.org/pypi/premailer

To figure out if I've got it right I've tried installing it like
this::

$ cd /tmp
$ mkvirtualenv --no-site-packages test_premailer
$ easy_install premailer
Searching for premailer
Reading http://pypi.python.org/simple/premailer/
Page at http://pypi.python.org/simple/premailer/ links to .py file(s)
without version info; an index scan is required.
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
Reading http://www.peterbe.com/plog/premailer.py
Best match: premailer 1.0
Downloading http://pypi.python.org/packages/source/p/premailer/premailer-1.0.tar.gz#md5=08f31eb9ae5601ab7c5dd543ecd1e216
Processing premailer-1.0.tar.gz
Running premailer-1.0/setup.py -q bdist_egg --dist-dir /tmp/
easy_install-R730U5/premailer-1.0/egg-dist-tmp-epbGlW
Traceback (most recent call last):
  File "/home/peterbe/virtualenvs/test_premailer/bin/easy_install",
line 8, in <module>
    load_entry_point('setuptools==0.6c9', 'console_scripts',
'easy_install')()
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 1671, in main
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 1659, in with_ei_usage
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 1675, in <lambda>
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in
run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in
run_command
    cmd_obj.run()
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 211, in run
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 446, in easy_install
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 476, in install_item
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 655, in install_eggs
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 930, in build_and_install
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/command/
easy_install.py", line 919, in run_setup
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/sandbox.py", line 27,
in run_setup
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/sandbox.py", line 63,
in run
  File "/home/peterbe/virtualenvs/test_premailer/lib/python2.5/site-
packages/setuptools-0.6c9-py2.5.egg/setuptools/sandbox.py", line 29,
in <lambda>
  File "setup.py", line 4, in <module>
  File "/tmp/easy_install-R730U5/premailer-1.0/premailer/__init__.py",
line 1, in <module>
  File "/tmp/easy_install-R730U5/premailer-1.0/premailer/
premailer.py", line 5, in <module>
ImportError: No module named lxml.html


The setup.py
(see http://github.com/peterbe/premailer/tree/master)
contains the following:

      install_requires=[
        'lxml',
      ],

Why does easy_install not try to install lxml before it installs the
package?

From exarkun at divmod.com  Wed Jul 15 15:16:45 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Wed, 15 Jul 2009 09:16:45 -0400
Subject: [Distutils] Not installing the install_requires
In-Reply-To: <23d88c97-093e-405e-b971-24e90e563062@r2g2000yqm.googlegroups.com>
Message-ID: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>

On Wed, 15 Jul 2009 04:29:05 -0700 (PDT), Peter Bengtsson <peterbe at gmail.com> wrote:
>I've just made a package
>http://pypi.python.org/pypi/premailer
>
>To figure out if I've got it right I've tried installing it like
>this::
>
> [snip - install failure log]
>
>The setup.py
>(see http://github.com/peterbe/premailer/tree/master)
>contains the following:
>
>      install_requires=[
>        'lxml',
>      ],
>
>Why does easy_install not try to install lxml before it installs the
>package?

Because it has to evaluate your setup.py to learn that it requires lxml,
but your setup.py *also* requires lxml, apparently because you're trying
to avoid spelling our your package's version number more than once.  This
has been discussed recently on this list a couple times:

http://mail.python.org/pipermail/distutils-sig/2009-May/011913.html
http://mail.python.org/pipermail/distutils-sig/2009-July/012441.html

The gist is that there is no way to declare things which your setup.py
depends on, so if you depend on anything novel in it, it will probably
fail like this for someone.

Jean-Paul

From ziade.tarek at gmail.com  Wed Jul 15 16:00:27 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 15 Jul 2009 16:00:27 +0200
Subject: [Distutils] PEP 376 - from PyPM's point of view
In-Reply-To: <79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
Message-ID: <94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>

On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore<p.f.moore at gmail.com> wrote:
>
> Disclaimer: I've only read the short version, so if some of this is
> covered in the longer explanation, I apologise now.

Next time I won't put a short version ;)


>
> PEP 376 support has added a requirement for 3 additional methods to
> the existing 1 finder method in PEP 302. That's already a 300%
> increase in complexity. I'm against adding any further complexity to
> PEP 302 - in all honesty, I'd rather move towards PEP 376 defining its
> *own* locator protocol and avoid any extra burden on PEP 302. I'm not
> sure implementers of PEP 302 importers will even provide the current
> PEP 376 extensions.
>
> I propose that before the current prototype is turned into a final
> (spec and) implementation, the PEP 302 extensions are extracted and
> documented as an independent protocol, purely part of PEP 376. (This
> *helps* implementers, as they can write support for, for example,
> eggs, without needing to modify the existing egg importer). I'll
> volunteer to do that work - but I won't start until the latest
> iteration of questions and discussions has settled down and PEP 376
> has achieved a stable form with the known issues addressed.

Sure that makes sense. I am all for having these 302 extensions
flipped on PEP 376
side, then think about the "locator" protocol.

I am lagging a bit in the discussions, I have 10 messages left to read or so,
but the known issues I've listed so far are about the RECORD file and
absolute paths,
I am waiting for PJE example on the syntax he proposed for prefixes,
on the docutils example.

> Of course, this is moving more and more towards saying that the design
> of setuptools, with its generic means for locating distributions, etc
> etc, is the right approach.
> We're reinventing the wheel here. But the
> problem is that too many people dislike setuptools as it stands for it
> to gain support.

I don't think it's about setuptools design. I think it's more likely
to be about the fact
that there's no way in Python to install two different versions of the
same distribution
without "hiding" one from each other, using setuptools, virtualenv or
zc.buildout.

"installing" a distribution in Python means that its activated
globally, whereas people
need it locally at the application level.

> My understanding is that the current set of PEPs were
> intended to be a stripped down, more generally acceptable subset of
> setuptools. Let's keep them that way (and omit the complexities of
> multi-version support).
>
> If you want setuptools, you know where to get it...

Sure, but let's not forget that the multiple-version issue is a global
issue OS packagers
also meet. (setuptools is not the problem) :

- application Foo uses docutils 0.4 and doesn't work with docutils 0.5
- application Bar uses docutils 0.5

if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
shipped with it.

So right now application developers must use tools to isolate their
dependencies from
the rest of the system, using virtualenv or zc.buildout, and ship the
dependencies with them.
So they are sure that their applications are not broken by the system.

This is not optimal of course, because you end up with several
occurences of the same
versions sometimes. And can be a nightmare for os packagers and maintainers.

And virtualenv and such tools are now required when you develop
applications (mid-size and large ones)
and the "good practice" is to avoid any installation of any
distributions in Python itself.

So basically "site-packages" is a distribution location that is
avoided by everyone because it doesn't
know how to handle multiple versions. If we had a multi-versions
support protocol, that would
help os packagers and application developers to be friends again imho ;)

Regards
Tarek

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

From ziade.tarek at gmail.com  Wed Jul 15 16:03:08 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 15 Jul 2009 16:03:08 +0200
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <4A5DACC2.5030609@voidspace.org.uk>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<4A5DACC2.5030609@voidspace.org.uk>
Message-ID: <94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>

On Wed, Jul 15, 2009 at 12:17 PM, Michael
Foord<fuzzyman at voidspace.org.uk> wrote:
>> Disclaimer: I've only read the short version, so if some of this is
>> covered in the longer explanation, I apologise now.
>>
>> -1.
>>
>
> I agree. People with versioning issues *should* be using virtualenv.
>

Let's remove site-packages from Python then.

From peterbe at gmail.com  Wed Jul 15 16:25:28 2009
From: peterbe at gmail.com (Peter Bengtsson)
Date: Wed, 15 Jul 2009 07:25:28 -0700 (PDT)
Subject: [Distutils] Not installing the install_requires
In-Reply-To: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
References: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
Message-ID: <023730ff-d871-4821-bc7c-15f92385cf51@o15g2000yqm.googlegroups.com>



On Jul 15, 2:16?pm, Jean-Paul Calderone <exar... at divmod.com> wrote:
> On Wed, 15 Jul 2009 04:29:05 -0700 (PDT), Peter Bengtsson <pete... at gmail.com> wrote:
> >I've just made a package
> >http://pypi.python.org/pypi/premailer
>
> >To figure out if I've got it right I've tried installing it like
> >this::
>
> > [snip - install failure log]
>
> >The setup.py
> >(seehttp://github.com/peterbe/premailer/tree/master)
> >contains the following:
>
> > ? ? ?install_requires=[
> > ? ? ? ?'lxml',
> > ? ? ?],
>
> >Why does easy_install not try to install lxml before it installs the
> >package?
>
> Because it has to evaluate your setup.py to learn that it requires lxml,
> but your setup.py *also* requires lxml, apparently because you're trying
> to avoid spelling our your package's version number more than once. ?This
> has been discussed recently on this list a couple times:
>

Ok. Thanks for spotting that. I'll change the package so that I
manually type in the version number.
Or even better actually. I'll add a file into the package called
version.txt and read that on the fly.

I've got a more pressing problem now, when I try to easy_install my
package it tries to install lxml even though it's already installed!

(djangopeoplenet)peterbe at trillian:~/djangopeoplenet $ cat `which
easy_install` | head -n 1
#!/home/peterbe/virtualenvs/djangopeoplenet/bin/python
(djangopeoplenet)peterbe at trillian:~/djangopeoplenet $ /home/peterbe/
virtualenvs/djangopeoplenet/bin/python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxml
>>>
(djangopeoplenet)peterbe at trillian:~/djangopeoplenet $ easy_install
premailer
Searching for premailer
Best match: premailer 1.2
Processing premailer-1.2-py2.5.egg
premailer 1.2 is already the active version in easy-install.pth

Using /home/peterbe/virtualenvs/djangopeoplenet/lib/python2.5/site-
packages/premailer-1.2-py2.5.egg
Processing dependencies for premailer
Searching for lxml
Reading http://pypi.python.org/simple/lxml/
Reading http://codespeak.net/lxml
Best match: lxml 2.2.2
Downloading http://codespeak.net/lxml/lxml-2.2.2.tgz
Processing lxml-2.2.2.tgz
Running lxml-2.2.2/setup.py -q bdist_egg --dist-dir /tmp/
easy_install-7jsFdx/lxml-2.2.2/egg-dist-tmp-Ezd7Ad
Building lxml version 2.2.2.
NOTE: Trying to build without Cython, pre-generated 'src/lxml/
lxml.etree.c' needs to be available.
Using build configuration of libxslt 1.1.24
Building against libxml2/libxslt in the following directory: /usr/lib
src/lxml/lxml.etree.c:4:20: error: Python.h: No such file or directory
src/lxml/lxml.etree.c:5:26: error: structmember.h: No such file or
directory
src/lxml/lxml.etree.c:7:6: error: #error Python headers needed to
compile C extensions, please install development version of Python.
error: Setup script exited with error: command 'gcc' failed with exit
status 1


Why is this a problem? Getting lxml to build in a virtual environment
is far from trivial and that's why I (amongst others) prefer to use OS
packages (debian apt in my case).

From peterbe at gmail.com  Wed Jul 15 16:43:58 2009
From: peterbe at gmail.com (Peter Bengtsson)
Date: Wed, 15 Jul 2009 07:43:58 -0700 (PDT)
Subject: [Distutils] Not installing the install_requires
In-Reply-To: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
References: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
Message-ID: <3d56057b-f8cd-40b0-9ae9-997b201e6d13@h18g2000yqj.googlegroups.com>

Crap!
That didn't work either!
IOError: [Errno 20] Not a directory: '/home/peterbe/virtualenvs/
djangopeoplenet/lib/python2.5/site-packages/premailer-1.2-py2.5.egg/
premailer/version.txt'

This must be because of some egg magic that I don't understand.
What I did was this (in premailer.py):

__version__ = open(os.path.join(os.path.dirname(__file__),
'version.txt')
                   ).read().strip()

That works if the thing is installed.
But not when trying to use it as an egg.

I tried to read P.J Eby's reply regarding using execfile() but it went
over my head.


On Jul 15, 2:16?pm, Jean-Paul Calderone <exar... at divmod.com> wrote:
> On Wed, 15 Jul 2009 04:29:05 -0700 (PDT), Peter Bengtsson <pete... at gmail.com> wrote:
> >I've just made a package
> >http://pypi.python.org/pypi/premailer
>
> >To figure out if I've got it right I've tried installing it like
> >this::
>
> > [snip - install failure log]
>
> >The setup.py
> >(seehttp://github.com/peterbe/premailer/tree/master)
> >contains the following:
>
> > ? ? ?install_requires=[
> > ? ? ? ?'lxml',
> > ? ? ?],
>
> >Why does easy_install not try to install lxml before it installs the
> >package?
>
> Because it has to evaluate your setup.py to learn that it requires lxml,
> but your setup.py *also* requires lxml, apparently because you're trying
> to avoid spelling our your package's version number more than once. ?This
> has been discussed recently on this list a couple times:
>
> http://mail.python.org/pipermail/distutils-sig/2009-May/011913.htmlhttp://mail.python.org/pipermail/distutils-sig/2009-July/012441.html
>
> The gist is that there is no way to declare things which your setup.py
> depends on, so if you depend on anything novel in it, it will probably
> fail like this for someone.
>
> Jean-Paul
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-... at python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

From p.f.moore at gmail.com  Wed Jul 15 17:14:30 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 15 Jul 2009 16:14:30 +0100
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<4A5DACC2.5030609@voidspace.org.uk>
	<94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>
Message-ID: <79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>

2009/7/15 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Wed, Jul 15, 2009 at 12:17 PM, Michael
> Foord<fuzzyman at voidspace.org.uk> wrote:
>>> Disclaimer: I've only read the short version, so if some of this is
>>> covered in the longer explanation, I apologise now.
>>>
>>> -1.
>>>
>>
>> I agree. People with versioning issues *should* be using virtualenv.
>>
>
> Let's remove site-packages from Python then.

If virtualenv/py2exe/cx_Freeze/py2app don't offer a solution, then
maybe you're right.

For me, py2exe (and a clean virtual machine if I require an absolutely
pristine environment, I guess virtualenv would help here too) does
what I need for application packaging. But I'll freely admit that my
needs are minimal.

Bluntly, as Python stands, import and sys.path do not offer any core
support for multiple versions. Custom solutions can be built on top of
that - that's what setuptools does. But they are precisely that -
custom solutions, and should be supported as such, outside the core
(and stdlib).

If standard Python support for multi-version imports is required (it's
not by me, but I accept that some people want it), then it should be
designed in thoughout:

- how do I import version 0.7.1 of package foo, rather than 0.7.2?
- how do I use foo 0.8 at my interactive prompt, and import bar 0.2
which relies on foo 0.7.1?
- what happens if I import foo 2.0 (which requires baz 0.1) and bar
1.5 (which requires baz 0.2)?
- what does "import foo" (without a version number) mean? Is it
different if it's at the command line or in bar 0.5 (which explicitly
declares a dependency on foo 0.7 in its setup.py)? Does the answer to
that mean that imports always need to read dependency information?
- does your head hurt yet? I could go on...

Any PEP dealing with multi versions should address these issues. It's
a big area, and I have no interest in it myself, but I do have an
interest in avoiding partial solutions which only look at some of the
questions that might arise.

Look - I really, really don't mind if people use setuptools. Honest.
But I do mind if core python gets changed to support little bits of
what setuptools does, adding complexity to deal with issues that
setuptools handles, but without making it possible to avoid using
setuptools. Where's the benefit to anyone then?

Paul.

From him at online.de  Wed Jul 15 17:16:41 2009
From: him at online.de (=?ISO-8859-1?Q?Joachim_K=F6nig?=)
Date: Wed, 15 Jul 2009 17:16:41 +0200
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
Message-ID: <4A5DF2D9.6050403@online.de>

Tarek Ziad? wrote:
> So basically "site-packages" is a distribution location that is
> avoided by everyone because it doesn't
> know how to handle multiple versions. 
I think you overrate the importance of having multiple versions of a 
package available
for the same python interpreter. If you have m different versions of n 
packages then
you could have n**m different combinations for an application so you need a
possiblilty to select one combination from n**m possible ones at application
startup time. Is this really worth it?

> If we had a multi-versions
> support protocol, that would
> help os packagers and application developers to be friends again imho ;)
>   
> Let's remove site-packages from Python then.
The _one_ site-packages folder stands for _one_ python interpreter. All 
the clever
efforts to provide a set of package versions at runtime to an 
application (that uses
the singleton python interpreter) do logically create a new python 
interpreter with
a site-packages folder that contains just the versions of the packages 
the application
needs, unfortunately by mucking with PYTHONPATH and <package>.pth, 
site.py etc
making it very difficult to understand what is happening for the joe 
average python developer.




From pje at telecommunity.com  Wed Jul 15 17:45:21 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Jul 2009 11:45:21 -0400
Subject: [Distutils] Not installing the install_requires
In-Reply-To: <3d56057b-f8cd-40b0-9ae9-997b201e6d13@h18g2000yqj.googlegro
	ups.com>
References: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
	<3d56057b-f8cd-40b0-9ae9-997b201e6d13@h18g2000yqj.googlegroups.com>
Message-ID: <20090715154218.97F943A411C@sparrow.telecommunity.com>

At 07:43 AM 7/15/2009 -0700, Peter Bengtsson wrote:
>Crap!
>That didn't work either!
>IOError: [Errno 20] Not a directory: '/home/peterbe/virtualenvs/
>djangopeoplenet/lib/python2.5/site-packages/premailer-1.2-py2.5.egg/
>premailer/version.txt'
>
>This must be because of some egg magic that I don't understand.
>What I did was this (in premailer.py):
>
>__version__ = open(os.path.join(os.path.dirname(__file__),
>'version.txt')
>                    ).read().strip()


from pkg_resources import resource_string
__version__ = resource_string(__name__, 'version.txt').strip()

Make sure that you either list 'version.txt' in your setup() 
data_files or else use include_package_data=True and a revision 
control system that includes the version.txt file, or else the 
version.txt won't be included in your sdists and eggs.


From ziade.tarek at gmail.com  Wed Jul 15 17:51:13 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 15 Jul 2009 17:51:13 +0200
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<4A5DACC2.5030609@voidspace.org.uk>
	<94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>
	<79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
Message-ID: <94bdd2610907150851u1c022d10i5bc6b6d9b581bc17@mail.gmail.com>

On Wed, Jul 15, 2009 at 5:14 PM, Paul Moore<p.f.moore at gmail.com> wrote:
> 2009/7/15 Tarek Ziad? <ziade.tarek at gmail.com>:
>> On Wed, Jul 15, 2009 at 12:17 PM, Michael
>> Foord<fuzzyman at voidspace.org.uk> wrote:
>>>> Disclaimer: I've only read the short version, so if some of this is
>>>> covered in the longer explanation, I apologise now.
>>>>
>>>> -1.
>>>>
>>>
>>> I agree. People with versioning issues *should* be using virtualenv.
>>>
>>
>> Let's remove site-packages from Python then.
>
> If virtualenv/py2exe/cx_Freeze/py2app don't offer a solution, then
> maybe you're right.

They do offer a solution, but these solution are hard to maintain from
a OS packager point of view.

In any case I don't see any use case to have a "site-packages"
remaining in Python itself.

> If standard Python support for multi-version imports is required (it's
> not by me, but I accept that some people want it), then it should be
> designed in thoughout:
> [..]
>
> Any PEP dealing with multi versions should address these issues. It's
> a big area, and I have no interest in it myself, but I do have an
> interest in avoiding partial solutions which only look at some of the
> questions that might arise.
>
> Look - I really, really don't mind if people use setuptools. Honest.
> But I do mind if core python gets changed to support little bits of
> what setuptools does, adding complexity to deal with issues that
> setuptools handles, but without making it possible to avoid using
> setuptools. Where's the benefit to anyone then?

I totally agree. But I think that the boundary between what Python+stdlib
should provide feature-wise and what third party packages provides is
still fuzzy and should
be made clearer.

At some point, third party projects are trying hard to isolate dependencies
because they can't do it with the execution environment Python sets by
default when
you launch a script or an interpreter.

site.py loads site-packages and user site-packages at startup
basically, and you can
use PYTHONPATH / sys.path to add more, but that's partially shared by all apps.

To address this issued, a project like zc.buildout will create a local
repository of distributions, and will
change sys.path on the fly so the local repository is used.

virtualenv on its side creates an isolated Python installation for
your application,

So If the stdlib doesn't provide a standard protocol that goes further
than that,
people that have this need will continue to use zc.buildout or
virtualenv and install many times
the same libs on a system.

It's perfectly fine from an application developer PoV, but it make
site-packages obsoletes and
every application installed that way looks like a black box for os
packagers. They don't want that.

At the end, application developers have to care about the way their applications
dependencies are installed, were they should just give the list of
those dependencies,
and let any package manager project install them.

If these matters are not adressed by Python sdtlib, then we should
remove the loading of
site-packages at Python startup completely, and make it cristal clear
that it's not the core/stdlib
problem.

Otherwise we should think hard about how to let os packagers manage a
single repository
of Python distributions (and multiple versions) and how application
developers could use them from within
their applications. This protocol imho could be in the sdtlib even if
the implementation
is outside, but that's just me.

In any case, these issues can be postponed after PEP 376, because
that's a another (bigger) part of the puzzle.

Regards
Tarek

From p.f.moore at gmail.com  Wed Jul 15 17:59:56 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 15 Jul 2009 16:59:56 +0100
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
	<5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>
Message-ID: <79990c6b0907150859h6d7ad65g67e179c31aaa81f9@mail.gmail.com>

2009/7/15 David Cournapeau <cournape at gmail.com>:
> As was stated by Debian packagers on the distutils ML, the problem is
> that docutils 0.5 breaks packages which work with docutils 0.4 in the
> first place.
>
> http://www.mail-archive.com/distutils-sig at python.org/msg05775.html
>
> And current hacks to work around lack of explicit version handling for
> module import is a maintenance burden:
>
> http://www.mail-archive.com/distutils-sig at python.org/msg05742.html
>
> setuptools has given the incentive to use versioning as a workaround
> for API/ABI compatibility. That's the core problem, and most problems
> brought by setuptools (sys.path and .pth hacks with the unreliability
> which ensued) are consequences of this. I don't see how virtualenv
> solves anything in that regard for deployment issues. I doubt using
> things like virtualenv will make OS packagers happy.

So, I think what you're saying is:

- The real issues is packages not maintaining backward compatibility (I agree)
- Setuptools is a workaround (I agree, at least it's *one* workaround)
- Virtualenv isn't a workaround (I don't know virtualenv, I'll take
your word for it)

Three points:

- When building *applications*, bundling everything (py2exe-style) is
an alternative workaround - universal on Windows, apparently uncommon
on Unix/Linux.
- When managing multiple packages in a "toolkit" style interactive
Python installation, I'm not aware of a good solution (other than
avoiding core that hits this issue in the first place).
- I do not believe that it's clear that sanctioning the setuptools
workaround as the "right" approach by building it into the Python
core/stdlib is the right thing to do.

Paul.

From ziade.tarek at gmail.com  Wed Jul 15 18:00:48 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 15 Jul 2009 18:00:48 +0200
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <4A5DF2D9.6050403@online.de>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
	<4A5DF2D9.6050403@online.de>
Message-ID: <94bdd2610907150900j62a249fwcf88a188d71c5a51@mail.gmail.com>

On Wed, Jul 15, 2009 at 5:16 PM, Joachim K?nig<him at online.de> wrote:
> Tarek Ziad? wrote:
>>
>> So basically "site-packages" is a distribution location that is
>> avoided by everyone because it doesn't
>> know how to handle multiple versions.
>
> I think you overrate the importance of having multiple versions of a package
> available
> for the same python interpreter. If you have m different versions of n
> packages then
> you could have n**m different combinations for an application so you need a
> possiblilty to select one combination from n**m possible ones at application
> startup time. Is this really worth it?

When you create an application that uses several libs, and when you
create your distribution,
you end up pinning a version for each one of your dependency to avoid
any problems.

While it's workable in a small application to list the dependencies in
a text file, and let your users
install them manually, it's impossible in bigger applications.

Applications based on Zope for example have **hundreds** of dependencies
you need to have installed, in very specific versions.

If you install a Zope 2 app on your system, and a Zope 3 one, you have
good chances of
breaking them because the "zope.schema" distribution is incompatible.

So either each application ships its own collection of dependencies
and ignore site-packages (that's what zope-based
applications does with zc.buildout), either they have a way to pick
the right version of each package.


>
>> If we had a multi-versions
>> support protocol, that would
>> help os packagers and application developers to be friends again imho ;)
>> ?Let's remove site-packages from Python then.
>
> The _one_ site-packages folder stands for _one_ python interpreter. All the
> clever
> efforts to provide a set of package versions at runtime to an application
> (that uses
> the singleton python interpreter) do logically create a new python
> interpreter with
> a site-packages folder that contains just the versions of the packages the
> application
> needs, unfortunately by mucking with PYTHONPATH and <package>.pth, site.py
> etc
> making it very difficult to understand what is happening for the joe average
> python developer.

That's what we have nowadays. python packages installed in different places,
and scripts tweaking the path to launch an application with them.

From pje at telecommunity.com  Wed Jul 15 18:21:32 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Jul 2009 12:21:32 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.co
 m>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
Message-ID: <20090715161829.E45BE3A4116@sparrow.telecommunity.com>

At 11:10 AM 7/15/2009 +0100, Paul Moore wrote:
>I propose that before the current prototype is turned into a final
>(spec and) implementation, the PEP 302 extensions are extracted and
>documented as an independent protocol, purely part of PEP 376. (This
>*helps* implementers, as they can write support for, for example,
>eggs, without needing to modify the existing egg importer).

Btw, this is why setuptools chose to implement these things as 
adapters or generic functions in pkg_resources (and in the vestigial 
bits that were added to python 2.5's pkgutil).

So as you can see, trying to solve these particular problems tends to 
lead to reinventing setuptools or at least portions thereof.  ;-)



>But the
>problem is that too many people dislike setuptools as it stands for it
>to gain support. My understanding is that the current set of PEPs were
>intended to be a stripped down, more generally acceptable subset of
>setuptools. Let's keep them that way (and omit the complexities of
>multi-version support).

Even without multi-version support, the parts of PEP 376 that aren't 
about uninstallation are still reinventing chunks of 
pkg_resources.  Had pkg_resources been in the stdlib a couple years 
back (note that bugs and changes in it are still quite rare), the PEP 
376 bits for pkgutil could have been focused strictly on 
uninstallation, and just reused pkg_resources API for finding 
distributions, reading metadata, getting version info, etc. etc.

All that stuff is extremely stable code, very widely used for a very 
long time.  If politics is the only thing keeping it from being used, 
then that's a pretty sad statement about the community, given that 
pkg_resources is not to blame for 99% of what people complain about 
in relation to setuptools.  All pkg_resources does is find stuff (on 
request) and maybe add it to sys.path (on request), pull out data and 
metadata from distributions (on request), or set up namespace 
packages (on request).

So if politics demands that it be rejected by association with 
"setuptools", then just search-and-replace the API, PEP 8-ify it, 
call it something different, and lie to everyone about where it came 
from.  I won't tell if you won't.  ;-)


From pje at telecommunity.com  Wed Jul 15 18:27:11 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Jul 2009 12:27:11 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.co
 m>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<4A5DACC2.5030609@voidspace.org.uk>
	<94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>
	<79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
Message-ID: <20090715162407.AD8723A4116@sparrow.telecommunity.com>

At 04:14 PM 7/15/2009 +0100, Paul Moore wrote:
>Look - I really, really don't mind if people use setuptools. Honest.
>But I do mind if core python gets changed to support little bits of
>what setuptools does, adding complexity to deal with issues that
>setuptools handles, but without making it possible to avoid using
>setuptools.

I don't see how that's being proposed.  Nothing in PEP 376 requires 
setuptools or any portion thereof, AFAICT.


From pje at telecommunity.com  Wed Jul 15 18:30:39 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Jul 2009 12:30:39 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <4A5DF2D9.6050403@online.de>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
	<4A5DF2D9.6050403@online.de>
Message-ID: <20090715162736.B54D33A4116@sparrow.telecommunity.com>

At 05:16 PM 7/15/2009 +0200, Joachim K?nig wrote:
>f you have m different versions of n packages then
>you could have n**m different combinations for an application so you need a
>possiblilty to select one combination from n**m possible ones at application
>startup time. Is this really worth it?

Obviously yes, as neither buildout nor setuptools would exist otherwise.  ;-)
Nor would Fedora be packaging certain library versions as eggs 
specifically to get certain multi-version scenarios to work.

The specific solutions for handling n*m problems aren't fantastic, 
but they are clearly needed.

(Buildout, btw, actually hardwires the n*m choice at install time, 
which is probably better for production situations than setuptools' 
dynamic approach.)


From pje at telecommunity.com  Wed Jul 15 18:34:00 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Jul 2009 12:34:00 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <79990c6b0907150859h6d7ad65g67e179c31aaa81f9@mail.gmail.com
 >
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
	<5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>
	<79990c6b0907150859h6d7ad65g67e179c31aaa81f9@mail.gmail.com>
Message-ID: <20090715163056.B34B63A4116@sparrow.telecommunity.com>

At 04:59 PM 7/15/2009 +0100, Paul Moore wrote:
>- Virtualenv isn't a workaround (I don't know virtualenv, I'll take
>your word for it)

It's not one for system package maintainers because it would 
effectively be managing multiple instances of 'python'.  Really not a 
suitable solution.


>- I do not believe that it's clear that sanctioning the setuptools
>workaround as the "right" approach by building it into the Python
>core/stdlib is the right thing to do.

I still don't understand how we're doing that.


From ziade.tarek at gmail.com  Wed Jul 15 19:07:34 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 15 Jul 2009 19:07:34 +0200
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <20090715161829.E45BE3A4116@sparrow.telecommunity.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<20090715161829.E45BE3A4116@sparrow.telecommunity.com>
Message-ID: <94bdd2610907151007p7cd5d6bof32612bec2908e43@mail.gmail.com>

2009/7/15 P.J. Eby <pje at telecommunity.com>:
[...]
> So if politics demands that it be rejected by association with "setuptools",
> then just search-and-replace the API, PEP 8-ify it, call it something
> different, and lie to everyone about where it came from. ?I won't tell if
> you won't. ?;-)

While setuptools did address some issues, we are now adressing in PEP 376,
it does a *lot* of other things and it's impossible to extract the
features we would
want to re-use. e.g. what I would call the good bits.

The prototype code we are building on bitbucket is clear, easy to
understand, read and adopt and already PEP8-fied (which is required
for sdtlib inclusion)

Reading and understanding pkg_resources requires a lot of time.

A side note on setuptools, I don't mean to be rude here or to tell you
what you should do,
really, but:

  While I am very glad that you are part of PEP 376 discussions, and
that you helped
  on almost every section of it, I really don't understand why you
keep on pushing setuptools
  *code* here and at distutils-SIG since you don't maintain it anymore
(the last commit is > 9 months)

  Part of the rejection of setuptools is because of that and because you don't
  bless anyone to maintain the project code base, or do releases,
neither to communicate clearly
  on what's its roadmap.

Regards
Tarek

From SridharR at activestate.com  Wed Jul 15 19:38:21 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Wed, 15 Jul 2009 10:38:21 -0700
Subject: [Distutils] PEP 376 - from PyPM's point of view
In-Reply-To: <94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
Message-ID: <op.uw4dx7ttbrrvlq@double>

On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

>>> get_installed_files(local=False) -> iterator of (path, md5, size)
>>
>> Will this also return the directories /created/ during the installation?
>> For example, will it also contain the entry "docutils" .. along with
>> "docutils/__init__.py"?
>
> I don't think it's necessary to add "docutils" if
> "docutils/__init__.py" is present
>
> But for empty directories added during installation we should add the I  
> guess.
>
> So, I'll add a note.

It seems that you overlooked the below paragraph.

>> If not, how is the installer (pip, pypm, etc..) supposed to know which
>> directories to remove (docutils/) and which directories not to remove
>> (site-packages/, bin/, etc..)?

Quoting from the PEP:

[quote]'(...)uninstall uses the APIs described earlier and remove all  
unique files, as long as their hash didn't change. Then it removes empty  
directories left behind.'[endquote]

Let's assume that site-packages/ contained only one package 'Foo'. Will  
uninstall('Foo') remove the site-packages/ directory just because it  
turned out to be empty after removing 'Foo'? To explain, let's assume the  
RECORD of 'Foo' contains:

$ cat RECORD
Foo/__init__.py
Foo/bar/__init__.py
Foo/bar/test.py

and according to what you wrote in the PEP ("it removes empty directories  
left behind"):

$ python -m distutils.util.uninstall Foo
rm /.../site-packages/Foo/__init__.py
rm /.../site-packages/Foo/bar/__init__.py
rm /.../site-packages/Foo/bar/test.py
rm empty dir /.../site-packages/Foo/bar
rm empty dir /.../site-packages/Foo/
rm empty dir /.../site-packages/        # !!!!!

it also remove the site-packages directory!

Then there is ~/python26/bin, ~/python26/include, ~/python26/etc, etc.. Do  
you see my point?

> btw: is PyPM a public project ?

If by 'public', you meant open source, then no.

-srid

From p.f.moore at gmail.com  Wed Jul 15 19:40:28 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 15 Jul 2009 18:40:28 +0100
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <20090715161829.E45BE3A4116@sparrow.telecommunity.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<20090715161829.E45BE3A4116@sparrow.telecommunity.com>
Message-ID: <79990c6b0907151040h5d37348cn8ee09755ba17f9cd@mail.gmail.com>

2009/7/15 P.J. Eby <pje at telecommunity.com>:
> At 11:10 AM 7/15/2009 +0100, Paul Moore wrote:
>>
>> I propose that before the current prototype is turned into a final
>> (spec and) implementation, the PEP 302 extensions are extracted and
>> documented as an independent protocol, purely part of PEP 376. (This
>> *helps* implementers, as they can write support for, for example,
>> eggs, without needing to modify the existing egg importer).
>
> Btw, this is why setuptools chose to implement these things as adapters or
> generic functions in pkg_resources (and in the vestigial bits that were
> added to python 2.5's pkgutil).
>
> So as you can see, trying to solve these particular problems tends to lead
> to reinventing setuptools or at least portions thereof. ?;-)

Yes, that's the impression I'm getting :-)

And yet you seem resistant to reading any message into the fact that
people find it easier to solve the problems from scratch than to
extract the relevant parts of the existing code. To be explicit - it's
too flipping hard to identify, extract and tidy up the appropriate
bits of the setuptools code! (Disclaimer: I haven't looked at the code
for some time - if the style has changed utterly in the last 2 years
or so, so that it no longer resembles the style of the pkgutil code
you contributed to the stdlib, I'll retract that criticism of the
setuptools codebase).

>> But the
>> problem is that too many people dislike setuptools as it stands for it
>> to gain support. My understanding is that the current set of PEPs were
>> intended to be a stripped down, more generally acceptable subset of
>> setuptools. Let's keep them that way (and omit the complexities of
>> multi-version support).
>
> Even without multi-version support, the parts of PEP 376 that aren't about
> uninstallation are still reinventing chunks of pkg_resources. ?Had
> pkg_resources been in the stdlib a couple years back (note that bugs and
> changes in it are still quite rare), the PEP 376 bits for pkgutil could have
> been focused strictly on uninstallation, and just reused pkg_resources API
> for finding distributions, reading metadata, getting version info, etc. etc.
>
> All that stuff is extremely stable code, very widely used for a very long
> time. ?If politics is the only thing keeping it from being used, then that's
> a pretty sad statement about the community, given that pkg_resources is not
> to blame for 99% of what people complain about in relation to setuptools.
> ?All pkg_resources does is find stuff (on request) and maybe add it to
> sys.path (on request), pull out data and metadata from distributions (on
> request), or set up namespace packages (on request).

I don't think it's quite "politics" as you describe it. Maybe
"marketing", if you want a simple tag for it.

The problem is that the setuptools "brand name" is associated with a
lot of baggage, that maybe it doesn't deserve, but equally no-one
seems interested in addressing. It's certainly not a technical
argument at this point. And yet you counter criticisms with technical
responses. But if I recall the history correctly, one of the initial
goals of setuptools was to become a de-facto standard precisely by
marketing and filling the ecological niche - a goal it has achieved
fantastically well. The fact that in doing so it alienated certain
groups is a more or less inevitable consequence.

My argument - which you may well disagree with - is that the
"setuptools ecosystem" (by which I mean
setuptools/easy_install/pkg_resources/eggs and the various subsystems
around these) is documented in a way which is:

- confusing to the casual user
- not at all modular (ie, it's impossible to easily pick out individual "bits")
- full of new concepts, so it's hard to find an easy place to start from

There's not much technically at issue here, it's all about presentation.

> So if politics demands that it be rejected by association with "setuptools",
> then just search-and-replace the API, PEP 8-ify it, call it something
> different, and lie to everyone about where it came from. ?I won't tell if
> you won't. ?;-)

Unless the documentation and code is cleaned up, it'll still be
obvious from the style where it came from - that's the problem. Who's
going to maintain the code within the standard library, and are they
happy with the style of the existing code - even with the serial
numbers filed off?

And of course, someone has to do the clean-up. It seems to me that the
fact that people are more inclined to reinvent the code than to try to
understand the existing codebase and pick out the relevant bits, says
something important about how easy it would be to maintain the
existing code within the Python core...

Paul.

From tjreedy at udel.edu  Wed Jul 15 19:43:19 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 15 Jul 2009 13:43:19 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>	<4A5DACC2.5030609@voidspace.org.uk>	<94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>
	<79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
Message-ID: <h3l4fk$3fe$1@ger.gmane.org>

Paul Moore wrote:


> - how do I import version 0.7.1 of package foo, rather than 0.7.2?

Augment import to recognize versioned names?

import foo_0_7_1

> - how do I use foo 0.8 at my interactive prompt, and import bar 0.2
> which relies on foo 0.7.1?

bar does import foo_0_7_2

> - what happens if I import foo 2.0 (which requires baz 0.1) and bar
> 1.5 (which requires baz 0.2)?

one import baz_0_1 and the other baz_0_2

Terry Jan Reedy


From tjreedy at udel.edu  Wed Jul 15 19:43:25 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 15 Jul 2009 13:43:25 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <94bdd2610907150851u1c022d10i5bc6b6d9b581bc17@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>	<4A5DACC2.5030609@voidspace.org.uk>	<94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>	<79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
	<94bdd2610907150851u1c022d10i5bc6b6d9b581bc17@mail.gmail.com>
Message-ID: <h3l4fp$3fe$2@ger.gmane.org>

Tarek Ziad? wrote:

> In any case I don't see any use case to have a "site-packages"
> remaining in Python itself.

I have and am using it.  Where else would you have me put library 
packages meant to be accessible by any Python program?

Terry Jan Reedy


From SridharR at activestate.com  Wed Jul 15 19:52:09 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Wed, 15 Jul 2009 10:52:09 -0700
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
	<5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>
Message-ID: <op.uw4ek7eubrrvlq@double>

On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau <cournape at gmail.com>  
wrote:

>> if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
>> shipped with it.
> As was stated by Debian packagers on the distutils ML, the problem is
> that docutils 0.5 breaks packages which work with docutils 0.4 in the
> first place.

Thus I am -1 on multi-version support .. and would rather have the python  
developers make their packages backward compatible just like what Armin  
did with Jinja and Jinja2. Debian at the moment has only one package  
"python-docutils" which is 0.5. How is a debian application supposed to  
depend upon 0.4? With Jinja, there is no problem .. there are  
'python-jinja' and 'python-jinja2'. Similarly, CherryPy should have gone  
with renaming their package names to CherryPy2 and CherryPy3.

-srid


PS: Quoting from a fellow developer:

> > [...] it sounds like CherryPy 3.x is really an incompatible
> > module that just kept the old name. That is rather unfortunate, but can
> > sometimes happen.
>  I have never seen a Python package changing its name (when significantly
> changing API, design, etc..). The only exception that comes to my mind
> is Jinja2 (renamed from 'Jinja'):
>  [Armin] (...) Because we love backwards compatibility these changes will
> go into a package called "jinja2"
> <http://lucumr.pocoo.org/2008/4/13/jinja2-making-things-awesome>

Well, congrats to the Jinja team then!  The others will eventually learn...
Mixing incompatible APIs in a single namespace and using a non-standardized
version numbering system to keep things apart creates a world of pain!

> The challenge however is in compartmentalizing versions according to
> their major release numbers. Versioning in the Python world is already a
> mess which we are beginning to sort out:
> http://wiki.python.org/moin/Distutils/VersionComparison (PyPM relies on
> this standard and the ongoing implementation - verlib.py)

How embarrassing for a cult that prides itself on having only one way for
everything they do...   CPAN versions numbers are just as much if not
more of a mess, but at least you can argue that it is the price for there
being "more than one way to do it".

From pje at telecommunity.com  Wed Jul 15 20:12:44 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Jul 2009 14:12:44 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <94bdd2610907151007p7cd5d6bof32612bec2908e43@mail.gmail.com
 >
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<20090715161829.E45BE3A4116@sparrow.telecommunity.com>
	<94bdd2610907151007p7cd5d6bof32612bec2908e43@mail.gmail.com>
Message-ID: <20090715180942.407DB3A403A@sparrow.telecommunity.com>

At 07:07 PM 7/15/2009 +0200, Tarek Ziad? wrote:
>   Part of the rejection of setuptools is because of that and 
> because you don't
>   bless anyone to maintain the project code base, or do releases,
>neither to communicate clearly
>   on what's its roadmap.

Jim Fulton and Ian Bicking have been officially blessed for *years*, 
and I've posted plenty about what's on its roadmap.


>I really don't understand why you keep on pushing setuptools *code*

pkg_resources is not setuptools; its stability and revision history 
are very different, as it addresses different problems.


From pje at telecommunity.com  Wed Jul 15 20:20:10 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Jul 2009 14:20:10 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <79990c6b0907151040h5d37348cn8ee09755ba17f9cd@mail.gmail.co
 m>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<20090715161829.E45BE3A4116@sparrow.telecommunity.com>
	<79990c6b0907151040h5d37348cn8ee09755ba17f9cd@mail.gmail.com>
Message-ID: <20090715181705.E22823A403A@sparrow.telecommunity.com>

At 06:40 PM 7/15/2009 +0100, Paul Moore wrote:
>And of course, someone has to do the clean-up. It seems to me that the
>fact that people are more inclined to reinvent the code than to try to
>understand the existing codebase and pick out the relevant bits, says
>something important about how easy it would be to maintain the
>existing code within the Python core...

That's normal for any code that contains "legacy" issues, which is 
why people always prefer rewriting code they don't understand: it's 
more fun to write than to read.  However, as Joel Spolsky has well 
explained, rewriting such code inevitably means that you must 
re-learn the lessons that were learned by the original author.

It seems like a waste, but then, I suppose those lessons must be 
relearned *some* way.  I just think it'd be better if, having 
re-learned most of the lessons by trying to rewrite, one could then 
go back and learn the rest from the code.  ;-)

That having been said, it's obviously a dead parrot... one which I 
will now cease attempting to revive.


From chrism at plope.com  Wed Jul 15 19:47:35 2009
From: chrism at plope.com (Chris McDonough)
Date: Wed, 15 Jul 2009 13:47:35 -0400
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <20090715163056.B34B63A4116@sparrow.telecommunity.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>	<5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>	<79990c6b0907150859h6d7ad65g67e179c31aaa81f9@mail.gmail.com>
	<20090715163056.B34B63A4116@sparrow.telecommunity.com>
Message-ID: <4A5E1637.30109@plope.com>

I've been trying to follow this discussion now for weeks. The signal to noise 
ratio is pretty low.

I'd love to have an stdlib solution for distribution packaging and installation. 
  But I think we might as well pack it up and go home if the folks whom are 
contributing to the discussion "recreationally" (whom are not themselves 
implementers and potential implementers or spec writers or potential spec 
writers of packaging systems) continue to chime in on *every single issue*, 
contributing only stop energy.  It's just completely pointless.

- C


On 7/15/09 12:34 PM, P.J. Eby wrote:
> At 04:59 PM 7/15/2009 +0100, Paul Moore wrote:
>> - Virtualenv isn't a workaround (I don't know virtualenv, I'll take
>> your word for it)
>
> It's not one for system package maintainers because it would effectively
> be managing multiple instances of 'python'. Really not a suitable solution.
>
>
>> - I do not believe that it's clear that sanctioning the setuptools
>> workaround as the "right" approach by building it into the Python
>> core/stdlib is the right thing to do.
>
> I still don't understand how we're doing that.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/lists%40plope.com
>


From mihamina at gulfsat.mg  Wed Jul 15 19:56:44 2009
From: mihamina at gulfsat.mg (Rakotomandimby Mihamina)
Date: Wed, 15 Jul 2009 20:56:44 +0300
Subject: [Distutils] debian packaging
Message-ID: <4A5E185C.2010005@gulfsat.mg>

Hi all.
As you probably know:
http://www.mail-archive.com/debian-python at lists.debian.org/msg05456.html

I would like to unofficially package Plone 3.3+ for Debian.
Unofficially, because I would like to package from the buildout/egg.
That way, it will never comply with the Debian policy.

Good idea? Bad idea?
Will some help?...

From cournape at gmail.com  Wed Jul 15 17:22:03 2009
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 16 Jul 2009 00:22:03 +0900
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
Message-ID: <5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>

On Wed, Jul 15, 2009 at 11:00 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore<p.f.moore at gmail.com> wrote:
>>
>> Disclaimer: I've only read the short version, so if some of this is
>> covered in the longer explanation, I apologise now.
>
> Next time I won't put a short version ;)
>
>
>>
>> PEP 376 support has added a requirement for 3 additional methods to
>> the existing 1 finder method in PEP 302. That's already a 300%
>> increase in complexity. I'm against adding any further complexity to
>> PEP 302 - in all honesty, I'd rather move towards PEP 376 defining its
>> *own* locator protocol and avoid any extra burden on PEP 302. I'm not
>> sure implementers of PEP 302 importers will even provide the current
>> PEP 376 extensions.
>>
>> I propose that before the current prototype is turned into a final
>> (spec and) implementation, the PEP 302 extensions are extracted and
>> documented as an independent protocol, purely part of PEP 376. (This
>> *helps* implementers, as they can write support for, for example,
>> eggs, without needing to modify the existing egg importer). I'll
>> volunteer to do that work - but I won't start until the latest
>> iteration of questions and discussions has settled down and PEP 376
>> has achieved a stable form with the known issues addressed.
>
> Sure that makes sense. I am all for having these 302 extensions
> flipped on PEP 376
> side, then think about the "locator" protocol.
>
> I am lagging a bit in the discussions, I have 10 messages left to read or so,
> but the known issues I've listed so far are about the RECORD file and
> absolute paths,
> I am waiting for PJE example on the syntax he proposed for prefixes,
> on the docutils example.
>
>> Of course, this is moving more and more towards saying that the design
>> of setuptools, with its generic means for locating distributions, etc
>> etc, is the right approach.
>> We're reinventing the wheel here. But the
>> problem is that too many people dislike setuptools as it stands for it
>> to gain support.
>
> I don't think it's about setuptools design. I think it's more likely
> to be about the fact
> that there's no way in Python to install two different versions of the
> same distribution
> without "hiding" one from each other, using setuptools, virtualenv or
> zc.buildout.
>
> "installing" a distribution in Python means that its activated
> globally, whereas people
> need it locally at the application level.
>
>> My understanding is that the current set of PEPs were
>> intended to be a stripped down, more generally acceptable subset of
>> setuptools. Let's keep them that way (and omit the complexities of
>> multi-version support).
>>
>> If you want setuptools, you know where to get it...
>
> Sure, but let's not forget that the multiple-version issue is a global
> issue OS packagers
> also meet. (setuptools is not the problem) :
>
> - application Foo uses docutils 0.4 and doesn't work with docutils 0.5
> - application Bar uses docutils 0.5
>
> if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
> shipped with it.

As was stated by Debian packagers on the distutils ML, the problem is
that docutils 0.5 breaks packages which work with docutils 0.4 in the
first place.

http://www.mail-archive.com/distutils-sig at python.org/msg05775.html

And current hacks to work around lack of explicit version handling for
module import is a maintenance burden:

http://www.mail-archive.com/distutils-sig at python.org/msg05742.html

setuptools has given the incentive to use versioning as a workaround
for API/ABI compatibility. That's the core problem, and most problems
brought by setuptools (sys.path and .pth hacks with the unreliability
which ensued) are consequences of this. I don't see how virtualenv
solves anything in that regard for deployment issues. I doubt using
things like virtualenv will make OS packagers happy.

David

From rdmurray at bitdance.com  Wed Jul 15 18:49:57 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 15 Jul 2009 12:49:57 -0400 (EDT)
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<4A5DACC2.5030609@voidspace.org.uk>
	<94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>
	<79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0907151235210.6306@kimball.webabinitio.net>

On Wed, 15 Jul 2009 at 16:14, Paul Moore wrote:
> Bluntly, as Python stands, import and sys.path do not offer any core
> support for multiple versions. Custom solutions can be built on top of
> that - that's what setuptools does. But they are precisely that -
> custom solutions, and should be supported as such, outside the core
> (and stdlib).
>
> If standard Python support for multi-version imports is required (it's
> not by me, but I accept that some people want it), then it should be
> designed in thoughout:

Isn't this problem directly analogous to the '.so version' (*) problem?
Can we learn anything from the solution to that problem?  Does not the
fact that a (standard) solution to that problem was required indicate
that a similar solution needs to be provided by core Python?  (And yes,
it's out of scope for PEP 376).

--David

(*) or, for our Windows users, DLL Hell and the Side By Side Component
Sharing solution...

From floris.bruynooghe at gmail.com  Wed Jul 15 22:07:23 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 15 Jul 2009 21:07:23 +0100
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <h3l4fk$3fe$1@ger.gmane.org>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<4A5DACC2.5030609@voidspace.org.uk>
	<94bdd2610907150703i7af22a1eq28e0617c6abd735f@mail.gmail.com>
	<79990c6b0907150814r293abb92k7aa15ba0a70a7931@mail.gmail.com>
	<h3l4fk$3fe$1@ger.gmane.org>
Message-ID: <20090715200723.GA15261@laurie.devork>

On Wed, Jul 15, 2009 at 01:43:19PM -0400, Terry Reedy wrote:
> Paul Moore wrote:
>
>
>> - how do I import version 0.7.1 of package foo, rather than 0.7.2?
>
> Augment import to recognize versioned names?
>
> import foo_0_7_1

If people just renamed their modules/packages when they made API
incompatible changes we woudn't be having these problems.  But it
seems they are reluctant to do so.  C has a quite nice solution for
all of this but it is quite hard to map onto Python.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From p.f.moore at gmail.com  Thu Jul 16 00:27:00 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 15 Jul 2009 23:27:00 +0100
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of view
In-Reply-To: <4A5E1637.30109@plope.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
	<5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>
	<79990c6b0907150859h6d7ad65g67e179c31aaa81f9@mail.gmail.com>
	<20090715163056.B34B63A4116@sparrow.telecommunity.com>
	<4A5E1637.30109@plope.com>
Message-ID: <79990c6b0907151527k1d8b8889j9adc7f4b1edc4e57@mail.gmail.com>

2009/7/15 Chris McDonough <chrism at plope.com>:
> I've been trying to follow this discussion now for weeks. The signal to
> noise ratio is pretty low.

I agree :-(

> I'd love to have an stdlib solution for distribution packaging and
> installation. ?But I think we might as well pack it up and go home if the
> folks whom are contributing to the discussion "recreationally" (whom are not
> themselves implementers and potential implementers or spec writers or
> potential spec writers of packaging systems) continue to chime in on *every
> single issue*, contributing only stop energy. ?It's just completely
> pointless.

I thought that as someone who is writing code for Tarek's PEP 376
prototype implementation, I counted as offering useful input. Thinking
further on what I've said, I'm no longer sure that's true.

I do think that at *some* point, the feedback from the non-packagers,
negative or irrelevant though it might be, needs to be requested and
considered. Maybe now isn't the right time, but it needs to be done at
some point.

Until then, I'll try to avoid adding to the noise.

Paul.

From david.lyon at preisshare.net  Thu Jul 16 01:39:40 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 15 Jul 2009 19:39:40 -0400
Subject: [Distutils] PEP 376 - from pythonpkgmgr point of view
In-Reply-To: <4A5E1637.30109@plope.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>	<5b8d13220907150822lee247csfd12e1a204f37931@mail.gmail.com>	<79990c6b0907150859h6d7ad65g67e179c31aaa81f9@mail.gmail.com>
	<20090715163056.B34B63A4116@sparrow.telecommunity.com>
	<4A5E1637.30109@plope.com>
Message-ID: <7cc3a3a3ff2f5a17c81060e6155c88c2@preisshare.net>

On Wed, 15 Jul 2009 13:47:35 -0400, Chris McDonough <chrism at plope.com>
wrote:
> I've been trying to follow this discussion now for weeks. The signal to
> noise ratio is pretty low.

I'm -1 on that..

As a relative newcomer to python packaging I'm finding all these
discussions very informative. :-)

> I'd love to have an stdlib solution for distribution packaging and
> installation.

That's right.

I'd love to find out what the process is for submitting my pythonpkgmgr
project for consideration into the stdlib.

As it fills a huge gap that you've just identified that currently exists 
within the python that is being shipped today. That is, allowing users to 
easily install packages from pypi.

>   But I think we might as well pack it up and go home if the folks whom
are
> contributing to the discussion "recreationally" (whom are not themselves 
> implementers and potential implementers or spec writers or potential spec

> writers of packaging systems) continue to chime in on *every single
issue*,
> 
> contributing only stop energy.  It's just completely pointless.

We can all work in different ways..

I'm not writing PEPS and don't care too much about how the internals of
a package work. As long as there are APIs for such stuff I'm happy.

What I'm working on is to try to improve the user experience which
isn't so handled so easily by a design by commitee process. 

Packaging and Distutils, need to be looked at wholistically as
well. It's not just about the api's, but how well they work.

It's not noise.... it's just the process....

ps:

(http://peak.telecommunity.com/DevCenter/EasyInstall)

"Easy Install
...
Please share your experiences with us! If you encounter difficulty
installing a package, please contact us via the distutils mailing list.
(Note: please DO NOT send private email directly to the author of
setuptools; it will be discarded. "

So what are we to do if we find issues with setuptools other than to post
to distutils?

David



From ziade.tarek at gmail.com  Thu Jul 16 02:13:41 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 16 Jul 2009 02:13:41 +0200
Subject: [Distutils] Announcing the 'Distribute' project
Message-ID: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>

Hello,

We have started a new project called 'Distribute'. It's a fork of
setuptools and its initial purpose will be to tackle
the most annoying bugs found in setuptools 0.6c9 version.

A first version will be released as soon as possible (probably next
monday) and a document will explain how to migrate
from setuptools. This should be fairly easy.

The next step of the project will be some cleanup and a split in two
distinct distributions:

- one that contains only pkg_resources
- one with the setuptools package.

The project is here : http://bitbucket.org/tarek/setuptoolsbranch

We have an issue tracker there where you can add feature requests and bugs.

Since its a DVCS repo, anyone is welcome to contribute patches.

Regards

Hanno, Chris, Tarek, and some other folks...

From ziade.tarek at gmail.com  Thu Jul 16 02:43:50 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 16 Jul 2009 02:43:50 +0200
Subject: [Distutils] PEP 376 - from PyPM's point of view
In-Reply-To: <op.uw4dx7ttbrrvlq@double>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<op.uw4dx7ttbrrvlq@double>
Message-ID: <94bdd2610907151743m619f91b9n9cc1dc31a86d2729@mail.gmail.com>

2009/7/15 Sridhar Ratnakumar <SridharR at activestate.com>:
> On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>
>>>> get_installed_files(local=False) -> iterator of (path, md5, size)
>>>
>>> Will this also return the directories /created/ during the installation?
>>> For example, will it also contain the entry "docutils" .. along with
>>> "docutils/__init__.py"?
>>
>> I don't think it's necessary to add "docutils" if
>> "docutils/__init__.py" is present
>>
>> But for empty directories added during installation we should add the I
>> guess.
>>
>> So, I'll add a note.
>
> It seems that you overlooked the below paragraph.
>
>>> If not, how is the installer (pip, pypm, etc..) supposed to know which
>>> directories to remove (docutils/) and which directories not to remove
>>> (site-packages/, bin/, etc..)?
>
> Quoting from the PEP:
>
> [quote]'(...)uninstall uses the APIs described earlier and remove all unique
> files, as long as their hash didn't change. Then it removes empty
> directories left behind.'[endquote]
>
> Let's assume that site-packages/ contained only one package 'Foo'. Will
> uninstall('Foo') remove the site-packages/ directory just because it turned
> out to be empty after removing 'Foo'? To explain, let's assume the RECORD of
> 'Foo' contains:
>
> $ cat RECORD
> Foo/__init__.py
> Foo/bar/__init__.py
> Foo/bar/test.py
>
> and according to what you wrote in the PEP ("it removes empty directories
> left behind"):
>
> $ python -m distutils.util.uninstall Foo
> rm /.../site-packages/Foo/__init__.py
> rm /.../site-packages/Foo/bar/__init__.py
> rm /.../site-packages/Foo/bar/test.py
> rm empty dir /.../site-packages/Foo/bar
> rm empty dir /.../site-packages/Foo/
> rm empty dir /.../site-packages/ ? ? ? ?# !!!!!
>
> it also remove the site-packages directory!
>
> Then there is ~/python26/bin, ~/python26/include, ~/python26/etc, etc.. Do
> you see my point?

I didn't mean that of course. While we can avoid your example for the
code, by removing only
packages that are fully emptied, and are alongside the egg-info directory,
we might not be able to do it properly for the data.

So let's add the directories as well

From SridharR at activestate.com  Thu Jul 16 01:33:27 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Wed, 15 Jul 2009 16:33:27 -0700
Subject: [Distutils] dependency graph of all packages in pypi
Message-ID: <op.uw4ud1f5brrvlq@double>

The following file gives the list of all packages in PyPI and their  
'install_requires' (or 'requires').

   http://files.getdropbox.com/u/87045/x/pypi-dependency.txt

This list does not include (most of the) packages that have external  
downloads.

-srid

From jdmain at comcast.net  Thu Jul 16 03:33:05 2009
From: jdmain at comcast.net (J.D. Main)
Date: Wed, 15 Jul 2009 19:33:05 -0600
Subject: [Distutils] py2exe - COM Server DLL can't be referenced by VB6
	or VS2003
In-Reply-To: <4A5AF7D4.18308.D3F2915@jdmain.comcast.net>
References: <4A5AF7D4.18308.D3F2915@jdmain.comcast.net>
Message-ID: <4A5E2EF1.11028.19CE7422@jdmain.comcast.net>

Hey Guys,

I guess nobody knows or cares.  Where do the Win32 python guys hang 
out?

J.D.

From sridharr at activestate.com  Thu Jul 16 05:31:09 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 15 Jul 2009 20:31:09 -0700
Subject: [Distutils] Not installing the install_requires
In-Reply-To: <20090715154218.97F943A411C@sparrow.telecommunity.com>
References: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
	<3d56057b-f8cd-40b0-9ae9-997b201e6d13@h18g2000yqj.googlegroups.com>
	<20090715154218.97F943A411C@sparrow.telecommunity.com>
Message-ID: <op.uw45d7pu1q4jlt@whymac>

 From my experience in building all the pypi packages, I can confirm that a  
significant number of packages (> 10 at least), fail to build[1] because  
it cannot read a file (usually LICENSE.txt, version.txt, README.txt in the  
sdist root) using __file__.

It is unfortunate that we have this mess.

-srid

[1] "python setup.py install --root=installdir/" run using subprocess

On Wed, 15 Jul 2009 08:45:21 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> At 07:43 AM 7/15/2009 -0700, Peter Bengtsson wrote:
>> Crap!
>> That didn't work either!
>> IOError: [Errno 20] Not a directory: '/home/peterbe/virtualenvs/
>> djangopeoplenet/lib/python2.5/site-packages/premailer-1.2-py2.5.egg/
>> premailer/version.txt'
>>
>> This must be because of some egg magic that I don't understand.
>> What I did was this (in premailer.py):
>>
>> __version__ = open(os.path.join(os.path.dirname(__file__),
>> 'version.txt')
>>                    ).read().strip()
>
>
> from pkg_resources import resource_string
> __version__ = resource_string(__name__, 'version.txt').strip()
>
> Make sure that you either list 'version.txt' in your setup() data_files  
> or else use include_package_data=True and a revision control system that  
> includes the version.txt file, or else the version.txt won't be included  
> in your sdists and eggs.
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig



From mail at timgolden.me.uk  Thu Jul 16 09:51:15 2009
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 16 Jul 2009 08:51:15 +0100
Subject: [Distutils] py2exe - COM Server DLL can't be referenced by VB6
 or VS2003
In-Reply-To: <4A5E2EF1.11028.19CE7422@jdmain.comcast.net>
References: <4A5AF7D4.18308.D3F2915@jdmain.comcast.net>
	<4A5E2EF1.11028.19CE7422@jdmain.comcast.net>
Message-ID: <4A5EDBF3.2060104@timgolden.me.uk>

J.D. Main wrote:
> Hey Guys,
> 
> I guess nobody knows or cares.  Where do the Win32 python guys hang 
> out?


Try the python-win32 list:

http://mail.python.org/mailman/listinfo/python-win32

TJG

From p.f.moore at gmail.com  Thu Jul 16 10:40:24 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 16 Jul 2009 09:40:24 +0100
Subject: [Distutils] Not installing the install_requires
In-Reply-To: <op.uw45d7pu1q4jlt@whymac>
References: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
	<3d56057b-f8cd-40b0-9ae9-997b201e6d13@h18g2000yqj.googlegroups.com>
	<20090715154218.97F943A411C@sparrow.telecommunity.com>
	<op.uw45d7pu1q4jlt@whymac>
Message-ID: <79990c6b0907160140k7532aca6p623fe9addb849fbb@mail.gmail.com>

2009/7/16 Sridhar Ratnakumar <sridharr at activestate.com>:
> From my experience in building all the pypi packages, I can confirm that a
> significant number of packages (> 10 at least), fail to build[1] because it
> cannot read a file (usually LICENSE.txt, version.txt, README.txt in the
> sdist root) using __file__.
>
> It is unfortunate that we have this mess.

PEP 302 and imports from zip files have been round since Python 2.3.
Unfortunately, very few people write their packages with the idea that
they may not be loaded from the filesystem in mind. As a result, we
have things like the "not zip safe" flag in setuptools.

I wish this didn't happen, but I don't know how to stop it. Partially,
it may be because the support for getting data resources in PEP 302 is
minimal, but equally the support is minimal because no-one has
proposed adding anything extra, and that's because no-one tries to use
it, and...

Even setuptools/pkg_resources hasn't encouraged people to fix stuff
like this :-(

Paul.

PS If someone were to propose some extra PEP 302 features, I'd be
happy to help get them added and support incorporated into the stdlib.

From regebro at gmail.com  Thu Jul 16 11:24:10 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 16 Jul 2009 11:24:10 +0200
Subject: [Distutils] Announcing the 'Distribute' project
Message-ID: <319e029f0907160224x2a6e0282i7ae0f95bb6072965@mail.gmail.com>

Tarek Ziad?:
> We have started a new project called 'Distribute'.

OK, I will retire my Python 3 branch, and make a branch here instead,
within a week. Maybe during the weekend, although I'm fairly busy at
the moment.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Thu Jul 16 11:27:34 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 16 Jul 2009 11:27:34 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <319e029f0907160224x2a6e0282i7ae0f95bb6072965@mail.gmail.com>
References: <319e029f0907160224x2a6e0282i7ae0f95bb6072965@mail.gmail.com>
Message-ID: <94bdd2610907160227jefe79edi25a441b50897a3fc@mail.gmail.com>

On Thu, Jul 16, 2009 at 11:24 AM, Lennart Regebro<regebro at gmail.com> wrote:
> Tarek Ziad?:
>> We have started a new project called 'Distribute'.
>
> OK, I will retire my Python 3 branch, and make a branch here instead,
> within a week. Maybe during the weekend, although I'm fairly busy at
> the moment.

Give me your bitbucket account, I'll add you as a commiter so you can
branch directly so you don't have to fork.

That'll save some merge work in the future,



>
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
> _______________________________________________
> 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  Thu Jul 16 11:28:52 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 16 Jul 2009 11:28:52 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
Message-ID: <94bdd2610907160228x41046306r8a0d84ccd6219289@mail.gmail.com>

On Thu, Jul 16, 2009 at 2:13 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
>
> The project is here : http://bitbucket.org/tarek/setuptoolsbranch

We've just moved it here with a clean svn history imported :
http://bitbucket.org/tarek/distribute/

From hanno at hannosch.eu  Thu Jul 16 11:43:07 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Thu, 16 Jul 2009 11:43:07 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
Message-ID: <5cae42b20907160243s7927cfb1s216f0dbd7fe660b3@mail.gmail.com>

Hi.

On Thu, Jul 16, 2009 at 2:13 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> We have started a new project called 'Distribute'. It's a fork of
> setuptools and its initial purpose will be to tackle
> the most annoying bugs found in setuptools 0.6c9 version.

I have fixed the Subversion 1.6 incompatibility as a first bug in the
"most annoying" category. See
http://bitbucket.org/tarek/distribute/issue/1/ for the bug report.

The excellent refactoring found in the original issue in the
setuptools bug tracker isn't applied yet. I'll do that including the
more thorough testing required for the larger change after we have
released our first 0.6 final release.

I'll go through the setuptools tracker to see if there are more very
simple bug fixes than can be made. If you know of a particular typo,
SyntaxError or any other non-controversial two-line change, feel free
to point me to them.

Hanno

From david.lyon at preisshare.net  Thu Jul 16 11:39:25 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 16 Jul 2009 05:39:25 -0400
Subject: [Distutils] setuptools not able to install package as regular user
 under linux because of internal crash
In-Reply-To: <op.uw45d7pu1q4jlt@whymac>
References: <20090715131645.2543.1042026702.divmod.quotient.2640@henry.divmod.com>
	<3d56057b-f8cd-40b0-9ae9-997b201e6d13@h18g2000yqj.googlegroups.com>
	<20090715154218.97F943A411C@sparrow.telecommunity.com>
	<op.uw45d7pu1q4jlt@whymac>
Message-ID: <6c23109ae1869d6cef0e74955f0301c5@preisshare.net>


Hi, 

I'm testing pythonpkgmgr under linux now. I'm really keen to allow users
to have a way to install packages in /usr/local/lib without having super
user
access (it's a hassle typing in a password every time). 

I feel that if they want to install into /usr/lib/pythonX.X/site-packages
then it's fair enough that they have a su password.

Anyway..

If I just use "easy_install html5lib" and not "sudo easy_install html5lib"
and 
then I get the following error:

--------------------------------------------------------------------------------
Running installer ... /usr/bin/easy_install "/media/Elements/Pythn
Packages/html5lib-0.10.zip"
ERRORS: Traceback (most recent call last):
  File "/usr/bin/easy_install", line 5, in <module>
    from pkg_resources import load_entry_point
ImportError: No module named pkg_resources
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/apport_python_hook.py", line 78,
in apport_excepthook
    report_file = open(pr_filename, 'wt')
IOError: [Errno 13] Permission denied:
'/var/crash/_usr_bin_easy_install.1000.crash'

Original exception was:
Traceback (most recent call last):
  File "/usr/bin/easy_install", line 5, in <module>
    from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

--------------------------------------------------------------------------------

If I run with sudo...

------------------------------------------------------------------
Running installer ... sudo /usr/bin/easy_install "/media/Elements/Pythn
Packages/html5lib-0.10.zip"
Processing html5lib-0.10.zip
Running html5lib-0.10/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-sV7fV2/html5lib-0.10/egg-dist-tmp-AT346T
zip_safe flag not set; analyzing archive contents...
Adding html5lib 0.10 to easy-install.pth file

Installed /usr/lib/python2.5/site-packages/html5lib-0.10-py2.5.egg
Processing dependencies for html5lib==0.10
Finished processing dependencies for html5lib==0.10

------------------------------------------------------------------

Here's the log for installing setuptools..

dlyon at MiniQ-ubunto-8:/media/Elements/Pythn Packages/setuptools-0.6c9$ sudo
python setup.py install
[sudo] password for dlyon: 
running install
running bdist_egg
running egg_info
writing setuptools.egg-info/PKG-INFO
writing top-level names to setuptools.egg-info/top_level.txt
writing dependency_links to setuptools.egg-info/dependency_links.txt
writing entry points to setuptools.egg-info/entry_points.txt
reading manifest file 'setuptools.egg-info/SOURCES.txt'
writing manifest file 'setuptools.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-i686/egg
running install_lib
running build_py
creating build
creating build/lib
copying pkg_resources.py -> build/lib
copying easy_install.py -> build/lib
copying site.py -> build/lib
creating build/lib/setuptools
copying setuptools/extension.py -> build/lib/setuptools
copying setuptools/sandbox.py -> build/lib/setuptools
copying setuptools/depends.py -> build/lib/setuptools
copying setuptools/__init__.py -> build/lib/setuptools
copying setuptools/archive_util.py -> build/lib/setuptools
copying setuptools/dist.py -> build/lib/setuptools
copying setuptools/package_index.py -> build/lib/setuptools
creating build/lib/setuptools/tests
copying setuptools/tests/test_resources.py -> build/lib/setuptools/tests
copying setuptools/tests/__init__.py -> build/lib/setuptools/tests
copying setuptools/tests/test_packageindex.py -> build/lib/setuptools/tests
copying setuptools/tests/doctest.py -> build/lib/setuptools/tests
creating build/lib/setuptools/command
copying setuptools/command/build_ext.py -> build/lib/setuptools/command
copying setuptools/command/upload.py -> build/lib/setuptools/command
copying setuptools/command/bdist_wininst.py -> build/lib/setuptools/command
copying setuptools/command/egg_info.py -> build/lib/setuptools/command
copying setuptools/command/__init__.py -> build/lib/setuptools/command
copying setuptools/command/setopt.py -> build/lib/setuptools/command
copying setuptools/command/install_egg_info.py ->
build/lib/setuptools/command
copying setuptools/command/bdist_egg.py -> build/lib/setuptools/command
copying setuptools/command/install.py -> build/lib/setuptools/command
copying setuptools/command/bdist_rpm.py -> build/lib/setuptools/command
copying setuptools/command/install_lib.py -> build/lib/setuptools/command
copying setuptools/command/saveopts.py -> build/lib/setuptools/command
copying setuptools/command/develop.py -> build/lib/setuptools/command
copying setuptools/command/easy_install.py -> build/lib/setuptools/command
copying setuptools/command/build_py.py -> build/lib/setuptools/command
copying setuptools/command/install_scripts.py ->
build/lib/setuptools/command
copying setuptools/command/sdist.py -> build/lib/setuptools/command
copying setuptools/command/rotate.py -> build/lib/setuptools/command
copying setuptools/command/alias.py -> build/lib/setuptools/command
copying setuptools/command/register.py -> build/lib/setuptools/command
copying setuptools/command/test.py -> build/lib/setuptools/command
copying setuptools/cli.exe -> build/lib/setuptools
copying setuptools/gui.exe -> build/lib/setuptools
creating build/bdist.linux-i686
creating build/bdist.linux-i686/egg
copying build/lib/pkg_resources.py -> build/bdist.linux-i686/egg
copying build/lib/easy_install.py -> build/bdist.linux-i686/egg
copying build/lib/site.py -> build/bdist.linux-i686/egg
creating build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/extension.py ->
build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/sandbox.py ->
build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/depends.py ->
build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/__init__.py ->
build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/archive_util.py ->
build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/dist.py ->
build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/package_index.py ->
build/bdist.linux-i686/egg/setuptools
creating build/bdist.linux-i686/egg/setuptools/tests
copying build/lib/setuptools/tests/test_resources.py ->
build/bdist.linux-i686/egg/setuptools/tests
copying build/lib/setuptools/tests/__init__.py ->
build/bdist.linux-i686/egg/setuptools/tests
copying build/lib/setuptools/tests/test_packageindex.py ->
build/bdist.linux-i686/egg/setuptools/tests
copying build/lib/setuptools/tests/doctest.py ->
build/bdist.linux-i686/egg/setuptools/tests
creating build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/build_ext.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/upload.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/bdist_wininst.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/egg_info.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/__init__.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/setopt.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/install_egg_info.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/bdist_egg.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/install.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/bdist_rpm.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/install_lib.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/saveopts.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/develop.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/easy_install.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/build_py.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/install_scripts.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/sdist.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/rotate.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/alias.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/register.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/command/test.py ->
build/bdist.linux-i686/egg/setuptools/command
copying build/lib/setuptools/cli.exe ->
build/bdist.linux-i686/egg/setuptools
copying build/lib/setuptools/gui.exe ->
build/bdist.linux-i686/egg/setuptools
byte-compiling build/bdist.linux-i686/egg/pkg_resources.py to
pkg_resources.pyc
byte-compiling build/bdist.linux-i686/egg/easy_install.py to
easy_install.pyc
byte-compiling build/bdist.linux-i686/egg/site.py to site.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/extension.py to
extension.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/sandbox.py to
sandbox.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/depends.py to
depends.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/__init__.py to
__init__.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/archive_util.py to
archive_util.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/dist.py to dist.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/package_index.py to
package_index.pyc
byte-compiling
build/bdist.linux-i686/egg/setuptools/tests/test_resources.py to
test_resources.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/tests/__init__.py to
__init__.pyc
byte-compiling
build/bdist.linux-i686/egg/setuptools/tests/test_packageindex.py to
test_packageindex.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/tests/doctest.py to
doctest.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/build_ext.py
to build_ext.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/upload.py to
upload.pyc
byte-compiling
build/bdist.linux-i686/egg/setuptools/command/bdist_wininst.py to
bdist_wininst.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/egg_info.py to
egg_info.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/__init__.py to
__init__.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/setopt.py to
setopt.pyc
byte-compiling
build/bdist.linux-i686/egg/setuptools/command/install_egg_info.py to
install_egg_info.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/bdist_egg.py
to bdist_egg.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/install.py to
install.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/bdist_rpm.py
to bdist_rpm.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/install_lib.py
to install_lib.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/saveopts.py to
saveopts.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/develop.py to
develop.pyc
byte-compiling
build/bdist.linux-i686/egg/setuptools/command/easy_install.py to
easy_install.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/build_py.py to
build_py.pyc
byte-compiling
build/bdist.linux-i686/egg/setuptools/command/install_scripts.py to
install_scripts.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/sdist.py to
sdist.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/rotate.py to
rotate.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/alias.py to
alias.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/register.py to
register.pyc
byte-compiling build/bdist.linux-i686/egg/setuptools/command/test.py to
test.pyc
creating build/bdist.linux-i686/egg/EGG-INFO
copying setuptools.egg-info/PKG-INFO -> build/bdist.linux-i686/egg/EGG-INFO
copying setuptools.egg-info/SOURCES.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying setuptools.egg-info/dependency_links.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying setuptools.egg-info/entry_points.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying setuptools.egg-info/top_level.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying setuptools.egg-info/zip-safe -> build/bdist.linux-i686/egg/EGG-INFO
creating dist
creating 'dist/setuptools-0.6c9-py2.5.egg' and adding
'build/bdist.linux-i686/egg' to it
removing 'build/bdist.linux-i686/egg' (and everything under it)
Processing setuptools-0.6c9-py2.5.egg
Copying setuptools-0.6c9-py2.5.egg to /usr/lib/python2.5/site-packages
Adding setuptools 0.6c9 to easy-install.pth file
Installing easy_install script to /usr/bin
Installing easy_install-2.5 script to /usr/bin

Installed /usr/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg
Processing dependencies for setuptools==0.6c9
Finished processing dependencies for setuptools==0.6c9



From ziade.tarek at gmail.com  Thu Jul 16 11:51:43 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 16 Jul 2009 11:51:43 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <5cae42b20907160243s7927cfb1s216f0dbd7fe660b3@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<5cae42b20907160243s7927cfb1s216f0dbd7fe660b3@mail.gmail.com>
Message-ID: <94bdd2610907160251x7145bddagcfdec27451979d17@mail.gmail.com>

On Thu, Jul 16, 2009 at 11:43 AM, Hanno Schlichting<hanno at hannosch.eu> wrote:
> Hi.
>
> On Thu, Jul 16, 2009 at 2:13 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
>> We have started a new project called 'Distribute'. It's a fork of
>> setuptools and its initial purpose will be to tackle
>> the most annoying bugs found in setuptools 0.6c9 version.
>
> I have fixed the Subversion 1.6 incompatibility as a first bug in the
> "most annoying" category. See
> http://bitbucket.org/tarek/distribute/issue/1/ for the bug report.

Great,

I've applied the one that makes it work under Python trunk again.

Cheers
Tarek

From david.lyon at preisshare.net  Thu Jul 16 13:42:29 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 16 Jul 2009 07:42:29 -0400
Subject: [Distutils] =?utf-8?q?setuptools_bug=3A_pkg=5Fresources_doesn=27t?=
 =?utf-8?q?_report_packages_installed_in_user_site-packages_python_2=2E6_w?=
 =?utf-8?q?indows?=
In-Reply-To: <94bdd2610907160228x41046306r8a0d84ccd6219289@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907160228x41046306r8a0d84ccd6219289@mail.gmail.com>
Message-ID: <d7d35a2ab4bec82a3a35c98eb74df72b@preisshare.net>


Under Windows XP, Python 2.6, I can install a package into my user
site-packages

ie  C:\Documents and Settings\David\Application
Data\Python\Python26\site-packages

No problem at all...

But then when I retrieve a package list...

The new packages don't get displayed in the workingset.

I can browse the directories and the files are there. I can
go into idle and import them. So they appear to be in working
order. But I just can't see them.

Any ideas?

is this supposed to be supported? or does some custom
code need to be written?

David


From him at online.de  Thu Jul 16 14:26:00 2009
From: him at online.de (=?ISO-8859-1?Q?Joachim_K=F6nig?=)
Date: Thu, 16 Jul 2009 14:26:00 +0200
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <20090715162736.B54D33A4116@sparrow.telecommunity.com>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>
	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>
	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>
	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>
	<4A5DF2D9.6050403@online.de>
	<20090715162736.B54D33A4116@sparrow.telecommunity.com>
Message-ID: <4A5F1C58.3030003@online.de>

P.J. Eby wrote:
> At 05:16 PM 7/15/2009 +0200, Joachim K?nig wrote:
>> f you have m different versions of n packages then
>> you could have n**m different combinations for an application so you 
>> need a
>> possiblilty to select one combination from n**m possible ones at 
>> application
>> startup time. Is this really worth it?
>
> Obviously yes, as neither buildout nor setuptools would exist 
> otherwise.  ;-)
> Nor would Fedora be packaging certain library versions as eggs 
> specifically to get certain multi-version scenarios to work.
>
> The specific solutions for handling n*m problems aren't fantastic, but 
> they are clearly needed.
I still do not see the need.

IMO the whole obfuscation comes from fact that all versions of all 
packages are installed into
one location where python automaticallly looks for packages and then 
with a lot of magic the
packages are hidden from the interpreter and only specific requested 
versions are made "visible"
to the interpreter at runtime.

Why do the package have to be installed there at the first place?

For an application it would be enough to have an additional directory on 
its PYTHONPATH where
the packages required for this application would be installed. So a 
package could be installed either
to the common directory ("site-packages") or an application specific 
directory (e.g. something like
"app-packages/<appname>/"). This approach has been used by Zope2 with 
its "private" lib/python
directory for years.

So one would have to set up the application specific packages before 
running the application, but the
whole clutter of uncounted versions of the same package in one directory 
could go away. The
"drawback" of this approach would be, that the same version of a package 
would have to be installed
multiple times if needed by different applications.





From chris at simplistix.co.uk  Thu Jul 16 16:20:35 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 16 Jul 2009 15:20:35 +0100
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
Message-ID: <4A5F3733.8050604@simplistix.co.uk>

Tarek Ziad? wrote:
> We have started a new project called 'Distribute'. It's a fork of
> setuptools and its initial purpose will be to tackle
> the most annoying bugs found in setuptools 0.6c9 version.

Just to make these comments publicly too:

*Please* consider a different name.
"distribute" just seems wrong as this project doesn't actually do any 
distributing. PyPI and other package indexes do the distributing, 
setuptools does installation and setup.

My own preference would be "setuptools2" with the first release being 
version number 2.0. This makes it very clear what the package is, solves 
the PyPI problem and involves less changes in things like buildout 
(well, a few characters anyway ;-) )

Also, what DVCS is being used? I hope it's Hg, otherwise it means 
another toolset to learn if I want to help out, which means me helping 
out would be less likely. (I hope you wouldn't see that as a good thing 
;-) )

cheers,

Chris

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

From barry at python.org  Thu Jul 16 16:29:27 2009
From: barry at python.org (Barry Warsaw)
Date: Thu, 16 Jul 2009 10:29:27 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <4A5F3733.8050604@simplistix.co.uk>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
Message-ID: <7A4B245E-F707-42AE-AD22-B8BE84159A15@python.org>

On Jul 16, 2009, at 10:20 AM, Chris Withers wrote:

> My own preference would be "setuptools2" with the first release  
> being version number 2.0. This makes it very clear what the package  
> is, solves the PyPI problem and involves less changes in things like  
> buildout (well, a few characters anyway ;-) )

Oh c'mon Chris, you know it /has/ to be named: setup2ls :)

<bikeshed>Seriously though: +1 for a different name</bikeshed>

> Also, what DVCS is being used? I hope it's Hg, otherwise it means  
> another toolset to learn if I want to help out, which means me  
> helping out would be less likely. (I hope you wouldn't see that as a  
> good thing ;-) )

One thing I'd like to see for this new project is more built-in  
support for the popular revision control systems.  I don't mind  
writing and maintaining the bzr part of that, but it's been a pain to  
have to distribute setuptools_bzr as a plugin. :(

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090716/1a5228f2/attachment.pgp>

From chris at simplistix.co.uk  Thu Jul 16 16:34:38 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 16 Jul 2009 15:34:38 +0100
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <7A4B245E-F707-42AE-AD22-B8BE84159A15@python.org>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<7A4B245E-F707-42AE-AD22-B8BE84159A15@python.org>
Message-ID: <4A5F3A7E.3040504@simplistix.co.uk>

Barry Warsaw wrote:
> On Jul 16, 2009, at 10:20 AM, Chris Withers wrote:
> 
>> My own preference would be "setuptools2" with the first release being 
>> version number 2.0. This makes it very clear what the package is, 
>> solves the PyPI problem and involves less changes in things like 
>> buildout (well, a few characters anyway ;-) )
> 
> Oh c'mon Chris, you know it /has/ to be named: setup2ls :)
> 
> <bikeshed>Seriously though: +1 for a different name</bikeshed>

Indeed, I don't mind what it is as long as it makes sense, which 
"distribute" doesn't...

Chris



From ktenney at gmail.com  Thu Jul 16 16:36:55 2009
From: ktenney at gmail.com (Kent Tenney)
Date: Thu, 16 Jul 2009 09:36:55 -0500
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <4A5F3733.8050604@simplistix.co.uk>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
Message-ID: <ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>

On Thu, Jul 16, 2009 at 9:20 AM, Chris Withers<chris at simplistix.co.uk> wrote:
> Tarek Ziad? wrote:
>>
>> We have started a new project called 'Distribute'. It's a fork of
>> setuptools and its initial purpose will be to tackle
>> the most annoying bugs found in setuptools 0.6c9 version.
>
> Just to make these comments publicly too:
>
> *Please* consider a different name.

Not to mention the PITA of Googling "distribute"

> "distribute" just seems wrong as this project doesn't actually do any
> distributing. PyPI and other package indexes do the distributing, setuptools
> does installation and setup.
>
> My own preference would be "setuptools2" with the first release being
> version number 2.0. This makes it very clear what the package is, solves the
> PyPI problem and involves less changes in things like buildout (well, a few
> characters anyway ;-) )
>
> Also, what DVCS is being used? I hope it's Hg, otherwise it means another
> toolset to learn if I want to help out, which means me helping out would be
> less likely. (I hope you wouldn't see that as a good thing ;-) )
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? - http://www.simplistix.co.uk
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From ziade.tarek at gmail.com  Thu Jul 16 16:49:41 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 16 Jul 2009 16:49:41 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
Message-ID: <94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>

On Thu, Jul 16, 2009 at 4:36 PM, Kent Tenney<ktenney at gmail.com> wrote:
> On Thu, Jul 16, 2009 at 9:20 AM, Chris Withers<chris at simplistix.co.uk> wrote:
>> Tarek Ziad? wrote:
>>>
>>> We have started a new project called 'Distribute'. It's a fork of
>>> setuptools and its initial purpose will be to tackle
>>> the most annoying bugs found in setuptools 0.6c9 version.
>>
>> Just to make these comments publicly too:
>>
>> *Please* consider a different name.
>
> Not to mention the PITA of Googling "distribute"

Ok so everyone agrees it's a bad name for many good reasons :)

I am changing to setuptools2 then.

For other remarks Chris made:

- which DVCS : Mercurial. I think it's the best pick for such a
project, if you come for Subversion you'll be up and running
  with Hg within an hour. There are many guides/tutorials out there.

  for instance : http://nedbatchelder.com/text/hgsvn.html

- for the mailing list, I'd like to stay on distutils-sig, unless many
people want a separate list for it, so I am 0-


Cheers
Tarek

From barry at python.org  Thu Jul 16 16:57:09 2009
From: barry at python.org (Barry Warsaw)
Date: Thu, 16 Jul 2009 10:57:09 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
Message-ID: <1C1F6B48-539B-4F62-8756-FA5E600B1E15@python.org>

On Jul 16, 2009, at 10:49 AM, Tarek Ziad? wrote:

> - for the mailing list, I'd like to stay on distutils-sig, unless many
> people want a separate list for it, so I am 0-

Please stay on distutils-sig.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090716/5b8c21fc/attachment.pgp>

From benji at zope.com  Thu Jul 16 17:02:23 2009
From: benji at zope.com (Benji York)
Date: Thu, 16 Jul 2009 11:02:23 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com> 
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com> 
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
Message-ID: <e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>

On Thu, Jul 16, 2009 at 10:49 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Thu, Jul 16, 2009 at 4:36 PM, Kent Tenney<ktenney at gmail.com> wrote:
>> On Thu, Jul 16, 2009 at 9:20 AM, Chris Withers<chris at simplistix.co.uk> wrote:
>>> Tarek Ziad? wrote:
>>>>
>>>> We have started a new project called 'Distribute'. It's a fork of
>>>> setuptools and its initial purpose will be to tackle
>>>> the most annoying bugs found in setuptools 0.6c9 version.
>>>
>>> Just to make these comments publicly too:
>>>
>>> *Please* consider a different name.
>>
>> Not to mention the PITA of Googling "distribute"
>
> Ok so everyone agrees it's a bad name for many good reasons :)
>
> I am changing to setuptools2 then.

I'll try to limit my bikesheading to this one message.

Given that this is -- I'm assuming -- an "unauthorized" fork, I wouldn't
use "setuptools2" as the name.

We don't want to confuse people, and "setuptools2" is confusingly
similar to "setuptools" (to borrow a phrase from trademark law).

The new project is based on setuptools but it is not a product of the
setuptools "project" so should have a distinct name.
-- 
Benji York
Senior Software Engineer
Zope Corporation

From p.f.moore at gmail.com  Thu Jul 16 17:08:54 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 16 Jul 2009 16:08:54 +0100
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
Message-ID: <79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>

2009/7/16 Benji York <benji at zope.com>:
>> Ok so everyone agrees it's a bad name for many good reasons :)
>>
>> I am changing to setuptools2 then.
>
> I'll try to limit my bikesheading to this one message.
>
> Given that this is -- I'm assuming -- an "unauthorized" fork, I wouldn't
> use "setuptools2" as the name.
>
> We don't want to confuse people, and "setuptools2" is confusingly
> similar to "setuptools" (to borrow a phrase from trademark law).
>
> The new project is based on setuptools but it is not a product of the
> setuptools "project" so should have a distinct name.

Agreed.

Also, I'd suggest that the fork work on splitting out the components
of setuptools - pkg_resources, the distutils extensions, easy_install
- so that they can be used independently. That may mean being prepared
to have a number of project names, rather than just one...

And now I'll refrain from bikeshedding further, too.

Paul.

From ziade.tarek at gmail.com  Thu Jul 16 17:18:16 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 16 Jul 2009 17:18:16 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
Message-ID: <94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>

2009/7/16 Paul Moore <p.f.moore at gmail.com>:
> 2009/7/16 Benji York <benji at zope.com>:
>>> Ok so everyone agrees it's a bad name for many good reasons :)
>>>
>>> I am changing to setuptools2 then.
>>
>> I'll try to limit my bikesheading to this one message.
>>
>> Given that this is -- I'm assuming -- an "unauthorized" fork, I wouldn't
>> use "setuptools2" as the name.
>>
>> We don't want to confuse people, and "setuptools2" is confusingly
>> similar to "setuptools" (to borrow a phrase from trademark law).
>>
>> The new project is based on setuptools but it is not a product of the
>> setuptools "project" so should have a distinct name.
>
> Agreed.
>
> Also, I'd suggest that the fork work on splitting out the components
> of setuptools - pkg_resources, the distutils extensions, easy_install
> - so that they can be used independently. That may mean being prepared
> to have a number of project names, rather than just one...

yes that' the plan, but the first release might be a "bug-free" clone
of the current
setuptool 0.6 branch, containing everything, before we start to split
it, in various
distributions.

>
> And now I'll refrain from bikeshedding further, too.
>

I agree with the fact that "setutptools2" is too close, I said I'd
change because I don't care
about the name, really.

So here's my suggestion:
I'll keep the "distribute" name unless someone comes up with a better
name here before the first release,
followed by more than 4 : "+1".

(I need to figure out a bikeshedding resolver process, that may help
for distutils discussions too ;) )

Cheers
Tarek

From regebro at gmail.com  Thu Jul 16 17:33:12 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 16 Jul 2009 17:33:12 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
Message-ID: <319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>

2009/7/16 Tarek Ziad? <ziade.tarek at gmail.com>:
> So here's my suggestion:
> I'll keep the "distribute" name unless someone comes up with a better
> name here before the first release,
> followed by more than 4 : "+1".

So I'll add my +1 for setuptools2.

Yes, it's an unauthorized fork, but it is very much a part of the
setuptools project, and it's aimed to be the successor to setuptools.
The fork is created out of pure necessity, not the wish of stepping on
anybody, and it's done because we love and need setuptools.
Setuptools2 is the obvious name, and the name that causes the least
confusion.

That said, it's bikeshedding, and I honestly don't care what it's
called. It can be called Zup2lsNG for all I care, as long as it works.
:)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From benji at zope.com  Thu Jul 16 17:44:58 2009
From: benji at zope.com (Benji York)
Date: Thu, 16 Jul 2009 11:44:58 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com> 
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com> 
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com> 
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com> 
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com> 
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
Message-ID: <e5fff6640907160844s470c429j95b2a493ee304785@mail.gmail.com>

On Thu, Jul 16, 2009 at 11:18 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> (I need to figure out a bikeshedding resolver process, that may help
> for distutils discussions too ;) )

For simple polls, doodle.com works well (example at
http://doodle.com/BSP77fprzt4z34th).

One down side being that you have to know what options you want
up-front.  So I guess you'd have to collect the candidates here and then
create a poll for the actual voting.
-- 
Benji York
Senior Software Engineer
Zope Corporation

From ktenney at gmail.com  Thu Jul 16 17:55:52 2009
From: ktenney at gmail.com (Kent Tenney)
Date: Thu, 16 Jul 2009 10:55:52 -0500
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
Message-ID: <ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>

On Thu, Jul 16, 2009 at 10:33 AM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/16 Tarek Ziad? <ziade.tarek at gmail.com>:
>> So here's my suggestion:
>> I'll keep the "distribute" name unless someone comes up with a better
>> name here before the first release,
>> followed by more than 4 : "+1".
>
> So I'll add my +1 for setuptools2.
>
> Yes, it's an unauthorized fork, but it is very much a part of the
> setuptools project, and it's aimed to be the successor to setuptools.
> The fork is created out of pure necessity, not the wish of stepping on
> anybody, and it's done because we love and need setuptools.
> Setuptools2 is the obvious name, and the name that causes the least
> confusion.
>
> That said, it's bikeshedding, and I honestly don't care what it's
> called.

I thought a good name was considered important.

> It can be called Zup2lsNG

-1

:-]


> for all I care, as long as it works.
> :)
>
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From santagada at gmail.com  Thu Jul 16 18:34:05 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Thu, 16 Jul 2009 13:34:05 -0300
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
Message-ID: <2f2e5f950907160934j2ae1e00bxacd92f6c501bbddd@mail.gmail.com>

On Thu, Jul 16, 2009 at 12:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> 2009/7/16 Paul Moore <p.f.moore at gmail.com>:
> > Also, I'd suggest that the fork work on splitting out the components
> > of setuptools - pkg_resources, the distutils extensions, easy_install
> > - so that they can be used independently. That may mean being prepared
> > to have a number of project names, rather than just one...
>
> yes that' the plan, but the first release might be a "bug-free" clone
> of the current
> setuptool 0.6 branch, containing everything, before we start to split
> it, in various
> distributions.
>

After the first release I would
suggest just dropping easy_install, there is already pip that does
instalation better than easy_install (and is supported by buildout I
think). One less piece to maintain and you people can focus more on
the packaging issue and not instalation

-- 
Leonardo Santagada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090716/cf95951b/attachment.htm>

From hanno at hannosch.eu  Thu Jul 16 19:28:07 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Thu, 16 Jul 2009 19:28:07 +0200
Subject: [Distutils] Progress on the first distribute release
Message-ID: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>

Hi there.

As promised I have gone through the setuptools tracker and tried to
identify the easy and ready-to-apply patches. As a result I have
applied the patches found in eight tickets [1] to the current
distribute code.

If you have another issue that is similarly uncontroversial and like
it to be fixed, please report a new issue at
http://bitbucket.org/tarek/distribute/issues/new.

I've readied my Windows box to build the required binary distributions
and installers for the 0.6 release. So hopefully there's just a few
more documentation updates to make, before we can get this release
out.

Cheers,
Hanno

[1] In all its gory details these issues were:

* Protected against failures in tarfile extraction. This closes
http://bitbucket.org/tarek/distribute/issue/10.

* Allow find_on_path on systems with tight permissions to fail
gracefully. This closes http://bitbucket.org/tarek/distribute/issue/9.

* Corrected inconsistency between documentation and code of add_entry.
This closes http://bitbucket.org/tarek/distribute/issue/8.

* Made api_tests.txt doctest compatible with Jython. This closes
http://bitbucket.org/tarek/distribute/issue/7.

* sandbox.py replaced builtin type file with builtin function open.
This closes http://bitbucket.org/tarek/distribute/issue/6.

* Immediately close all file handles. This closes
http://bitbucket.org/tarek/distribute/issue/3.

* Backported old distutils behaviour for add_defaults, to avoid a
recursive loop when setuptools builds the file list. This closes
http://bitbucket.org/tarek/distribute/issue/2.

* Added compatibility with Subversion 1.6. This references
http://bitbucket.org/tarek/distribute/issue/1.

From pje at telecommunity.com  Thu Jul 16 22:21:40 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 16 Jul 2009 16:21:40 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <7A4B245E-F707-42AE-AD22-B8BE84159A15@python.org>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<7A4B245E-F707-42AE-AD22-B8BE84159A15@python.org>
Message-ID: <20090716201836.EF9A93A403A@sparrow.telecommunity.com>

At 10:29 AM 7/16/2009 -0400, Barry Warsaw wrote:
>One thing I'd like to see for this new project is more built-in
>support for the popular revision control systems.

Arguably, the existing built-in support is a bug that should be 
fixed.  If SVN support was a plug-in, it could be more easily fixed 
when stuff changes.


From barry at python.org  Thu Jul 16 22:29:16 2009
From: barry at python.org (Barry Warsaw)
Date: Thu, 16 Jul 2009 16:29:16 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <20090716201836.EF9A93A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<7A4B245E-F707-42AE-AD22-B8BE84159A15@python.org>
	<20090716201836.EF9A93A403A@sparrow.telecommunity.com>
Message-ID: <1A31A192-7093-4E40-8559-1279614E9437@python.org>

On Jul 16, 2009, at 4:21 PM, P.J. Eby wrote:

> At 10:29 AM 7/16/2009 -0400, Barry Warsaw wrote:
>> One thing I'd like to see for this new project is more built-in
>> support for the popular revision control systems.
>
> Arguably, the existing built-in support is a bug that should be  
> fixed.  If SVN support was a plug-in, it could be more easily fixed  
> when stuff changes.

Using a plugin for this is still a pain, but revision control parity  
would still be a good thing, whether that argues for inclusion or  
exclusion in the core.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090716/6cd77a77/attachment.pgp>

From robert.kern at gmail.com  Thu Jul 16 22:44:19 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 16 Jul 2009 15:44:19 -0500
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <1A31A192-7093-4E40-8559-1279614E9437@python.org>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<4A5F3733.8050604@simplistix.co.uk>	<7A4B245E-F707-42AE-AD22-B8BE84159A15@python.org>	<20090716201836.EF9A93A403A@sparrow.telecommunity.com>
	<1A31A192-7093-4E40-8559-1279614E9437@python.org>
Message-ID: <h3o3f4$h8r$1@ger.gmane.org>

On 2009-07-16 15:29, Barry Warsaw wrote:
> On Jul 16, 2009, at 4:21 PM, P.J. Eby wrote:
>
>> At 10:29 AM 7/16/2009 -0400, Barry Warsaw wrote:
>>> One thing I'd like to see for this new project is more built-in
>>> support for the popular revision control systems.
>>
>> Arguably, the existing built-in support is a bug that should be fixed.
>> If SVN support was a plug-in, it could be more easily fixed when stuff
>> changes.
>
> Using a plugin for this is still a pain, but revision control parity
> would still be a good thing, whether that argues for inclusion or
> exclusion in the core.

I suspect one could have implementations in the core that could be overridden by 
plugins. Then you can have the best of both worlds at the cost of some 
additional complexity.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From regebro at gmail.com  Thu Jul 16 22:57:14 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 16 Jul 2009 22:57:14 +0200
Subject: [Distutils] [Distribute] What versions should we support?
Message-ID: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>

More specifically, Python 2.3 and/or 2.4?

The current trunk (or whatever mercurial calls it) doesn't work with
2.4, because of a try/except/finally clause. That's fixable, but I
ain't gonna fix it if we don't want to support 2.4 any more. I would
claim that we should support 2.4.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From encolpe.degoute at free.fr  Thu Jul 16 23:10:24 2009
From: encolpe.degoute at free.fr (Encolpe Degoute)
Date: Thu, 16 Jul 2009 23:10:24 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
Message-ID: <h3o4vn$mq7$1@ger.gmane.org>

Lennart Regebro a ?crit :
> More specifically, Python 2.3 and/or 2.4?
> 
> The current trunk (or whatever mercurial calls it) doesn't work with
> 2.4, because of a try/except/finally clause. That's fixable, but I
> ain't gonna fix it if we don't want to support 2.4 any more. I would
> claim that we should support 2.4.

-1
Even debian maintainers don't want to support python 2.4 anymore.

-- 
Encolpe DEGOUTE
Thursday is an early Friday
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activit?s c?r?brales


From regebro at gmail.com  Thu Jul 16 23:20:03 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 16 Jul 2009 23:20:03 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <h3o4vn$mq7$1@ger.gmane.org>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<h3o4vn$mq7$1@ger.gmane.org>
Message-ID: <319e029f0907161420r29940105vb94b0b43a593dc40@mail.gmail.com>

2009/7/16 Encolpe Degoute <encolpe.degoute at free.fr>:
> Lennart Regebro a ?crit :
>> More specifically, Python 2.3 and/or 2.4?
>>
>> The current trunk (or whatever mercurial calls it) doesn't work with
>> 2.4, because of a try/except/finally clause. That's fixable, but I
>> ain't gonna fix it if we don't want to support 2.4 any more. I would
>> claim that we should support 2.4.
>
> -1
> Even debian maintainers don't want to support python 2.4 anymore.

Well, don't want to is not really a question here, Python 2.4 is still
used a lot. If we don't support it, anybody who needs to support 2.4
(which means all of the Plone world, for a year or two more) can't use
Distribute. And I don't think supporting 2.4 will be difficult.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From encolpe.degoute at free.fr  Thu Jul 16 23:31:00 2009
From: encolpe.degoute at free.fr (Encolpe Degoute)
Date: Thu, 16 Jul 2009 23:31:00 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <319e029f0907161420r29940105vb94b0b43a593dc40@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>	<h3o4vn$mq7$1@ger.gmane.org>
	<319e029f0907161420r29940105vb94b0b43a593dc40@mail.gmail.com>
Message-ID: <h3o66a$qo9$1@ger.gmane.org>

Lennart Regebro a ?crit :
> 2009/7/16 Encolpe Degoute <encolpe.degoute at free.fr>:
>> Lennart Regebro a ?crit :
>>> More specifically, Python 2.3 and/or 2.4?
>>>
>>> The current trunk (or whatever mercurial calls it) doesn't work with
>>> 2.4, because of a try/except/finally clause. That's fixable, but I
>>> ain't gonna fix it if we don't want to support 2.4 any more. I would
>>> claim that we should support 2.4.
>> -1
>> Even debian maintainers don't want to support python 2.4 anymore.
> 
> Well, don't want to is not really a question here, Python 2.4 is still
> used a lot. If we don't support it, anybody who needs to support 2.4
> (which means all of the Plone world, for a year or two more) can't use
> Distribute. And I don't think supporting 2.4 will be difficult.

The Zope 2/Plone world will evolve to Zope 2.12 that run on python 2.5
and python 2.6.
Plone 4 target this Zope version.

Older projects will fix setuptools version < 2.

-- 
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activit?s c?r?brales


From regebro at gmail.com  Fri Jul 17 00:14:12 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 00:14:12 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <h3o66a$qo9$1@ger.gmane.org>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<h3o4vn$mq7$1@ger.gmane.org>
	<319e029f0907161420r29940105vb94b0b43a593dc40@mail.gmail.com>
	<h3o66a$qo9$1@ger.gmane.org>
Message-ID: <319e029f0907161514o30722794h1385adb1307a9ed6@mail.gmail.com>

2009/7/16 Encolpe Degoute <encolpe.degoute at free.fr>:
> The Zope 2/Plone world will evolve to Zope 2.12 that run on python 2.5
> and python 2.6.
> Plone 4 target this Zope version.
>
> Older projects will fix setuptools version < 2.

Not if you use svn 1.6, since setuptools 0.69c doesn't support that.

After thinking about this a bit more I've realized that we have to
have 2.4 support. We don't have a choice.


-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ncoghlan at gmail.com  Thu Jul 16 23:20:49 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 17 Jul 2009 07:20:49 +1000
Subject: [Distutils] [Python-Dev]  PEP 376 - from PyPM's point of  view
In-Reply-To: <4A5F1C58.3030003@online.de>
References: <op.uw06u6px1q4jlt@whymac.activestate.com>	<94bdd2610907150201y2204d4f6pbf57f3cd8e3d45f9@mail.gmail.com>	<79990c6b0907150310r318a6d9ep22e84f6c98355969@mail.gmail.com>	<94bdd2610907150700y55eb26d6qda2ebc4f702fb0af@mail.gmail.com>	<4A5DF2D9.6050403@online.de>	<20090715162736.B54D33A4116@sparrow.telecommunity.com>
	<4A5F1C58.3030003@online.de>
Message-ID: <4A5F99B1.6000006@gmail.com>

Joachim K?nig wrote:
> So one would have to set up the application specific packages before
> running the application, but the
> whole clutter of uncounted versions of the same package in one directory
> could go away. The
> "drawback" of this approach would be, that the same version of a package
> would have to be installed
> multiple times if needed by different applications.

While this is a very common practice in the Windows world, it is far
less common in the *nix world of vendor managed packaging systems.

As for why it can be a problem, it (bundling libraries with
applications) makes security vulnerability management a *lot* more
difficult for system administrators. If a bug is found in a key library
(e.g. openssl) a dependency based system just needs to update the single
shared copy of that library. In a bundling system, you first have to
work out which of your applications contain an instance of that library
and then see if the application vendors have provided a security patch.
If any one of them hasn't released a patch and you can't patch it
yourself, then you either have to stop using that application or else
accept remaining exposed to the vulnerability.

The bundling approach also leads to applications being much bigger than
they need to be. That isn't much of a problem for desktop or server
systems these days, but can still be an issue in the embedded world.

As far as the idea of making bundling easier goes, we already
implemented that in 2.6 and 3.0. It's the whole reason that zip files
and directories are directly executable now: the named zip file or
directory itself is automatically added to sys.path, so the top level
"__main__.py" in that location can freely import any other co-located
modules and packages.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From ben+python at benfinney.id.au  Fri Jul 17 01:48:01 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 17 Jul 2009 09:48:01 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork (was:
	Announcing the 'Distribute' project)
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
Message-ID: <874otci40e.fsf_-_@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> Ok so everyone agrees [?Distribute? is] a bad name for many good
> reasons :)
> 
> I am changing to setuptools2 then.

You've stated that you don't really care what the name is. Thank you for
stating that opinion clearly.

Acknowledging the risk of endless bike-shedding, I wish to disagree:
choosing a good name is very important. Analogous to the name of a
function or variable in our program code, a project name is the only
chance we have at initial communication with potential users. Unlike
identifiers in program code, the name of a project, once it becomes
established, is extremely difficult to change later.

A good name for a software project is typified as much by things to
avoid as much as things to aim for:

* The name should avoid unnecessary implication that this is ?the next
  version? of Setuptools. This is a fork, and should be named to make
  the distinction between the projects clear.

* The name should at least hint at the purpose of the software.

  It doesn't need to encapsulate the purpose directly, and that's almost
  impossible for most software ? especially when choosing a name for a
  fork that does essentially the same job. But it does need to make the
  association relatively easy to make in a newcomer's mind.

* The name should be easy to spell, search, and speak.

  That is, it should be formed by well-known orthographic rules (of
  English, probably, or some other common language), it should have a
  good chance of leading quickly to the project when typing a query
  string of ?python name_of_the_project?, and it should be fairly
  unambiguous in spelling when spoken aloud.

* Corrollaries of the above: the name should be relatively short and
  relatively unique among software projects.

That's a lot to ask of a simple identifier, but I'm convinced those are
all necessary for a name to be a good one. I never said choosing a good
name was easy :-)

Examples of ways to get a good name, by no means exhaustive, with
selected examples of using that way to get a good name:

* A short word that has a clever acronym expansion for the project.
  Remember that an acronym is a *pronounceable* word (otherwise it's
  just an initialism :-) Example: ?pip?.

* A word in a non-English language that is nevertheless easy for
  Anglophiles to spell and speak. Bonus points if the word has an
  indirect association to the project purpose. Example: ?midori?.

* The (easily-spelled-and-spoken) name of an animal, plant, or other
  natural phenomenon with properties that can be easily associated with
  the project purpose. Example: ?ferret?.

* An obscure (yet easily-spelled-and-spoken) English word whose meaning
  has a clever association with the project purpose. Example:
  ?perdition?.

* Obviously, there are others.

How's that?

-- 
 \         ?Pinky, are you pondering what I'm pondering?? ?I think so, |
  `\      Brain, but shouldn't the bat boy be wearing a cape?? ?_Pinky |
_o__)                                                   and The Brain_ |
Ben Finney


From david.lyon at preisshare.net  Fri Jul 17 02:07:44 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 16 Jul 2009 20:07:44 -0400
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
Message-ID: <117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>


Hi Hanno,

If I find anymore issues I can post them to there instead of the
mailing list.

Somebody should update the easy_install web site to direct users
to post to the tracker and not to the mailing list.

People are happy using Trackers and I'm starting to notice that
bug reports posted to the distutils mailing list are probably
being ignored at best.

Being ignored in a tracker is an entirely different thing - haha

David

On Thu, 16 Jul 2009 19:28:07 +0200, Hanno Schlichting <hanno at hannosch.eu>
wrote:
> Hi there.
> 
> As promised I have gone through the setuptools tracker and tried to
> identify the easy and ready-to-apply patches. As a result I have
> applied the patches found in eight tickets [1] to the current
> distribute code.
> 
> If you have another issue that is similarly uncontroversial and like
> it to be fixed, please report a new issue at
> http://bitbucket.org/tarek/distribute/issues/new.
> 
> I've readied my Windows box to build the required binary distributions
> and installers for the 0.6 release. So hopefully there's just a few
> more documentation updates to make, before we can get this release
> out.
> 
> Cheers,
> Hanno
> 
> [1] In all its gory details these issues were:
> 
> * Protected against failures in tarfile extraction. This closes
> http://bitbucket.org/tarek/distribute/issue/10.
> 
> * Allow find_on_path on systems with tight permissions to fail
> gracefully. This closes http://bitbucket.org/tarek/distribute/issue/9.
> 
> * Corrected inconsistency between documentation and code of add_entry.
> This closes http://bitbucket.org/tarek/distribute/issue/8.
> 
> * Made api_tests.txt doctest compatible with Jython. This closes
> http://bitbucket.org/tarek/distribute/issue/7.
> 
> * sandbox.py replaced builtin type file with builtin function open.
> This closes http://bitbucket.org/tarek/distribute/issue/6.
> 
> * Immediately close all file handles. This closes
> http://bitbucket.org/tarek/distribute/issue/3.
> 
> * Backported old distutils behaviour for add_defaults, to avoid a
> recursive loop when setuptools builds the file list. This closes
> http://bitbucket.org/tarek/distribute/issue/2.
> 
> * Added compatibility with Subversion 1.6. This references
> http://bitbucket.org/tarek/distribute/issue/1.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

From jdmain at comcast.net  Fri Jul 17 02:56:45 2009
From: jdmain at comcast.net (J.D. Main)
Date: Thu, 16 Jul 2009 18:56:45 -0600
Subject: [Distutils] py2exe - COM Server DLL can't be referenced by VB6
	or VS2003
In-Reply-To: <4A5EDBF3.2060104@timgolden.me.uk>
References: <4A5AF7D4.18308.D3F2915@jdmain.comcast.net>,
	<4A5E2EF1.11028.19CE7422@jdmain.comcast.net>,
	<4A5EDBF3.2060104@timgolden.me.uk>
Message-ID: <4A5F77ED.30839.1ED38A31@jdmain.comcast.net>

Thanks. I didn't know about that one.  It's not listed on the Python SIG page:

http://www.python.org/community/sigs/current/




J.D. Main wrote:
> Hey Guys,
> 
> I guess nobody knows or cares.  Where do the Win32 python guys hang 
> out?


Try the python-win32 list:

http://mail.python.org/mailman/listinfo/python-win32

TJG
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG at python.org
http://mail.python.org/mailman/listinfo/distutils-sig

From sridharr at activestate.com  Fri Jul 17 04:44:16 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Thu, 16 Jul 2009 19:44:16 -0700
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
Message-ID: <op.uw6xv2ev1q4jlt@whymac.activestate.com>

Sorry if I lack the information related to why there is now a fork. But  
does this mean that setuptools is becoming a dead project - as in no more  
fixes/commits? Or, is there going to be two separate tools - setuptools  
and distribute/setuptools2 - that will have ongoing releases?

In anycase, I wish the new project succeed and bring some good parts of  
setuptools (eg: pkg_resources/Distribution-related) to the stdlib. :-)

-srid

On Wed, 15 Jul 2009 17:13:41 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> Hello,
>
> We have started a new project called 'Distribute'. It's a fork of
> setuptools and its initial purpose will be to tackle
> the most annoying bugs found in setuptools 0.6c9 version.
>
> A first version will be released as soon as possible (probably next
> monday) and a document will explain how to migrate
> from setuptools. This should be fairly easy.
>
> The next step of the project will be some cleanup and a split in two
> distinct distributions:
>
> - one that contains only pkg_resources
> - one with the setuptools package.
>
> The project is here : http://bitbucket.org/tarek/setuptoolsbranch
>
> We have an issue tracker there where you can add feature requests and  
> bugs.
>
> Since its a DVCS repo, anyone is welcome to contribute patches.
>
> Regards
>
> Hanno, Chris, Tarek, and some other folks...
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig



From setuptools at bugs.python.org  Fri Jul 17 06:10:08 2009
From: setuptools at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 17 Jul 2009 04:10:08 +0000
Subject: [Distutils] [issue81] cannot install abstract.jwrotator
In-Reply-To: <1247803808.14.0.145014512955.issue81@psf.upfronthosting.co.za>
Message-ID: <1247803808.14.0.145014512955.issue81@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

The following command runs forever. But then, why would it try external 
downloads when this package has a tarball on pypi itself?

sridharr at whymac:/tmp/fo > bin/easy_install abstract.jwrotator
Searching for abstract.jwrotator
Reading http://pypi.python.org/simple/abstract.jwrotator/
Reading http://www.abstract.it/svn

----------
messages: 328
nosy: srid
priority: bug
status: unread
title: cannot install abstract.jwrotator

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue81>
_______________________________________________

From mail at timgolden.me.uk  Fri Jul 17 07:05:13 2009
From: mail at timgolden.me.uk (Tim Golden)
Date: Fri, 17 Jul 2009 06:05:13 +0100
Subject: [Distutils] py2exe - COM Server DLL can't be referenced by VB6
 or VS2003
In-Reply-To: <4A5F77ED.30839.1ED38A31@jdmain.comcast.net>
References: <4A5AF7D4.18308.D3F2915@jdmain.comcast.net>,
	<4A5E2EF1.11028.19CE7422@jdmain.comcast.net>,
	<4A5EDBF3.2060104@timgolden.me.uk>
	<4A5F77ED.30839.1ED38A31@jdmain.comcast.net>
Message-ID: <4A600689.7070207@timgolden.me.uk>

J.D. Main wrote:
> Thanks. I didn't know about that one.  It's not listed on the Python SIG page:
> 
> http://www.python.org/community/sigs/current/

Interestingly, I've never even thought of looking at
that page, and probably wouldn't have considered
win32 as a SIG -- even though it arguably is :)

For a wide range of Python mailing lists, look here:

  http://mail.python.org

TJG

From david.lyon at preisshare.net  Fri Jul 17 07:19:29 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 17 Jul 2009 01:19:29 -0400
Subject: [Distutils] [issue81] cannot install abstract.jwrotator
In-Reply-To: <1247803808.14.0.145014512955.issue81@psf.upfronthosting.co.za>
References: <1247803808.14.0.145014512955.issue81@psf.upfronthosting.co.za>
Message-ID: <aa779cd35f1ea6f62be24c216e705b90@preisshare.net>


-----------------------------------------------------------------------------------------
Running installer ... C:\Python25\scripts\easy_install.exe
abstract.jwrotator
Searching for abstract.jwrotator
Reading http://pypi.python.org/simple/abstract.jwrotator/
Reading http://www.abstract.it/svn

Download error: (10054, 'Connection reset by peer') -- Some packages may
not be found!
Best match: abstract.jwrotator 0.3
Downloading
http://pypi.python.org/packages/source/a/abstract.jwrotator/abstract.jwrotator-0.3.tar.gz#md5=f8e908d02f0f44a2d591342d8a32383a

Processing abstract.jwrotator-0.3.tar.gz

Running abstract.jwrotator-0.3\setup.py -q bdist_egg --dist-dir
c:\docume~1\david\locals~1\temp\easy_install-quzoim\abstract.jwrotator-0.3\egg-dist-tmp-rzo2wd
paster_plugins not set in setup(), but
abstract.jwrotator.egg-info\paster_plugins.txt exists

Adding abstract.jwrotator 0.3 to easy-install.pth file


Installed c:\python25\lib\site-packages\abstract.jwrotator-0.3-py2.5.egg
Processing dependencies for abstract.jwrotator
Finished processing dependencies for abstract.jwrotator

-----------------------------------------------------------------------------------------

On Fri, 17 Jul 2009 04:10:08 +0000, Sridhar Ratnakumar
<setuptools at bugs.python.org> wrote:
> New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
> 
> The following command runs forever. But then, why would it try external 
> downloads when this package has a tarball on pypi itself?
> 
> sridharr at whymac:/tmp/fo > bin/easy_install abstract.jwrotator
> Searching for abstract.jwrotator
> Reading http://pypi.python.org/simple/abstract.jwrotator/
> Reading http://www.abstract.it/svn
> 
> ----------
> messages: 328
> nosy: srid
> priority: bug
> status: unread
> title: cannot install abstract.jwrotator
> 
> _______________________________________________
> Setuptools tracker <setuptools at bugs.python.org>
> <http://bugs.python.org/setuptools/issue81>
> _______________________________________________
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

From greg.ewing at canterbury.ac.nz  Fri Jul 17 04:13:43 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 17 Jul 2009 14:13:43 +1200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
Message-ID: <4A5FDE57.4060207@canterbury.ac.nz>

Kent Tenney wrote:

> I thought a good name was considered important.

Are there any Monty Python sketches that relate to
packaging or distribution? That's the only way to
find names for really *important* things in Python.:-)

-- 
Greg

From regebro at gmail.com  Fri Jul 17 09:06:43 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 09:06:43 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
	(was: Announcing the 'Distribute' project)
In-Reply-To: <874otci40e.fsf_-_@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<874otci40e.fsf_-_@benfinney.id.au>
Message-ID: <319e029f0907170006x1436c98cq1656ac8aebde66b6@mail.gmail.com>

2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
> Tarek Ziad? <ziade.tarek at gmail.com> writes:
>
>> Ok so everyone agrees [?Distribute? is] a bad name for many good
>> reasons :)
>>
>> I am changing to setuptools2 then.
>
> You've stated that you don't really care what the name is. Thank you for
> stating that opinion clearly.
>
> Acknowledging the risk of endless bike-shedding, I wish to disagree:
> choosing a good name is very important. Analogous to the name of a
> function or variable in our program code, a project name is the only
> chance we have at initial communication with potential users. Unlike
> identifiers in program code, the name of a project, once it becomes
> established, is extremely difficult to change later.
>
> A good name for a software project is typified as much by things to
> avoid as much as things to aim for:
>
> * The name should avoid unnecessary implication that this is ?the next
> ?version? of Setuptools. This is a fork, and should be named to make
> ?the distinction between the projects clear.
>
> * The name should at least hint at the purpose of the software.
>
> ?It doesn't need to encapsulate the purpose directly, and that's almost
> ?impossible for most software ? especially when choosing a name for a
> ?fork that does essentially the same job. But it does need to make the
> ?association relatively easy to make in a newcomer's mind.
>
> * The name should be easy to spell, search, and speak.
>
> ?That is, it should be formed by well-known orthographic rules (of
> ?English, probably, or some other common language), it should have a
> ?good chance of leading quickly to the project when typing a query
> ?string of ?python name_of_the_project?, and it should be fairly
> ?unambiguous in spelling when spoken aloud.
>
> * Corrollaries of the above: the name should be relatively short and
> ?relatively unique among software projects.
>
> That's a lot to ask of a simple identifier, but I'm convinced those are
> all necessary for a name to be a good one. I never said choosing a good
> name was easy :-)
>
> Examples of ways to get a good name, by no means exhaustive, with
> selected examples of using that way to get a good name:
>
> * A short word that has a clever acronym expansion for the project.
> ?Remember that an acronym is a *pronounceable* word (otherwise it's
> ?just an initialism :-) Example: ?pip?.
>
> * A word in a non-English language that is nevertheless easy for
> ?Anglophiles to spell and speak. Bonus points if the word has an
> ?indirect association to the project purpose. Example: ?midori?.
>
> * The (easily-spelled-and-spoken) name of an animal, plant, or other
> ?natural phenomenon with properties that can be easily associated with
> ?the project purpose. Example: ?ferret?.
>
> * An obscure (yet easily-spelled-and-spoken) English word whose meaning
> ?has a clever association with the project purpose. Example:
> ??perdition?.
>
> * Obviously, there are others.
>
> How's that?

Very good argumentation, except that argument that wee need to
separate us from setuptools. Normally in an unfriendly fork I would
disagree. This is however not an unfriendly fork. It's a friendly
fork, and we do it because we must.

Anyway, easy to pronounce, easy to search, has something to do with
the project. Well, setuptools2 is still the good one there. Barring
that, we can't use distutils, or packageutils, which would be the best
names, because they are taken. Taken is also Packaging. So...
Distribute. Not much choice.

Unless we go the "obscure but cute" way, and call it cheesecloth. But
that fails the pronunciation test.


So, while you have arguments for having a good name, I think that in
the end it's so hard to come up with a good name that you usually have
to settle for one that is not bad. So, something that is easy to
remember, easy to say and doesn't mean anything rude in Norwegian. :-)


-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Fri Jul 17 09:11:19 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 09:11:19 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <4A5FDE57.4060207@canterbury.ac.nz>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
Message-ID: <319e029f0907170011v14cfad61l8564fe3fdae85db4@mail.gmail.com>

2009/7/17 Greg Ewing <greg.ewing at canterbury.ac.nz>:
> Kent Tenney wrote:
>
>> I thought a good name was considered important.
>
> Are there any Monty Python sketches that relate to
> packaging or distribution? That's the only way to
> find names for really *important* things in Python.:-)

I completely agree, and of course googled the scripts, and as far as I
could find, there is nothing.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Jul 17 10:17:18 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 10:17:18 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <op.uw6xv2ev1q4jlt@whymac.activestate.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
Message-ID: <94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>

2009/7/17 Sridhar Ratnakumar <sridharr at activestate.com>:
> Sorry if I lack the information related to why there is now a fork. But does
> this mean that setuptools is becoming a dead project - as in no more
> fixes/commits?

If this is your definition of "dead", setuptools is dead for 9 months now.

As soon as the name is found I'll blog about the reasons in detail.

Our fork will adress the bugs you can find in the current setuptools tracker,
then evolve in several distributions.

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

From ben+python at benfinney.id.au  Fri Jul 17 11:38:41 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 17 Jul 2009 19:38:41 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
Message-ID: <878winhcny.fsf_-_@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> Very good argumentation, except that argument that wee need to
> separate us from setuptools. Normally in an unfriendly fork I would
> disagree. This is however not an unfriendly fork. It's a friendly
> fork, and we do it because we must.

Whether or not the fork is friendly, it is a fork, not a continuation.
Also, there never really was a ?setuptools 1?. I think it's only going
to be confusing to call this ?setuptools 2?.

> So, while you have arguments for having a good name, I think that in
> the end it's so hard to come up with a good name that you usually have
> to settle for one that is not bad.

Undoubtedly, it's often the case that one must choose the least worst
name that one comes up with, because the best is already taken. But we
can surely do better than ?distribute? or ?setuptools 2?.

> So, something that is easy to remember, easy to say and doesn't mean
> anything rude in Norwegian. :-)

Greg Ewing <greg.ewing at canterbury.ac.nz> writes:

> Are there any Monty Python sketches that relate to packaging or
> distribution? That's the only way to find names for really *important*
> things in Python.:-)

Nice idea.

Okay, how about: ?Red Barrel?.

In Episode 31, the ?Travel Agent? sketch features a customer (with a
strange speech impediment) wanting to book a package tour, but he ends
up blathering on endlessly about bad experiences he's had on previous
package tours so the travel agent never actually manages to talk about
their tours <URL:http://orangecow.org/pythonet/sketches/package.htm>.

The customer makes many references to an ale named ?Watney's Red Barrel?
<http://en.wikipedia.org/wiki/Watney_Combe_%26_Reid#Watneys_Red_Barrel>,
to the point that this is the name many people associate with the sketch
itself.

So I propose the name ?Red Barrel? as directly suggesting packaging
(barrels), and having the reference to a popular Monty Python sketch ?
a sketch about package tours, hence another ?package? reference.

-- 
 \        ?I filled my humidifier with wax. Now my room is all shiny.? |
  `\                                                    ?Steven Wright |
_o__)                                                                  |
Ben Finney


From ziade.tarek at gmail.com  Fri Jul 17 11:40:29 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 11:40:29 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
Message-ID: <94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>

On Thu, Jul 16, 2009 at 10:57 PM, Lennart Regebro<regebro at gmail.com> wrote:
> More specifically, Python 2.3 and/or 2.4?
>
> The current trunk (or whatever mercurial calls it) doesn't work with
> 2.4, because of a try/except/finally clause. That's fixable, but I
> ain't gonna fix it if we don't want to support 2.4 any more. I would
> claim that we should support 2.4.
>

I think we can release a 2.4-compatible bugfix version then focus on
making it evolve with Distutils trunk.

It should be the 0.6 final version.

Then we can focus on working on the 0.7 series that will work with
Distutils current trunk.

When Python 2.7/3.2 are out, I am planning to release a standalone
version of Distutils that will work starting at 2.5.
Which means that the 0.7 series of Distribute will be able to work with it.

>From there we can maintain a 0.6.x maintenance branch that will work
with vanilla Python from 2.4 to 2.6 + 3.1
and a 0.7.x branch that will work with Python 2.7/3.2 and 2.5/2.6/3.1
if the users install the Distutils backport.

Which means that the roadmap of Distribute is indexed with Python :

- 0.6 final : asap
- 0.6.x : maintenance releases - not sure when they are released
- 0.7 alphas/betas : indexed with Python 2.7/3.2 alphas/betas
- 0.7 final:  : indexed with Python 2.7/3.2 final
- 0.7.X  : maintenance releases - not sure when they are released

The only problem with 2.4 I can see is that the tarfile module is badly broken.
So I propose shipping a backport of the 2.5 tarfile module with
Distribute 0.6 final.
(that's what I do with customer projects)

The other open question we need to think about is how to split the
distribution into several
distributions starting at 0.7.

e.g. what should be taken out Distribute 0.7 to live on its own.

Obviously, pkg_resources can be on a single distribution. (that
requires another name :) ) starting at 0.1,
when Distribute 0.7 is out

What else do we want to take out ? easy_install ? While is implemented
like a distutils command in
setuptools, it could be a standalone script like pip does.

Cheers
Tarek

From hanno at hannosch.eu  Fri Jul 17 11:50:31 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 11:50:31 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>
Message-ID: <5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>

Hi.

On Fri, Jul 17, 2009 at 2:07 AM, David Lyon<david.lyon at preisshare.net> wrote:
> If I find anymore issues I can post them to there instead of the
> mailing list.

Our bug tracker is open for submission by anyone. It's not a magical
thing though. So the same rules about good bug reports, repeatable
steps, preferably patches with tests and so on apply. Meta questions
and general observations about controversial issues are as likely to
get a non-optimal treatment as everywhere else ;)

> Somebody should update the easy_install web site to direct users
> to post to the tracker and not to the mailing list.

We'll update the documentation soon. We will need to find a new place
to put the documentation for this fork, though.

> People are happy using Trackers and I'm starting to notice that
> bug reports posted to the distutils mailing list are probably
> being ignored at best.
>
> Being ignored in a tracker is an entirely different thing - haha

Bug reports are ignored or never followed up upon on every mailing
list I've seen. There's a reason why bug trackers exist ;)

Hanno

From ziade.tarek at gmail.com  Fri Jul 17 11:51:24 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 11:51:24 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
Message-ID: <94bdd2610907170251g611451b9ndb5bb6ceb840272a@mail.gmail.com>

On Thu, Jul 16, 2009 at 7:28 PM, Hanno Schlichting<hanno at hannosch.eu> wrote:
> Hi there.
>
> As promised I have gone through the setuptools tracker and tried to
> identify the easy and ready-to-apply patches. As a result I have
> applied the patches found in eight tickets [1] to the current
> distribute code.
>
> If you have another issue that is similarly uncontroversial and like
> it to be fixed, please report a new issue at
> http://bitbucket.org/tarek/distribute/issues/new.
>
> I've readied my Windows box to build the required binary distributions
> and installers for the 0.6 release. So hopefully there's just a few
> more documentation updates to make, before we can get this release
> out.
>
> Cheers,
> Hanno
>

If everyone agrees, let's focus on changing the documentation and let's
release 0.6 final as soon as the documentation is changed and the name is found.

I'll branch then the repo to have a maintenance branch for 0.6, and we
will start on the 0.7x

From regebro at gmail.com  Fri Jul 17 11:51:45 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 11:51:45 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
Message-ID: <319e029f0907170251q5e0f42cchb6b12df5a9dd23ad@mail.gmail.com>

2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Thu, Jul 16, 2009 at 10:57 PM, Lennart Regebro<regebro at gmail.com> wrote:
>> More specifically, Python 2.3 and/or 2.4?
>>
>> The current trunk (or whatever mercurial calls it) doesn't work with
>> 2.4, because of a try/except/finally clause. That's fixable, but I
>> ain't gonna fix it if we don't want to support 2.4 any more. I would
>> claim that we should support 2.4.
>>
>
> I think we can release a 2.4-compatible bugfix version then focus on
> making it evolve with Distutils trunk.
>
> It should be the 0.6 final version.
>
> Then we can focus on working on the 0.7 series that will work with
> Distutils current trunk.
>
> When Python 2.7/3.2 are out, I am planning to release a standalone
> version of Distutils that will work starting at 2.5.
> Which means that the 0.7 series of Distribute will be able to work with it.
>
> From there we can maintain a 0.6.x maintenance branch that will work
> with vanilla Python from 2.4 to 2.6 + 3.1
> and a 0.7.x branch that will work with Python 2.7/3.2 and 2.5/2.6/3.1
> if the users install the Distutils backport.

Sounds reasonable.

> What else do we want to take out ? easy_install ? While is implemented
> like a distutils command in
> setuptools, it could be a standalone script like pip does.

I think that's a good idea.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Jul 17 11:54:13 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 11:54:13 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>
	<5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
Message-ID: <94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>

On Fri, Jul 17, 2009 at 11:50 AM, Hanno Schlichting<hanno at hannosch.eu> wrote:
> Hi.
>
> On Fri, Jul 17, 2009 at 2:07 AM, David Lyon<david.lyon at preisshare.net> wrote:
>> If I find anymore issues I can post them to there instead of the
>> mailing list.
>
> Our bug tracker is open for submission by anyone. It's not a magical
> thing though. So the same rules about good bug reports, repeatable
> steps, preferably patches with tests and so on apply. Meta questions
> and general observations about controversial issues are as likely to
> get a non-optimal treatment as everywhere else ;)
>
>> Somebody should update the easy_install web site to direct users
>> to post to the tracker and not to the mailing list.
>
> We'll update the documentation soon. We will need to find a new place
> to put the documentation for this fork, though.

Let's create a Sphinx-based website. I can host it on my server. As
soon as the name is chosen, we can set a domain
name too.

We can start to build the sphinx-based doc in the docs/ directory.

From regebro at gmail.com  Fri Jul 17 11:57:17 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 11:57:17 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <878winhcny.fsf_-_@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
Message-ID: <319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>

2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
> Whether or not the fork is friendly, it is a fork, not a continuation.

I disagree with that.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From hanno at hannosch.eu  Fri Jul 17 12:03:47 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 12:03:47 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>
	<5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
	<94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
Message-ID: <5cae42b20907170303v208ba308q7d9fd872839bafd8@mail.gmail.com>

On Fri, Jul 17, 2009 at 11:54 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Fri, Jul 17, 2009 at 11:50 AM, Hanno Schlichting<hanno at hannosch.eu> wrote:
>> We'll update the documentation soon. We will need to find a new place
>> to put the documentation for this fork, though.
>
> Let's create a Sphinx-based website. I can host it on my server. As
> soon as the name is chosen, we can set a domain
> name too.
>
> We can start to build the sphinx-based doc in the docs/ directory.

+1.

Hanno

From hanno at hannosch.eu  Fri Jul 17 12:11:59 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 12:11:59 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <319e029f0907170251q5e0f42cchb6b12df5a9dd23ad@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
	<319e029f0907170251q5e0f42cchb6b12df5a9dd23ad@mail.gmail.com>
Message-ID: <5cae42b20907170311j676366b0o711324986e020dcd@mail.gmail.com>

On Fri, Jul 17, 2009 at 11:51 AM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
>> When Python 2.7/3.2 are out, I am planning to release a standalone
>> version of Distutils that will work starting at 2.5.
>> Which means that the 0.7 series of Distribute will be able to work with it.
>>
>> From there we can maintain a 0.6.x maintenance branch that will work
>> with vanilla Python from 2.4 to 2.6 + 3.1

Yes. The current setuptools 0.6c9 release claims to be compatible with
Python 2.3 to 2.6. I'd like to maintain that same promise for the 0.6
release series. I don't see Python 3.x support as mandatory for these
maintenance releases. It's a new feature which can go into a new major
release. It's likely to be somewhat disruptive to do while retaining
support for all older releases.

>> and a 0.7.x branch that will work with Python 2.7/3.2 and 2.5/2.6/3.1
>> if the users install the Distutils backport.
>
> Sounds reasonable.

+1

Hanno

From regebro at gmail.com  Fri Jul 17 12:31:01 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 12:31:01 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <5cae42b20907170311j676366b0o711324986e020dcd@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
	<319e029f0907170251q5e0f42cchb6b12df5a9dd23ad@mail.gmail.com>
	<5cae42b20907170311j676366b0o711324986e020dcd@mail.gmail.com>
Message-ID: <319e029f0907170331g6b51c22kc4e5bd013ae893b5@mail.gmail.com>

2009/7/17 Hanno Schlichting <hanno at hannosch.eu>:
> Yes. The current setuptools 0.6c9 release claims to be compatible with
> Python 2.3 to 2.6. I'd like to maintain that same promise for the 0.6
> release series. I don't see Python 3.x support as mandatory for these
> maintenance releases. It's a new feature which can go into a new major
> release. It's likely to be somewhat disruptive to do while retaining
> support for all older releases.

Also, supporting both 2.3 and 3.1 is a LOT of work, even when using
2to3. I'd be happy to be able to drop both 2.3 and 2.4 support in the
Python 3 branch.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Jul 17 12:42:05 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 12:42:05 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <319e029f0907170331g6b51c22kc4e5bd013ae893b5@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
	<319e029f0907170251q5e0f42cchb6b12df5a9dd23ad@mail.gmail.com>
	<5cae42b20907170311j676366b0o711324986e020dcd@mail.gmail.com>
	<319e029f0907170331g6b51c22kc4e5bd013ae893b5@mail.gmail.com>
Message-ID: <94bdd2610907170342s2af2756j852901aeea0c6aae@mail.gmail.com>

On Fri, Jul 17, 2009 at 12:31 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/17 Hanno Schlichting <hanno at hannosch.eu>:
>> Yes. The current setuptools 0.6c9 release claims to be compatible with
>> Python 2.3 to 2.6. I'd like to maintain that same promise for the 0.6
>> release series. I don't see Python 3.x support as mandatory for these
>> maintenance releases. It's a new feature which can go into a new major
>> release. It's likely to be somewhat disruptive to do while retaining
>> support for all older releases.
>
> Also, supporting both 2.3 and 3.1 is a LOT of work, even when using
> 2to3. I'd be happy to be able to drop both 2.3 and 2.4 support in the
> Python 3 branch.

I don't think it's a lot of work to stick on 2.3 for 0.6, and yes,
let's drop any Python 3 support for it completely.

For Python 3 if we can't manage to have 2.5 to 3.2 support (I didn't
look at the porting problem myself yet so
I don't know) maybe you can start to work on another branch Lennart,
that will drop 2.x support
and focus on 3.x support.

Maybe that could be the 0.8 branch.

So what about this :

- 0.6.x : 2.3 to 2.6 support
- 0.7.x : 2.7 support, and 2.8 if it exists.  2.5 and 2.6 support if
the Distutils 2.7 backport is installed.
- 0.8.x and up : 3.2 and up

Cheers
Tarek

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

From ziade.tarek at gmail.com  Fri Jul 17 12:49:00 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 12:49:00 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <94bdd2610907170342s2af2756j852901aeea0c6aae@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
	<319e029f0907170251q5e0f42cchb6b12df5a9dd23ad@mail.gmail.com>
	<5cae42b20907170311j676366b0o711324986e020dcd@mail.gmail.com>
	<319e029f0907170331g6b51c22kc4e5bd013ae893b5@mail.gmail.com>
	<94bdd2610907170342s2af2756j852901aeea0c6aae@mail.gmail.com>
Message-ID: <94bdd2610907170349x745e8c7and4bd8066be6ba684@mail.gmail.com>

On Fri, Jul 17, 2009 at 12:42 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:

> - 0.8.x and up : 3.2 and up

3.1 and up I mean.

From regebro at gmail.com  Fri Jul 17 12:51:03 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 12:51:03 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <94bdd2610907170342s2af2756j852901aeea0c6aae@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
	<319e029f0907170251q5e0f42cchb6b12df5a9dd23ad@mail.gmail.com>
	<5cae42b20907170311j676366b0o711324986e020dcd@mail.gmail.com>
	<319e029f0907170331g6b51c22kc4e5bd013ae893b5@mail.gmail.com>
	<94bdd2610907170342s2af2756j852901aeea0c6aae@mail.gmail.com>
Message-ID: <319e029f0907170351q6449da3bm213645a67c004823@mail.gmail.com>

2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
> For Python 3 if we can't manage to have 2.5 to 3.2 support (I didn't
> look at the porting problem myself yet so
> I don't know) maybe you can start to work on another branch Lennart,

Of course we can have 2.5 to 3.2 support. We can have 2.3 support as
well, it's just way more work and more uglyness. The branch I have at
google code support 2.3 to 3.1. But it's not pretty. :-)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pje at telecommunity.com  Fri Jul 17 13:27:01 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 17 Jul 2009 07:27:01 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <878winhcny.fsf_-_@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
Message-ID: <20090717112359.588423A4099@sparrow.telecommunity.com>

At 07:38 PM 7/17/2009 +1000, Ben Finney wrote:
>Whether or not the fork is friendly, it is a fork, not a 
>continuation. Also, there never really was a ???setuptools 1???. I 
>think it's only going to be confusing to call this ???setuptools 2???.

Definitely.  I'd really rather it not be called that, and would 
prefer that your versioning scheme not imply a continuation 
either...  *especially* if it's based on the 0.6x branch, which is 
just about a dead parrot at this point.


>So I propose the name ???Red Barrel??? as directly suggesting 
>packaging (barrels), and having the reference to a popular Monty 
>Python sketch ? a sketch about packagee tours, hence another 
>???package??? reference.

Nice. 


From pje at telecommunity.com  Fri Jul 17 13:31:18 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 17 Jul 2009 07:31:18 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <op.uw6xv2ev1q4jlt@whymac.activestate.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
Message-ID: <20090717112815.820803A403A@sparrow.telecommunity.com>

At 07:44 PM 7/16/2009 -0700, Sridhar Ratnakumar wrote:
>Sorry if I lack the information related to why there is now a fork. But
>does this mean that setuptools is becoming a dead project - as in no more
>fixes/commits? Or, is there going to be two separate tools - setuptools
>and distribute/setuptools2 - that will have ongoing releases?

That other people are doing something based on the code does not in 
any way change my plans...  except that if the fork turns out to 
actually be useful, then I might stop even thinking about backward 
compatibility issues and write Something Completely Different instead.

For now, however, my plans for setuptools remain largely 
unchanged.  They await only time and/or funding, as has been the case 
for some considerable time now.


From benji at zope.com  Fri Jul 17 13:38:32 2009
From: benji at zope.com (Benji York)
Date: Fri, 17 Jul 2009 07:38:32 -0400
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com> 
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
Message-ID: <e5fff6640907170438x5765527dx356ebe2529624ced@mail.gmail.com>

On Fri, Jul 17, 2009 at 5:40 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> The only problem with 2.4 I can see is that the tarfile module is badly broken.
> So I propose shipping a backport of the 2.5 tarfile module with
> Distribute 0.6 final.
> (that's what I do with customer projects)

Big +1 (as long as the backported tarfile module doesn't shadow the
built-in tarfile, that's just asking for trouble).
-- 
Benji York
Senior Software Engineer
Zope Corporation

From hanno at hannosch.eu  Fri Jul 17 13:39:18 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 13:39:18 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
Message-ID: <5cae42b20907170439g79995697ua4aa18e67ee1e6fa@mail.gmail.com>

On Thu, Jul 16, 2009 at 10:57 PM, Lennart Regebro<regebro at gmail.com> wrote:
> The current trunk (or whatever mercurial calls it) doesn't work with
> 2.4, because of a try/except/finally clause. That's fixable, but I
> ain't gonna fix it if we don't want to support 2.4 any more. I would
> claim that we should support 2.4.

Where exactly do you see that try/except/finally? I cannot find such a
construct in the code I'm looking at.

I'm on "hg clone ssh://hg at bitbucket.org/tarek/distribute distribute"
and there's no branches yet as far as I know.

Hanno

From ben+python at benfinney.id.au  Fri Jul 17 13:42:00 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 17 Jul 2009 21:42:00 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
Message-ID: <87r5wffsdz.fsf@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> 2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
> > Whether or not the fork is friendly, it is a fork, not a
> > continuation.
> 
> I disagree with that.

That was the impression I got from the recent day's discussion. That's
only a minor point, anyway; I think all the other reasons for renaming
are still sound.

-- 
 \         ?I still have my Christmas Tree. I looked at it today. Sure |
  `\               enough, I couldn't see any forests.? ?Steven Wright |
_o__)                                                                  |
Ben Finney


From zooko at zooko.com  Fri Jul 17 13:55:03 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Fri, 17 Jul 2009 05:55:03 -0600
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
Message-ID: <B141F827-ACD7-4F37-BD1B-5A82545707CD@zooko.com>

Please consider this patch:

http://bugs.python.org/setuptools/issue53 # respect the PYTHONPATH

It is the biggest issue for many people.  In the ticket PJE describes  
several caveats about how that patch could interfere with other use  
cases.  I find it hard to keep track of the way different changes  
would impact competing use cases.  I love the Twisted development  
process in which such requirements get codified into unit tests which  
get run automatically by a buildbot.  Then I can look at the buildbot  
and if it is green I know that none of the supported use cases have  
regressed.  I've been doing something similar for the building/ 
packaging/installing use cases of the TahoeLAFS project (which is  
based on setuptools, or more precisely a tiny fork of setuptools  
maintained by myself).  See http://allmydata.org/buildbot .

Think we could cook up something like that for the setuptools2 (nee  
"Distribute") project?

Regards,

Zooko

From regebro at gmail.com  Fri Jul 17 14:23:41 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 14:23:41 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <87r5wffsdz.fsf@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
Message-ID: <319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>

2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
> That was the impression I got from the recent day's discussion. That's
> only a minor point, anyway; I think all the other reasons for renaming
> are still sound.

PJE wanted a rename, which settles that issue IMO.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Fri Jul 17 14:27:18 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 14:27:18 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <5cae42b20907170439g79995697ua4aa18e67ee1e6fa@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<5cae42b20907170439g79995697ua4aa18e67ee1e6fa@mail.gmail.com>
Message-ID: <319e029f0907170527m3ccf772cmf1f6eea3fa0a1448@mail.gmail.com>

2009/7/17 Hanno Schlichting <hanno at hannosch.eu>:
> Where exactly do you see that try/except/finally? I cannot find such a
> construct in the code I'm looking at.

Hm. You are right. It was late, I might have run it on a local branch
when I thought I was on trunk.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From zooko at zooko.com  Fri Jul 17 14:35:14 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Fri, 17 Jul 2009 06:35:14 -0600
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
Message-ID: <52737F4E-8565-42D3-9A0A-5D491818A451@zooko.com>

The downloads count on http://pypi.python.org/pypi/setuptools suggest  
that Python 2.4 is still slightly more popular than Python 2.5 among  
non-Windows users who download their setuptools from pypi.

My TahoeLAFS project, which I hope will be an early adopter of  
"Distribute", I mean "setuptools2", I mean "Zup2lsNG", currently  
still supports Python 2.4, but it is a bit of a hassle and I'm hoping  
to drop support for Python 2.4 before we switch to Zup2ls anyway.

Regards,

Zooko 

From david.lyon at preisshare.net  Fri Jul 17 14:34:02 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 17 Jul 2009 08:34:02 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
Message-ID: <9a5612039cb3991de00ae32bce93975d@preisshare.net>

On Fri, 17 Jul 2009 10:17:18 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> As soon as the name is found I'll blog about the reasons in detail.

Hi Tarek,

I suggest you consider "Packaging" for project name..

It is very generic, but at the same time specific.

Regards

David

From ziade.tarek at gmail.com  Fri Jul 17 14:41:32 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 14:41:32 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <5cae42b20907170303v208ba308q7d9fd872839bafd8@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>
	<5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
	<94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
	<5cae42b20907170303v208ba308q7d9fd872839bafd8@mail.gmail.com>
Message-ID: <94bdd2610907170541l41fc5877l170d682d99c54391@mail.gmail.com>

On Fri, Jul 17, 2009 at 12:03 PM, Hanno Schlichting<hanno at hannosch.eu> wrote:
> On Fri, Jul 17, 2009 at 11:54 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
>> On Fri, Jul 17, 2009 at 11:50 AM, Hanno Schlichting<hanno at hannosch.eu> wrote:
>>> We'll update the documentation soon. We will need to find a new place
>>> to put the documentation for this fork, though.
>>
>> Let's create a Sphinx-based website. I can host it on my server. As
>> soon as the name is chosen, we can set a domain
>> name too.
>>
>> We can start to build the sphinx-based doc in the docs/ directory.
>
> +1.
>

I've created the initial structure in docs/ and pushed api_tests.txt
doctest to the tests directory

Now we can start working in the docs/ directory,

instead of puting backs bits of setuptools docs there, I was thinking
about starting a
documentation from scratch, with these sections (and probably a lot of
links to the current peak website):

A- why a fork ? what are the future plans
B- how to switch from setuptools
C- a step-by-step tutorial on how to use the tool
D- good practices in recipes

A and B would be the only required part for the 0.6 release

Opinions ?

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

From ziade.tarek at gmail.com  Fri Jul 17 14:46:51 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 14:46:51 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <52737F4E-8565-42D3-9A0A-5D491818A451@zooko.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<52737F4E-8565-42D3-9A0A-5D491818A451@zooko.com>
Message-ID: <94bdd2610907170546sab90c58se17481ab0a6e1e99@mail.gmail.com>

On Fri, Jul 17, 2009 at 2:35 PM, Zooko Wilcox-O'Hearn<zooko at zooko.com> wrote:
> The downloads count on http://pypi.python.org/pypi/setuptools suggest that
> Python 2.4 is still slightly more popular than Python 2.5 among non-Windows
> users who download their setuptools from pypi.

That's the zc.buildout effect: zope-based applications are still using
2.4 so everytime
a zope-based app is built, setuptools for 2.4 is downloaded from PyPI.

The current status of 2.5/2.6 support is unclear to me in Plone land
for instance,
I thaught it was effective.

2.4 has to be supported in any case.

>
> My TahoeLAFS project, which I hope will be an early adopter of "Distribute",
> I mean "setuptools2", I mean "Zup2lsNG", currently still supports Python
> 2.4, but it is a bit of a hassle and I'm hoping to drop support for Python
> 2.4 before we switch to Zup2ls anyway.
>
> Regards,
>
> Zooko_______________________________________________
> 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  Fri Jul 17 14:48:13 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 14:48:13 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
Message-ID: <94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>

On Fri, Jul 17, 2009 at 2:23 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
>> That was the impression I got from the recent day's discussion. That's
>> only a minor point, anyway; I think all the other reasons for renaming
>> are still sound.
>
> PJE wanted a rename, which settles that issue IMO.

Ok then let's call it "Red Barrel" then


Unless I get 4 "-1"  (please don't ;) )

From david.lyon at preisshare.net  Fri Jul 17 14:54:10 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 17 Jul 2009 08:54:10 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
Message-ID: <302f4eed19b9479b938d77b30bfe309d@preisshare.net>

On Fri, 17 Jul 2009 14:48:13 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:

> Ok then let's call it "Red Barrel" then

-1 for me, -1 from my daughter..

Sounds too much like pork barrel, or red baron..



From santagada at gmail.com  Fri Jul 17 15:06:06 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Fri, 17 Jul 2009 10:06:06 -0300
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
Message-ID: <E6473AE5-D92A-48DC-85DD-AFDC2EBD3878@gmail.com>


On Jul 17, 2009, at 9:23 AM, Lennart Regebro wrote:

> 2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
>> That was the impression I got from the recent day's discussion.  
>> That's
>> only a minor point, anyway; I think all the other reasons for  
>> renaming
>> are still sound.
>
> PJE wanted a rename, which settles that issue IMO.


I would like to propose disttools, it could be the "setuptools fork to  
make it work closer with distutils".

--
Leonardo Santagada
santagada at gmail.com




From benji at zope.com  Fri Jul 17 15:07:23 2009
From: benji at zope.com (Benji York)
Date: Fri, 17 Jul 2009 09:07:23 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com> 
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com> 
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com> 
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com> 
	<4A5FDE57.4060207@canterbury.ac.nz> <878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com> 
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com> 
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
Message-ID: <e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>

On Fri, Jul 17, 2009 at 8:48 AM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> On Fri, Jul 17, 2009 at 2:23 PM, Lennart Regebro<regebro at gmail.com> wrote:
>> 2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
>>> That was the impression I got from the recent day's discussion. That's
>>> only a minor point, anyway; I think all the other reasons for renaming
>>> are still sound.
>>
>> PJE wanted a rename, which settles that issue IMO.
>
> Ok then let's call it "Red Barrel" then

Short, memorable, and (Monty) Pythonic.

+1
-- 
Benji York
Senior Software Engineer
Zope Corporation

From david.lyon at preisshare.net  Fri Jul 17 15:06:29 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 17 Jul 2009 09:06:29 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <302f4eed19b9479b938d77b30bfe309d@preisshare.net>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<302f4eed19b9479b938d77b30bfe309d@preisshare.net>
Message-ID: <204cdd956d6add7ba2150e919bcb64f3@preisshare.net>


1) "PackageTools" - like setuptools - but different

2) "Packaging" - straight to the point

3) "EggWrappers" - what you put eggs in

4) "PyPackage" - it's cheesy

5) "ShrinkWrap" - hot plastic packaging... 



From mihamina at gulfsat.mg  Fri Jul 17 15:26:11 2009
From: mihamina at gulfsat.mg (Rakotomandimby Mihamina)
Date: Fri, 17 Jul 2009 16:26:11 +0300
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
Message-ID: <4A607BF3.8060908@gulfsat.mg>

07/17/2009 04:07 PM, Benji York:
>> Ok then let's call it "Red Barrel" then
> Short, memorable, and (Monty) Pythonic.
> +1

+1

Let's keep History in.

-- 
                             Architecte Informatique:
    Administration Systeme, Recherche & Developpement
                                   + 261 32 11 401 65
Pensez a l'environnement avant d'imprimer ce message

From ziade.tarek at gmail.com  Fri Jul 17 15:37:57 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 15:37:57 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <4A607BF3.8060908@gulfsat.mg>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
Message-ID: <94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>

On Fri, Jul 17, 2009 at 3:26 PM, Rakotomandimby
Mihamina<mihamina at gulfsat.mg> wrote:
> 07/17/2009 04:07 PM, Benji York:
>>>
>>> Ok then let's call it "Red Barrel" then
>>
>> Short, memorable, and (Monty) Pythonic.
>> +1
>
> +1
>

Ok I'll act a bit like a dictactor for this ;)

here's a Poll with the two finalists

http://doodle.com/4eyxzrwgwq4a6t9s

Pick the one you like, and we'll use the winner Monday for the release

From regebro at gmail.com  Fri Jul 17 15:44:01 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 15:44:01 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <9a5612039cb3991de00ae32bce93975d@preisshare.net>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
Message-ID: <319e029f0907170644k7be29cd0x1a2235b7c1a4675@mail.gmail.com>

2009/7/17 David Lyon <david.lyon at preisshare.net>:
> On Fri, 17 Jul 2009 10:17:18 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
>> As soon as the name is found I'll blog about the reasons in detail.
>
> Hi Tarek,
>
> I suggest you consider "Packaging" for project name..
>
> It is very generic, but at the same time specific.

But taken.
http://pypi.python.org/pypi/packaging/

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From hanno at hannosch.eu  Fri Jul 17 15:45:56 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 15:45:56 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <94bdd2610907170546sab90c58se17481ab0a6e1e99@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<52737F4E-8565-42D3-9A0A-5D491818A451@zooko.com>
	<94bdd2610907170546sab90c58se17481ab0a6e1e99@mail.gmail.com>
Message-ID: <5cae42b20907170645s3eb13c42yc21d0539b973f8cd@mail.gmail.com>

On Fri, Jul 17, 2009 at 2:46 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> The current status of 2.5/2.6 support is unclear to me in Plone land
> for instance,
> I thaught it was effective.

The story for most of Plone and Zope 2 / Zope Toolkit is:

- Stable released versions of Plone and Zope 2 only work with Python
2.4 - nothing newer.
- The last Zope 3 release also works with Python 2.5.

By the end of this year we will have new major versions of all of
them, which do longer support Python 2.4 but instead need Python 2.5
or 2.6. They officially recommend 2.6.

Considering adoption rate of new releases, that means there's still
going to be a number of years where Python 2.4 is going to be dominant
in the Zope/Plone world. But then again there's still many Python 2.1
and Python 2.3 installations out there.

That calls for the willingness to support a backwards compatible 0.6
release series, but no features or improvements need to be made to
this line. In the end current setuptools and buildout works for all
Plone and Zope users the way it is. The Subversion 1.6 bug is the only
major one I encountered which hit people constantly.

Hanno

From ben+python at benfinney.id.au  Fri Jul 17 15:49:31 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 17 Jul 2009 23:49:31 +1000
Subject: [Distutils] Announcing the 'Distribute' project
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
Message-ID: <87ab33fmhg.fsf@benfinney.id.au>

David Lyon <david.lyon at preisshare.net> writes:

> I suggest you consider "Packaging" for project name..
> 
> It is very generic, but at the same time specific.

-1

Fails the web search test: a search for ?python packaging? will not
find this project specifically. Even worse, the seeker could just as
easily be trying to search for all the various discussions about
packaging for Python, and *not* want one specific project to get in the
way of the results.

-- 
 \           ?The lift is being fixed for the day. During that time we |
  `\            regret that you will be unbearable.? ?hotel, Bucharest |
_o__)                                                                  |
Ben Finney


From ben+python at benfinney.id.au  Fri Jul 17 15:50:36 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 17 Jul 2009 23:50:36 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<E6473AE5-D92A-48DC-85DD-AFDC2EBD3878@gmail.com>
Message-ID: <8763drfmfn.fsf@benfinney.id.au>

Leonardo Santagada <santagada at gmail.com> writes:

> I would like to propose disttools, it could be the "setuptools fork to
> make it work closer with distutils".

+0. It's not memorably different, but the associations are all correct.

-- 
 \         ?I'm beginning to think that life is just one long Yoko Ono |
  `\   album; no rhyme or reason, just a lot of incoherent shrieks and |
_o__)                                      then it's over.? ?Ian Wolff |
Ben Finney


From p.f.moore at gmail.com  Fri Jul 17 15:58:52 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 17 Jul 2009 14:58:52 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
Message-ID: <79990c6b0907170658r67a97189r4d7c8d7821ecd1ff@mail.gmail.com>

2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Fri, Jul 17, 2009 at 2:23 PM, Lennart Regebro<regebro at gmail.com> wrote:
>> 2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
>>> That was the impression I got from the recent day's discussion. That's
>>> only a minor point, anyway; I think all the other reasons for renaming
>>> are still sound.
>>
>> PJE wanted a rename, which settles that issue IMO.
>
> Ok then let's call it "Red Barrel" then
>
>
> Unless I get 4 "-1" ?(please don't ;) )

Sorry, I'm going to be a spoilsport. Remember PyPI -> Cheese Shop ->
PyPI? Monty Python names are fun, but they confuse people a bit too
much when used as high-profile project name.

I actually like disttools (can't recall who suggested it) but I see
Tarek didn't include it in the poll. Ah, well...

Paul.

From ziade.tarek at gmail.com  Fri Jul 17 16:02:07 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 16:02:07 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <79990c6b0907170658r67a97189r4d7c8d7821ecd1ff@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<79990c6b0907170658r67a97189r4d7c8d7821ecd1ff@mail.gmail.com>
Message-ID: <94bdd2610907170702o38171e69j79f4b221598d8928@mail.gmail.com>

On Fri, Jul 17, 2009 at 3:58 PM, Paul Moore<p.f.moore at gmail.com> wrote:
> 2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
> I actually like disttools (can't recall who suggested it) but I see
> Tarek didn't include it in the poll. Ah, well...
>

I have added it. you can vote for it (I am trying to keep the choice small)



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

From barry at python.org  Fri Jul 17 16:02:35 2009
From: barry at python.org (Barry Warsaw)
Date: Fri, 17 Jul 2009 10:02:35 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <79990c6b0907170658r67a97189r4d7c8d7821ecd1ff@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<79990c6b0907170658r67a97189r4d7c8d7821ecd1ff@mail.gmail.com>
Message-ID: <E5435417-F2EE-4231-A322-A5E7E1136925@python.org>

On Jul 17, 2009, at 9:58 AM, Paul Moore wrote:

> 2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
>> On Fri, Jul 17, 2009 at 2:23 PM, Lennart Regebro<regebro at gmail.com>  
>> wrote:
>>> 2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
>>>> That was the impression I got from the recent day's discussion.  
>>>> That's
>>>> only a minor point, anyway; I think all the other reasons for  
>>>> renaming
>>>> are still sound.
>>>
>>> PJE wanted a rename, which settles that issue IMO.
>>
>> Ok then let's call it "Red Barrel" then
>>
>>
>> Unless I get 4 "-1"  (please don't ;) )
>
> Sorry, I'm going to be a spoilsport. Remember PyPI -> Cheese Shop ->
> PyPI? Monty Python names are fun, but they confuse people a bit too
> much when used as high-profile project name.

Well, I disagreed with that decision because PyPI was /more/ confusing  
(IMHO) since PyPy also exists, and is a homonym.  Which means when  
you're actually talking about it, you have to say "no, I mean the  
Python Packaging Index".  This is one place where I think a cute MP  
name was perfectly descriptive, fun, memorable, distinctive, and just  
plain right.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090717/27b35b34/attachment.pgp>

From david.lyon at preisshare.net  Fri Jul 17 15:58:51 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 17 Jul 2009 09:58:51 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <8763drfmfn.fsf@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<E6473AE5-D92A-48DC-85DD-AFDC2EBD3878@gmail.com>
	<8763drfmfn.fsf@benfinney.id.au>
Message-ID: <01c5509bb26c169b486fbd3de4033d3d@preisshare.net>


"MontyPackage" - Monty who?

From chris at simplistix.co.uk  Fri Jul 17 16:03:25 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:03:25 +0100
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
Message-ID: <4A6084AD.2010301@simplistix.co.uk>

Benji York wrote:
> Given that this is -- I'm assuming -- an "unauthorized" fork, I wouldn't
> use "setuptools2" as the name.

I don't think it is "unauthorized", Phil knows it's happening and hasn't 
complained.

I think it's perfectly sensible given the contents of the package.

Chris

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

From regebro at gmail.com  Fri Jul 17 16:07:56 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 16:07:56 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <01c5509bb26c169b486fbd3de4033d3d@preisshare.net>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<E6473AE5-D92A-48DC-85DD-AFDC2EBD3878@gmail.com>
	<8763drfmfn.fsf@benfinney.id.au>
	<01c5509bb26c169b486fbd3de4033d3d@preisshare.net>
Message-ID: <319e029f0907170707x374f0f57v54498e020f6757c0@mail.gmail.com>

disttools? Hmm.


pkgutils
distutils
setuptools
disttools

Well, then we only need pkgtools and setuputils to complete the
confusion. If that's good or bad is a matter of taste I guess. :)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From chris at simplistix.co.uk  Fri Jul 17 16:07:58 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:07:58 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <878winhcny.fsf_-_@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<4A5F3733.8050604@simplistix.co.uk>	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
Message-ID: <4A6085BE.4090601@simplistix.co.uk>

Ben Finney wrote:
> Whether or not the fork is friendly, it is a fork, not a continuation.

Er, it's a drop-in replacement with an identical API, how is that not a 
continuation?

Chris

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

From chris at simplistix.co.uk  Fri Jul 17 16:08:59 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:08:59 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>	<878winhcny.fsf_-_@benfinney.id.au>	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>	<87r5wffsdz.fsf@benfinney.id.au>	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
Message-ID: <4A6085FB.3010401@simplistix.co.uk>

Tarek Ziad? wrote:
> On Fri, Jul 17, 2009 at 2:23 PM, Lennart Regebro<regebro at gmail.com> wrote:
>> 2009/7/17 Ben Finney <ben+python at benfinney.id.au>:
>>> That was the impression I got from the recent day's discussion. That's
>>> only a minor point, anyway; I think all the other reasons for renaming
>>> are still sound.
>> PJE wanted a rename, which settles that issue IMO.
> 
> Ok then let's call it "Red Barrel" then
> 
> Unless I get 4 "-1"  (please don't ;) )

-1 I'm afraid.

Meaningful package names are pretty important.

Chris

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

From ronaldoussoren at mac.com  Fri Jul 17 16:09:38 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 17 Jul 2009 16:09:38 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz> <878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
Message-ID: <49583975633816029001522603707116473601-Webmail@me.com>

 
On Friday, 17 July, 2009, at 03:37PM, "Tarek Ziad?" <ziade.tarek at gmail.com> wrote:
>On Fri, Jul 17, 2009 at 3:26 PM, Rakotomandimby
>Mihamina<mihamina at gulfsat.mg> wrote:
>> 07/17/2009 04:07 PM, Benji York:
>>>>
>>>> Ok then let's call it "Red Barrel" then
>>>
>>> Short, memorable, and (Monty) Pythonic.
>>> +1
>>
>> +1
>>
>
>Ok I'll act a bit like a dictactor for this ;)
>
>here's a Poll with the two finalists
>
>http://doodle.com/4eyxzrwgwq4a6t9s
>
>Pick the one you like, and we'll use the winner Monday for the release

I don't have an account at doodle and won't create one.

My vote: Distribute.  

Ronald


From ziade.tarek at gmail.com  Fri Jul 17 16:11:19 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 16:11:19 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <49583975633816029001522603707116473601-Webmail@me.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<49583975633816029001522603707116473601-Webmail@me.com>
Message-ID: <94bdd2610907170711q15edc567q3de372349aa6eabd@mail.gmail.com>

On Fri, Jul 17, 2009 at 4:09 PM, Ronald Oussoren<ronaldoussoren at mac.com> wrote:
>
> On Friday, 17 July, 2009, at 03:37PM, "Tarek Ziad?" <ziade.tarek at gmail.com> wrote:
>>On Fri, Jul 17, 2009 at 3:26 PM, Rakotomandimby
>>Mihamina<mihamina at gulfsat.mg> wrote:
>>> 07/17/2009 04:07 PM, Benji York:
>>>>>
>>>>> Ok then let's call it "Red Barrel" then
>>>>
>>>> Short, memorable, and (Monty) Pythonic.
>>>> +1
>>>
>>> +1
>>>
>>
>>Ok I'll act a bit like a dictactor for this ;)
>>
>>here's a Poll with the two finalists
>>
>>http://doodle.com/4eyxzrwgwq4a6t9s
>>
>>Pick the one you like, and we'll use the winner Monday for the release
>
> I don't have an account at doodle and won't create one.

No need to create an account. If you get on the page, you just put
your name, choose
and click.

And if you don't want to see your name listed, Ronald. O. is fine


>
> My vote: Distribute.
>
> Ronald
>
>



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

From chris at simplistix.co.uk  Fri Jul 17 16:12:25 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:12:25 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090717112359.588423A4099@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<4A5F3733.8050604@simplistix.co.uk>	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
Message-ID: <4A6086C9.7000203@simplistix.co.uk>

P.J. Eby wrote:
> At 07:38 PM 7/17/2009 +1000, Ben Finney wrote:
>> Whether or not the fork is friendly, it is a fork, not a continuation. 
>> Also, there never really was a ???setuptools 1???. I think it's only 
>> going to be confusing to call this ???setuptools 2???.
> 
> Definitely.  I'd really rather it not be called that, and would prefer 
> that your versioning scheme not imply a continuation either...  
> *especially* if it's based on the 0.6x branch, which is just about a 
> dead parrot at this point.

Phil,

How come you couldn't reply to anything other than this?

I really don't understand your attitude and lack on communication on 
what has become so important a package...

Chris

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

From benji at zope.com  Fri Jul 17 16:12:34 2009
From: benji at zope.com (Benji York)
Date: Fri, 17 Jul 2009 10:12:34 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <49583975633816029001522603707116473601-Webmail@me.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com> 
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com> 
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com> 
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com> 
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com> 
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com> 
	<49583975633816029001522603707116473601-Webmail@me.com>
Message-ID: <e5fff6640907170712i27787896u9d313c0f5ae6b9e9@mail.gmail.com>

On Fri, Jul 17, 2009 at 10:09 AM, Ronald Oussoren<ronaldoussoren at mac.com> wrote:
> I don't have an account at doodle and won't create one.

You don't need a account to vote.
-- 
Benji York
Senior Software Engineer
Zope Corporation

From chris at simplistix.co.uk  Fri Jul 17 16:16:20 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:16:20 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <874otci40e.fsf_-_@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<4A5F3733.8050604@simplistix.co.uk>	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<874otci40e.fsf_-_@benfinney.id.au>
Message-ID: <4A6087B4.7010705@simplistix.co.uk>

Ben Finney wrote:
> * The name should avoid unnecessary implication that this is ?the next
>   version? of Setuptools. 

..but it is.

> This is a fork, and should be named to make
>   the distinction between the projects clear.

I disagree. Phil could have made this *much* easier at any point by just 
giving more access to setuptools development. He's stubbornly refused to 
do either this or develop setuptools himself.

If he knows otherwise, I wish he would say something publicly...

> * The name should at least hint at the purpose of the software.

Agreed.

> * The name should be easy to spell, search, and speak.

Agreed.

Chris

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

From chris at simplistix.co.uk  Fri Jul 17 16:17:47 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:17:47 +0100
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <9a5612039cb3991de00ae32bce93975d@preisshare.net>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<op.uw6xv2ev1q4jlt@whymac.activestate.com>	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
Message-ID: <4A60880B.4060303@simplistix.co.uk>

David Lyon wrote:
> I suggest you consider "Packaging" for project name..

Potential verbs are bad for package names

packagetools yes, but we already have pkg_tools :-S

Chris

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

From chris at simplistix.co.uk  Fri Jul 17 16:19:07 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:19:07 +0100
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <20090717112815.820803A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
	<20090717112815.820803A403A@sparrow.telecommunity.com>
Message-ID: <4A60885B.1000207@simplistix.co.uk>

P.J. Eby wrote:
> That other people are doing something based on the code does not in any 
> way change my plans...  except that if the fork turns out to actually be 
> useful, then I might stop even thinking about backward compatibility 
> issues and write Something Completely Different instead.
> 
> For now, however, my plans for setuptools remain largely unchanged.  
> They await only time and/or funding, as has been the case for some 
> considerable time now.

Any chance you could tell someone other than yourself what these are?!

(and while you're at it, any chance of not just ignoring mail from 
people who are, ultimately, trying to help?)

Chris

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

From david.lyon at preisshare.net  Fri Jul 17 16:36:46 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 17 Jul 2009 10:36:46 -0400
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <4A60880B.4060303@simplistix.co.uk>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<op.uw6xv2ev1q4jlt@whymac.activestate.com>	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
	<4A60880B.4060303@simplistix.co.uk>
Message-ID: <36a0c722c046dcbe5e685e1653ac088d@preisshare.net>

On Fri, 17 Jul 2009 15:17:47 +0100, Chris Withers <chris at simplistix.co.uk>
wrote:
> 
> packagetools yes, but we already have pkg_tools :-S

packagetools is very easy to read, talks about 'packages' and
may be vaigely reminiscent to setuptools...

It is very succinct and represents a name improvement on setuptools.

montypackage may be immediately humourous....

I watched the Monty Python films, but don't remember any red
barrels.

Another totally unique name is "packagepy". That's not on
pypi.

At the end of the day, it's Tareks project. So whatever he
decides for the project will be the right decision..

David


From pje at telecommunity.com  Fri Jul 17 16:44:29 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 17 Jul 2009 10:44:29 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <4A6086C9.7000203@simplistix.co.uk>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
Message-ID: <20090717144125.5C12A3A403A@sparrow.telecommunity.com>

At 03:12 PM 7/17/2009 +0100, Chris Withers wrote:
>P.J. Eby wrote:
>>At 07:38 PM 7/17/2009 +1000, Ben Finney wrote:
>>>Whether or not the fork is friendly, it is a fork, not a 
>>>continuation. Also, there never really was a ???setuptools 1???. I 
>>>think it's only going to be confusing to call this ???setuptools 2???.
>>Definitely.  I'd really rather it not be called that, and would 
>>prefer that your versioning scheme not imply a continuation either...
>>*especially* if it's based on the 0.6x branch, which is just about 
>>a dead parrot at this point.
>
>Phil,
>
>How come you couldn't reply to anything other than this?

Because if you RTFM'd, you'd see that I don't respond to private 
email about setuptools.  Had you written via the distutils-SIG, you'd 
have had a better chance of an answer, though it might still have 
taken another week before you got the reply.

(I have odds and ends from distutils-SIG saved in a folder for later 
reply or action...  but the oldest is from February 2007, so two 
weeks isn't that bad!)


>I really don't understand your attitude and lack on communication on 
>what has become so important a package...

Setuptools was something I originally wrote for common requirements 
in my work projects...  then expanded into a funded project to 
provide Chandler with a plugin infrastructure.  These days, I don't 
have time to code on the projects I *enjoy* and *want* to code 
on...  and setuptools as it stands today is not one of those projects.


From chris at simplistix.co.uk  Fri Jul 17 16:49:14 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:49:14 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090717144125.5C12A3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
Message-ID: <4A608F6A.5070600@simplistix.co.uk>

P.J. Eby wrote:
> Setuptools was something I originally wrote for common requirements in 
> my work projects...  then expanded into a funded project to provide 
> Chandler with a plugin infrastructure.  These days, I don't have time to 
> code on the projects I *enjoy* and *want* to code on...  and setuptools 
> as it stands today is not one of those projects.

Then why on earth don't you open up the development of setuptools and 
let other people progress the project?!

Chris

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

From regebro at gmail.com  Fri Jul 17 16:53:19 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 16:53:19 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090717144125.5C12A3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
Message-ID: <319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>

2009/7/17 P.J. Eby <pje at telecommunity.com>:
> Setuptools was something I originally wrote for common requirements in my
> work projects... ?then expanded into a funded project to provide Chandler
> with a plugin infrastructure. ?These days, I don't have time to code on the
> projects I *enjoy* and *want* to code on... ?and setuptools as it stands
> today is not one of those projects.

This is completely understandable, and a good reason not to work on
it. The problem is that you simultaneously have prevented others to
work on it, which now finally has created this fork. We don't want to
fork it. We don't want to rename it. We don't want to have a
bikeshedding discussion. We just *need* to fix setuptools. The best
name for this for is obviously "setuptools", because that's what it
is. It's setuptools. We only for it because you won't let us fix the
main fork.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From chris at simplistix.co.uk  Fri Jul 17 16:53:48 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 17 Jul 2009 15:53:48 +0100
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <36a0c722c046dcbe5e685e1653ac088d@preisshare.net>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<op.uw6xv2ev1q4jlt@whymac.activestate.com>	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
	<4A60880B.4060303@simplistix.co.uk>
	<36a0c722c046dcbe5e685e1653ac088d@preisshare.net>
Message-ID: <4A60907C.8070702@simplistix.co.uk>

David Lyon wrote:
> On Fri, 17 Jul 2009 15:17:47 +0100, Chris Withers <chris at simplistix.co.uk>
> wrote:
>> packagetools yes, but we already have pkg_tools :-S
> 
> packagetools is very easy to read, talks about 'packages' and
> may be vaigely reminiscent to setuptools...

packagetools or pypackaging would make me happy, if we can't get PJE to 
either allow us access to setuptools or if no-one has the guts to just 
use setuptools2 (which is exactly what this project is ;-) )

I'm annoyed by the poll because it only had two crap options on it for 
the first majority of the votes. Tarek doesn't see this as a problem 
(because it sees 'distribute' stay as the project name) and is sure it's 
all fair because people can re-vote if they want to.

So, if you voted and wanted something other than "distribute" or 
"redbarrel", please re-vote. If your option isn't there, please consider 
selecting the awkwardly named third column option.

Myself, I'd prefer an option not on there, but I don't know what to do, 
if I change my vote, the only other option on the poll stands less 
chance of succeeding.

Myself, I'd prefer setuptools2, packagetools, pypackaging, disttools, 
{anything else} in that order...

Chris

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

From p.f.moore at gmail.com  Fri Jul 17 16:54:14 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 17 Jul 2009 15:54:14 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907170702o38171e69j79f4b221598d8928@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<79990c6b0907170658r67a97189r4d7c8d7821ecd1ff@mail.gmail.com>
	<94bdd2610907170702o38171e69j79f4b221598d8928@mail.gmail.com>
Message-ID: <79990c6b0907170754n552f84edwfafc8ae0d3e4f8f9@mail.gmail.com>

2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Fri, Jul 17, 2009 at 3:58 PM, Paul Moore<p.f.moore at gmail.com> wrote:
>> 2009/7/17 Tarek Ziad? <ziade.tarek at gmail.com>:
>> I actually like disttools (can't recall who suggested it) but I see
>> Tarek didn't include it in the poll. Ah, well...
>>
>
> I have added it. you can vote for it (I am trying to keep the choice small)

Doesn't look like I can edit my vote. But OK to either Distribute or disttools.
Paul.

From regebro at gmail.com  Fri Jul 17 16:58:25 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 16:58:25 +0200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <4A60907C.8070702@simplistix.co.uk>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
	<4A60880B.4060303@simplistix.co.uk>
	<36a0c722c046dcbe5e685e1653ac088d@preisshare.net>
	<4A60907C.8070702@simplistix.co.uk>
Message-ID: <319e029f0907170758v2becddf0k309d1e5246923915@mail.gmail.com>

Holy Apollo, stop this sillyness. THE NAME DOESN'T MATTER! People are
using TextIndexNG3 for Armstrongs sake. :-)


2009/7/17 Chris Withers <chris at simplistix.co.uk>:
> David Lyon wrote:
>>
>> On Fri, 17 Jul 2009 15:17:47 +0100, Chris Withers <chris at simplistix.co.uk>
>> wrote:
>>>
>>> packagetools yes, but we already have pkg_tools :-S
>>
>> packagetools is very easy to read, talks about 'packages' and
>> may be vaigely reminiscent to setuptools...
>
> packagetools or pypackaging would make me happy, if we can't get PJE to
> either allow us access to setuptools or if no-one has the guts to just use
> setuptools2 (which is exactly what this project is ;-) )
>
> I'm annoyed by the poll because it only had two crap options on it for the
> first majority of the votes. Tarek doesn't see this as a problem (because it
> sees 'distribute' stay as the project name) and is sure it's all fair
> because people can re-vote if they want to.
>
> So, if you voted and wanted something other than "distribute" or
> "redbarrel", please re-vote. If your option isn't there, please consider
> selecting the awkwardly named third column option.
>
> Myself, I'd prefer an option not on there, but I don't know what to do, if I
> change my vote, the only other option on the poll stands less chance of
> succeeding.
>
> Myself, I'd prefer setuptools2, packagetools, pypackaging, disttools,
> {anything else} in that order...
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? - http://www.simplistix.co.uk
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Fri Jul 17 16:59:01 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 16:59:01 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <79990c6b0907170754n552f84edwfafc8ae0d3e4f8f9@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<79990c6b0907170658r67a97189r4d7c8d7821ecd1ff@mail.gmail.com>
	<94bdd2610907170702o38171e69j79f4b221598d8928@mail.gmail.com>
	<79990c6b0907170754n552f84edwfafc8ae0d3e4f8f9@mail.gmail.com>
Message-ID: <319e029f0907170759t61dc6b81k1897a3d8e0fa49a2@mail.gmail.com>

2009/7/17 Paul Moore <p.f.moore at gmail.com>:
> Doesn't look like I can edit my vote. But OK to either Distribute or disttools.

The link is at the bottom.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From mihamina at gulfsat.mg  Fri Jul 17 18:01:02 2009
From: mihamina at gulfsat.mg (Rakotomandimby Mihamina)
Date: Fri, 17 Jul 2009 19:01:02 +0300
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <49583975633816029001522603707116473601-Webmail@me.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<49583975633816029001522603707116473601-Webmail@me.com>
Message-ID: <4A60A03E.1040408@gulfsat.mg>

07/17/2009 05:09 PM, Ronald Oussoren:
> I don't have an account at doodle and won't create one.

What made you think you need one?

-- 
                             Architecte Informatique:
    Administration Systeme, Recherche & Developpement
                                   + 261 32 11 401 65
Pensez a l'environnement avant d'imprimer ce message

From pje at telecommunity.com  Fri Jul 17 18:35:07 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 17 Jul 2009 12:35:07 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.co
 m>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
Message-ID: <20090717163204.A507B3A403A@sparrow.telecommunity.com>

At 04:53 PM 7/17/2009 +0200, Lennart Regebro wrote:
>2009/7/17 P.J. Eby <pje at telecommunity.com>:
> > Setuptools was something I originally wrote for common requirements in my
> > work projects...  then expanded into a funded project to provide Chandler
> > with a plugin infrastructure.  These days, I don't have time to code on the
> > projects I *enjoy* and *want* to code on...  and setuptools as it stands
> > today is not one of those projects.
>
>This is completely understandable, and a good reason not to work on
>it. The problem is that you simultaneously have prevented others to
>work on it,

False.  Jim Fulton has had commit privileges for ages (and has 
committed sizable chunks of code), and Ian Bicking would be equally 
welcome to them, if he asked.  (Ian contributed the Python 2.6 egg 
for the 0.6c9 release, and of course he pioneered support for 
Subversion and Sourceforge downloads in easy_install.)  And I'd 
seriously consider Philip Jenvey as well, as he's done a ton of 
Jython-compatibility work.

In other words, people I know and trust to be qualified for the job 
are quite free to maintain it.  If Jim or Ian wanted to "adopt" 
setuptools or become primary maintainers, I'd frankly jump at the opportunity!

Mainly, I trust Jim and Ian because they're thorough, cautious, and 
sensitive to "legacy" issues.  I know they're not going to go in and 
reverse years of policy until and unless they have a damn good 
understanding of both the old and the new requirements, and have a 
plan to address compatibility and migration.

(Hell, I'd also consider the folks at Enthought, who (like Jim and 
Ian) have built sizable systems atop setuptools and had to deal with 
a nice variety of end-user configuration quirks.  I would guess them 
to be equally requirements-educated and production-cautious.)

However, AFAIK, nobody qualified for the job of setuptools maintainer 
actually *wants* the position, myself included.  (This is not to say 
that such qualified persons do not exist, I'm just saying that I 
don't know of them at the moment.)

But lack of qualified volunteers is not me "preventing" anyone doing 
anything.  Obviously, I am not "preventing" anyone from forking it.


From hanno at hannosch.eu  Fri Jul 17 18:36:57 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 18:36:57 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
Message-ID: <5cae42b20907170936k13535f11sff6329c09e2021c3@mail.gmail.com>

Hi.

Following up on myself :)

We started to work on the documentation, added the basic Sphinx
infrastructure and added a new combined changelog which lists the
changes made in this fork.

Since we have forked the setuptools 0.6 branch, I have carefully
reviewed what changesets we missed from the setuptools trunk. Based on
this review I have merged a couple more bug-fixes and style changes to
our code. There are only a minor number of remaining differences to
the setuptools trunk, which are not appropriate for a maintenance
release. These are tracked at
http://bitbucket.org/tarek/distribute/issue/14.

In addition to the eight issues we have fixed so far, these are the
new additions we applied, solely based on the work from the original
contributers:

* Packages required at build time where not fully present at install
time. This closes http://bitbucket.org/tarek/distribute/issue/12.

* Avoid a call to /usr/bin/sw_vers on OSX and use the official
platform API instead. Based on a patch from ronaldoussoren. This
closes http://bitbucket.org/tarek/distribute/issue/5.

* Fixed a SandboxViolation for mkdir that could occur in certain
cases. This closes http://bitbucket.org/tarek/distribute/issue/13.

Hanno

From regebro at gmail.com  Fri Jul 17 18:42:37 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 18:42:37 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090717163204.A507B3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
Message-ID: <319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>

2009/7/17 P.J. Eby <pje at telecommunity.com>:
> At 04:53 PM 7/17/2009 +0200, Lennart Regebro wrote:
>>
>> 2009/7/17 P.J. Eby <pje at telecommunity.com>:
>> > Setuptools was something I originally wrote for common requirements in
>> > my
>> > work projects... ?then expanded into a funded project to provide
>> > Chandler
>> > with a plugin infrastructure. ?These days, I don't have time to code on
>> > the
>> > projects I *enjoy* and *want* to code on... ?and setuptools as it stands
>> > today is not one of those projects.
>>
>> This is completely understandable, and a good reason not to work on
>> it. The problem is that you simultaneously have prevented others to
>> work on it,
>
> False. ?Jim Fulton has had commit privileges for ages (and has committed
> sizable chunks of code), and Ian Bicking would be equally welcome to them,
> if he asked. ?(Ian contributed the Python 2.6 egg for the 0.6c9 release, and
> of course he pioneered support for Subversion and Sourceforge downloads in
> easy_install.) ?And I'd seriously consider Philip Jenvey as well, as he's
> done a ton of Jython-compatibility work.
>
> In other words, people I know and trust to be qualified for the job are
> quite free to maintain it. ?If Jim or Ian wanted to "adopt" setuptools or
> become primary maintainers, I'd frankly jump at the opportunity!
>
> Mainly, I trust Jim and Ian because they're thorough, cautious, and
> sensitive to "legacy" issues. ?I know they're not going to go in and reverse
> years of policy until and unless they have a damn good understanding of both
> the old and the new requirements, and have a plan to address compatibility
> and migration.
>
> (Hell, I'd also consider the folks at Enthought, who (like Jim and Ian) have
> built sizable systems atop setuptools and had to deal with a nice variety of
> end-user configuration quirks. ?I would guess them to be equally
> requirements-educated and production-cautious.)
>
> However, AFAIK, nobody qualified for the job of setuptools maintainer
> actually *wants* the position, myself included. ?(This is not to say that
> such qualified persons do not exist, I'm just saying that I don't know of
> them at the moment.)
>
> But lack of qualified volunteers is not me "preventing" anyone doing
> anything. ?Obviously, I am not "preventing" anyone from forking it.

This is an unreasonable position. You are adopting the position that
only the persons that you know do not have time to maintain it should
be allowed to do so, That has put us through a lot of unnecessary
pain, just because you are not willing to let go of something you no
longer are willing to maintain.

I which we somehow could get control over the setuptools name on PyPI.
Setuptools is dead, you are not interested in maintaining it, we
should in fact not need to rename it at all.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From santagada at gmail.com  Fri Jul 17 18:48:37 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Fri, 17 Jul 2009 13:48:37 -0300
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
Message-ID: <2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>

On Fri, Jul 17, 2009 at 1:42 PM, Lennart Regebro <regebro at gmail.com> wrote:

> y the persons that you know do not have time to maintain it should
> be allowed to do so, That has put us through a lot of unnecessary
> pain, just because you are not willing to let go of something you no
> longer are willing to maintain.
>
> I which we somehow could get control over the setuptools name on PyPI.
> Setuptools is dead, you are not interested in maintaining it, we
> should in fact not need to rename it at all.
>

Setuptools is dead, but the fork should be named something else just
to show that development doesn't have anything to do with the way
setuptools and is in fact a new and live project. People that were
burned by setuptools should give distribute a new chance.
What should happen is that distribute (or redbarrel or disttools)
should provide a distribute-setuptools package that is just a module
that import distribute and is transparent to other packages that want
to continue to "import setuptools".


-- 
Leonardo Santagada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090717/53ec38c6/attachment.htm>

From regebro at gmail.com  Fri Jul 17 18:54:39 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 18:54:39 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
	<2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
Message-ID: <319e029f0907170954v4976430bgef04d6d95d0b5b11@mail.gmail.com>

2009/7/17 Leonardo Santagada <santagada at gmail.com>:
> Setuptools?is?dead,?but?the?fork?should?be?named?something?else?just?to?show?that?development?doesn't?have?anything?to?do?with?the?way?setuptools?and?is?in?fact?a?new?and?live?project.?People?that?were?burned?by?setuptools?should?give?distribute?a?new?chance.

OK, that may be a valid standpoint.

> What?should?happen?is?that?distribute?(or?redbarrel?or?disttools)?should?provide?a?distribute-setuptools?package?that?is?just?a?module?that?import?distribute?and?is?transparent?to?other?packages?that?want?to?continue?to?"import?setuptools".

"import distribute as setuptools" isn't a very big change. I think
people can manage that one. ;)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Jul 17 19:28:02 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 17 Jul 2009 19:28:02 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090717163204.A507B3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
Message-ID: <94bdd2610907171028m62b9bd62l21a6a161bc7cbe50@mail.gmail.com>

On Fri, Jul 17, 2009 at 6:35 PM, P.J. Eby<pje at telecommunity.com> wrote:
> [...]
>
> However, AFAIK, nobody qualified for the job of setuptools maintainer
> actually *wants* the position, myself included. ?(This is not to say that
> such qualified persons do not exist, I'm just saying that I don't know of
> them at the moment.)
>
> But lack of qualified volunteers is not me "preventing" anyone doing
> anything. ?Obviously, I am not "preventing" anyone from forking it.

I don't buy that anymore. If you want to be a dictator you have to be
present in the
maintenance of the code. You're not anymore present, now you are
acting and talking like an old
despot that don't want to see his kingdom taken over by the people ;)

More seriously, if you think people like me or Hanno are not qualified
enough to fix dumb-stupid bugs like
the svn 1.6 compatibility stuff, or do releases, that's your problem.

Also, you spend enough time in the mailing lists to be able to drive
us to do the "right"  things,
so, I don't buy what you are saying about being "blessed" (being Ian
or Jim). No offense, but I wouldn't bless *you*
in any of my projects with you anti-PEP 8 coding style ;)

But anyway, let the fork be, I trust all these "unqualified" people
that are part of it. Most of them
have released many big large-scale applications and are very good.

Cheers
Tarek

From pje at telecommunity.com  Fri Jul 17 19:40:11 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 17 Jul 2009 13:40:11 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.co
 m>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
Message-ID: <20090717173711.C15063A403A@sparrow.telecommunity.com>

At 06:42 PM 7/17/2009 +0200, Lennart Regebro wrote:
>This is an unreasonable position. You are adopting the position that
>only the persons that you know do not have time to maintain it should
>be allowed to do so,

You seem to be confused.  I'm only talking about the setuptools 
*primary maintainer* role.  If said primary maintainer wants to have 
a more open patch policy, that'd be their business.  (Heck, I'd grant 
the role to a *team* of qualified volunteers, if it cut down the load 
for said volunteers.)

I've also laid out criteria -- both in the email you're replying to, 
and in the past -- for what would make me consider someone for the 
role of a primary maintainer.

That nobody has stepped forward doesn't make me unreasonable, it 
means there's a lack of qualified and interested volunteers for that position.

I'm not saying that nobody but Jim and Ian and Philip contribute good 
patches; maybe half the patches I get are basically good.  But 
*reviewing* those patches, rejecting the ones that should be 
rejected, and hardest of all, coming up with good ways to actually 
move the codebase forward, are the tasks that need more-qualified (by 
my previously-stated definition) volunteers.


>  That has put us through a lot of unnecessary
>pain, just because you are not willing to let go of something you no
>longer are willing to maintain.

Who said I'm not willing to maintain it?  All I said is that it's not 
very high on my priorities for *unpaid* programming projects.  That 
means that stuff tends to get fixed only when it interferes with me 
personally getting something done.


>Setuptools is dead,

Nope, is's only resting.  ;-)  At some point it'll move again.


>you are not interested in maintaining it,

Which should not be confused with me not having an *interest* in 
maintaining it.  (Which is why the name only goes to a qualified 
replacement figurehead.)


From pje at telecommunity.com  Fri Jul 17 19:48:58 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 17 Jul 2009 13:48:58 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907171028m62b9bd62l21a6a161bc7cbe50@mail.gmail.co
 m>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<94bdd2610907171028m62b9bd62l21a6a161bc7cbe50@mail.gmail.com>
Message-ID: <20090717174554.89DBA3A403A@sparrow.telecommunity.com>

At 07:28 PM 7/17/2009 +0200, Tarek Ziad? wrote:
>On Fri, Jul 17, 2009 at 6:35 PM, P.J. Eby<pje at telecommunity.com> wrote:
> > [...]
> >
> > However, AFAIK, nobody qualified for the job of setuptools maintainer
> > actually *wants* the position, myself included.  (This is not to say that
> > such qualified persons do not exist, I'm just saying that I don't know of
> > them at the moment.)
> >
> > But lack of qualified volunteers is not me "preventing" anyone doing
> > anything.  Obviously, I am not "preventing" anyone from forking it.
>
>I don't buy that anymore. If you want to be a dictator you have to be
>present in the
>maintenance of the code. You're not anymore present, now you are
>acting and talking like an old
>despot that don't want to see his kingdom taken over by the people ;)

Eh?  I encourage the fork.  I only don't want it called 
setuptools.  Call it the People's Republic of Setuptools or something.  ;-)


>More seriously, if you think people like me or Hanno are not qualified
>enough to fix dumb-stupid bugs like
>the svn 1.6 compatibility stuff, or do releases, that's your problem.

As I said, at least half the patches I get are good.  Knowing *which* 
half is the part that has tougher qualifications.  ;-)


>Also, you spend enough time in the mailing lists to be able to drive
>us to do the "right"  things,

I don't intend to spend a lot of time on that for the fork, actually, 
at least not on an unsolicited basis.


>so, I don't buy what you are saying about being "blessed" (being Ian
>or Jim).

I don't get what you mean by this.


From hanno at hannosch.eu  Fri Jul 17 21:35:20 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 21:35:20 +0200
Subject: [Distutils] Distribute - issue tracker
Message-ID: <5cae42b20907171235u7aaa7921kd79b9a4fd5f8b17@mail.gmail.com>

Hi there.

In order to not disrupt the setuptools project in any way, we have
chosen to have our own issue tracker at
http://bitbucket.org/tarek/distribute/issues and mirror issues
instead. We felt that comments like "this is fixed in Distribute -
come join us" are inappropriate to leave in the setuptools tracker ;-)

Obviously this leaves us with a synchronization problem. We already do
have a new issue and comments on issues which are unique in our own
tracker. For now I've used a stupid low-tech approach and manually
created a Wiki page at
http://bitbucket.org/tarek/distribute/wiki/bug_listing which lists our
own issues and their relations to the setuptools issue tracker. This
is of course in addition to a comment on each issue explaining its
origin.

If someone has a better idea on how to synchronize these trackers or
can provide insight in proven techniques for forks in this way, please
speak up. Otherwise I'm going to continue to manually mirror all
issues over from the setuptools tracker into our own.

Cheers,
Hanno

From hanno at hannosch.eu  Fri Jul 17 21:51:43 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 21:51:43 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090717174554.89DBA3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<94bdd2610907171028m62b9bd62l21a6a161bc7cbe50@mail.gmail.com>
	<20090717174554.89DBA3A403A@sparrow.telecommunity.com>
Message-ID: <5cae42b20907171251p6e21c008q962ee367aa249d08@mail.gmail.com>

Hi.

On Fri, Jul 17, 2009 at 7:48 PM, P.J. Eby<pje at telecommunity.com> wrote:
> Eh? ?I encourage the fork. ?I only don't want it called setuptools. ?Call it
> the People's Republic of Setuptools or something. ?;-)

Thank you!

Judging by the current vote outcome and the interest of the people
actually doing the work on this right now, I think we'll call it
Distribute - driven by the Fellowship of the Packaging. There needs to
be some silliness involved ;-)

> As I said, at least half the patches I get are good. ?Knowing *which* half
> is the part that has tougher qualifications. ?;-)

Sure. Bug management that only consists of applying well tested and
thought out patches wouldn't be any fun. I made my choices of which
bugs and patches to accept, as seen from my progress report. Obviously
I left out all the hard ones for now.

> I don't intend to spend a lot of time on that for the fork, actually, at
> least not on an unsolicited basis.

I hope we will be able to get some more productive and constructive
discussions than the usual heated debates we see on this list. It's
good to know that you are in principe willing to share your expertise
with us.

Thanks,
Hanno

From sridharr at activestate.com  Fri Jul 17 22:04:21 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 17 Jul 2009 13:04:21 -0700
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <94bdd2610907170541l41fc5877l170d682d99c54391@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>
	<5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
	<94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
	<5cae42b20907170303v208ba308q7d9fd872839bafd8@mail.gmail.com>
	<94bdd2610907170541l41fc5877l170d682d99c54391@mail.gmail.com>
Message-ID: <op.uw791jwr1q4jlt@whymac>

On Fri, 17 Jul 2009 05:41:32 -0700, Tarek Ziad? <ziade.tarek at gmail.com>  
wrote:

> D- good practices in recipes

+1 on this.

In fact, I'd suggest including a Paste template that will create a sample  
project with setup.py in it that makes use of these good practices such as  
using ``pkg_resource.resource_string`` to read README, version, etc..

-srid

From hanno at hannosch.eu  Fri Jul 17 22:05:08 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Fri, 17 Jul 2009 22:05:08 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
	<2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
Message-ID: <5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.com>

On Fri, Jul 17, 2009 at 6:48 PM, Leonardo Santagada<santagada at gmail.com> wrote:
> Setuptools?is?dead,?but?the?fork?should?be?named?something?else?just?to?show?that?development?doesn't?have?anything?to?do?with?the?way?setuptools?and?is?in?fact?a?new?and?live?project.?People?that?were?burned?by?setuptools?should?give?distribute?a?new?chance.

As with every OS project our fork will need to better define what
exactly it wants to achieve.

I will just say that I wholeheartedly disagree with the underlying
notion of the above statement.

I think setuptools is by and large a huge success and has pushed
package management in Python to a new level.  What we need is ongoing
maintenance and very careful evolution of it. Package management is no
place to go crazy and fancy. We will need to carefully look at what we
want to do and how we do it after some of the early strong emotional
reactions have settled down.

Anyone who wants to rewrite setuptools from scratch or thinks
"easy_install must die" probably will be very disappointed by the
distribute fork.

Hanno

From regebro at gmail.com  Fri Jul 17 23:18:31 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 17 Jul 2009 23:18:31 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked everything up.
Message-ID: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>

OK, not a good start. I haven't used mercurial for long and I already hate it.

I checked in the Python 3 support, which for some reason made the new
python3 branch the main active branch. Which of course wasn't the
intention. Also, an earlier name of the branch got added. I want that
removed.

Somebody is welcome to tell me how to fix this. I have no idea, and
mercurial documentation doesn't help (and in fact gave absolutely no
hint that this would happen).

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From hanno at hannosch.eu  Sat Jul 18 01:14:56 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sat, 18 Jul 2009 01:14:56 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
Message-ID: <5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>

On Fri, Jul 17, 2009 at 11:18 PM, Lennart Regebro<regebro at gmail.com> wrote:
> I checked in the Python 3 support, which for some reason made the new
> python3 branch the main active branch. Which of course wasn't the
> intention. Also, an earlier name of the branch got added. I want that
> removed.

Thanks for the Python 3 support work.

I've cleaned up your commits a bit. The "regebro-python3" branch is
now marked as closed and merged into the "python3" branch. I've also
made a new commit on the setuptools-0.6 branch to create a proper
second head again. We are back at two active branches and
corresponding heads as shown at
http://bitbucket.org/tarek/distribute/changesets/.

Hanno

From pje at telecommunity.com  Sat Jul 18 02:05:44 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 17 Jul 2009 20:05:44 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.co
 m>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
	<2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
	<5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.com>
Message-ID: <20090718000240.C42273A403A@sparrow.telecommunity.com>

At 10:05 PM 7/17/2009 +0200, Hanno Schlichting wrote:
>We will need to carefully look at what we want to do and how we do 
>it after some of the early strong emotional reactions have settled 
>down. Anyone who wants to rewrite setuptools from scratch or thinks 
>"easy_install must die" probably will be very disappointed by the 
>distribute fork.

I'm glad to hear it; that makes it *much* more likely that I will 
simply bless some version of your package as the "official" 
setuptools 0.6 "final" series, and merge it back into my trunk 
whenever I get around to working on the 0.7 versions.  (Which might 
even happen sooner if somebody else is keeping 0.6 fed  and 
watered... thereby decreasing the "work factor" for me.)

(Btw, I'm not sure if you really want to drop entry-points.txt from 
revision control, since ISTM a fresh checkout will not be able to run 
egg_info and rebuild it, unless you also add a hack to 
Distribution.get_command_class() so it (and any other setuptools 
commands it relies upon) can be found.  If it seems to be working 
as-is, my guess is it's because an already-elsewhere-installed 
setuptools version on sys.path is providing the glue by way of *its* 
entry-points.txt.  Try it and see!)


From ben+python at benfinney.id.au  Sat Jul 18 02:40:45 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 10:40:45 +1000
Subject: [Distutils] Who could be lead developer? (was: Colour this
	bikeshed: Name for setuptools fork)
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
Message-ID: <878wimesc2.fsf_-_@benfinney.id.au>

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

> However, AFAIK, nobody qualified for the job of setuptools maintainer
> actually *wants* the position, myself included. (This is not to say
> that such qualified persons do not exist, I'm just saying that I don't
> know of them at the moment.)

Since there are people who have demonstrated significant desire to
continue development of setuptools ? heck, they're organising a fork of
it solely because they want its development to proceed ? the ?wants to?
criterion is evidently satisfied.

So I can only interpret the above as saying that those who have
demonstrated that they want to, are not qualified.

Is that what you're saying? If not, what *are* you saying?

> But lack of qualified volunteers is not me "preventing" anyone doing
> anything.

You are preventing people from continuing development of setuptools *as
setuptools*. That's the main complaint I'm seeing in this discussion,
and your explanation in this latest message reinforces that.

You may have good justification for preventing people from doing that,
but I wish you'd acknowledge that this *is* preventing people from doing
something they've expressed a clear desire to do.

> Obviously, I am not "preventing" anyone from forking it.

Forking is the option of last resort. It's good that we *have* that
option ? heck, it's one of the main reasons to prefer free software ?
but it's far less preferable than continuance of the project under the
same banner.

-- 
 \      ?It's up to the masses to distribute [music] however they want |
  `\    ? The laws don't matter at that point. People sharing music in |
_o__)        their bedrooms is the new radio.? ?Neil Young, 2008-05-06 |
Ben Finney


From ben+python at benfinney.id.au  Sat Jul 18 02:50:20 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 10:50:20 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<94bdd2610907171028m62b9bd62l21a6a161bc7cbe50@mail.gmail.com>
	<20090717174554.89DBA3A403A@sparrow.telecommunity.com>
	<5cae42b20907171251p6e21c008q962ee367aa249d08@mail.gmail.com>
Message-ID: <874otaerw3.fsf@benfinney.id.au>

Hanno Schlichting <hanno at hannosch.eu> writes:

> Judging by the current vote outcome and the interest of the people
> actually doing the work on this right now, I think we'll call it
> Distribute

I will register again that the name ?Distribute? is terrible for this
project: it will make searching for the project too difficult. The name
should quickly become the first hit when searching the web for ?python
name_of_the_project?, and ?Distribute? is not and should not be that.

When a person, ignorant of any particular means of distributing Python
code, goes searching for ?how do I distribute Python stuff?? they will
likely be searching for terms including ?python distribute?. This will
return lots of hits about things *that are not this project*, and that's
the way it should be.

The project name should be chosen so that it doesn't compete with the
general search for ?python distribute? or ?python packaging? or
anything similar. It should be unique enough to quickly differentiate
itself from the general topic search.

Any of ?Red Barrel? or ?distutils? or countless other names would be
better in this regard.

-- 
 \        ?Intellectual property is to the 21st century what the slave |
  `\                              trade was to the 16th.? ?David Mertz |
_o__)                                                                  |
Ben Finney


From ben+python at benfinney.id.au  Sat Jul 18 02:54:15 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 10:54:15 +1000
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked everything up.
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
Message-ID: <87zlb2dd54.fsf@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> OK, not a good start. I haven't used mercurial for long and I already
> hate it.

Welcome to the club :-(

It's sad that, at my workplace, the ideological battle between Bazaar
and Darcs means that Mercurial was chosen (perhaps because it's equally
irritating to everyone). The user experience has not improved with
experience.

-- 
 \       ?If you are unable to leave your room, expose yourself in the |
  `\            window.? ?instructions in case of fire, hotel, Finland |
_o__)                                                                  |
Ben Finney


From santagada at gmail.com  Sat Jul 18 03:16:00 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Fri, 17 Jul 2009 22:16:00 -0300
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
	<2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
	<5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.com>
Message-ID: <09E5DDC2-1CBE-439F-AE97-3AEE040B94C7@gmail.com>


On Jul 17, 2009, at 5:05 PM, Hanno Schlichting wrote:

> On Fri, Jul 17, 2009 at 6:48 PM, Leonardo Santagada<santagada at gmail.com 
> > wrote:
>> Setuptools is dead, but the fork should be named something else  
>> just to show that development doesn't have anything to do with the  
>> way setuptools and is in fact a new and live project. People that  
>> were burned by setuptools should give distribute a new chance.
>
> As with every OS project our fork will need to better define what
> exactly it wants to achieve.
>
> I will just say that I wholeheartedly disagree with the underlying
> notion of the above statement.
>
> I think setuptools is by and large a huge success and has pushed
> package management in Python to a new level.  What we need is ongoing
> maintenance and very careful evolution of it. Package management is no
> place to go crazy and fancy. We will need to carefully look at what we
> want to do and how we do it after some of the early strong emotional
> reactions have settled down.
>
> Anyone who wants to rewrite setuptools from scratch or thinks
> "easy_install must die" probably will be very disappointed by the
> distribute fork.

What I meant is that the pace that setuptools took in the last 9 or so  
months is over, and people that sent patches only to see them rot on  
the issue tracker should look at distribute as a place to try again.  
For example people that were using svn 1.6 just to see setuptools  
failing and never be fixed should feel safe again knowing that if a  
new version of their favorite scm comes along someone (even oneself)  
will patch it to work and not be forced to work with an older version  
because of setuptools.

The bit about easy_install is more about its terrible user interface  
(ok command line user interface) and it messing around syspath than  
any of its other features.

What I would like to see to easy_install would be progress meters on  
downloads, simpler way to tell it by default not to mess with sys.path  
and maybe atomic installs where it would either install all packages  
that you asked or none.

--
Leonardo Santagada
santagada at gmail.com




From ben+python at benfinney.id.au  Sat Jul 18 03:33:40 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 11:33:40 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<94bdd2610907171028m62b9bd62l21a6a161bc7cbe50@mail.gmail.com>
	<20090717174554.89DBA3A403A@sparrow.telecommunity.com>
	<5cae42b20907171251p6e21c008q962ee367aa249d08@mail.gmail.com>
	<874otaerw3.fsf@benfinney.id.au>
Message-ID: <87r5wedbbf.fsf@benfinney.id.au>

Ben Finney <ben+python at benfinney.id.au> writes:

> Any of ?Red Barrel? or ?distutils? or countless other names would be
> better in this regard.

s/distutils/disttools/ of course (which demonstrates perhaps a reason
not to prefer that name :-)

-- 
 \       ?Pinky, are you pondering what I'm pondering?? ?Well, I think |
  `\   so, Brain, but it's a miracle that this one grew back.? ?_Pinky |
_o__)                                                   and The Brain_ |
Ben Finney


From david.lyon at preisshare.net  Sat Jul 18 03:32:58 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 17 Jul 2009 21:32:58 -0400
Subject: [Distutils]
 =?utf-8?q?Who_could_be_lead_developer=3F_=28was=3A_Co?=
 =?utf-8?q?lour_this_bikeshed=3A_Name_for_setuptools_fork=29?=
In-Reply-To: <878wimesc2.fsf_-_@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<878wimesc2.fsf_-_@benfinney.id.au>
Message-ID: <44b53cc3ecf36da68ee941f6e746ba47@preisshare.net>

> "P.J. Eby" <pje at telecommunity.com> writes:
 
> However, AFAIK, nobody qualified for the job of setuptools maintainer
> actually *wants* the position, myself included. (This is not to say
> that such qualified persons do not exist, I'm just saying that I don't
> know of them at the moment.)

I don't know what your expectations of qualifications are exactly.

But I can guess that basically you want somebody that understands
packaging and somebody that doesn't want to hack your code to
pieces so that you lose control of it. This is perfectly fair
and reasonable.

The person needs to accept that the coding style "should'nt'
change. Which actually I do. In any software project, you
should have only one coding stuff - whether it is right or
wrong.

In my job, I actually do some sysadmin for, can you believe
a dBase-IV system. There's an old guy there who "did everything"
and everybody tries to dislodge him because everything is "old".

But he signs the cheques for my invoices.. haha and what
that means is that help him keep his dBase-IV system alive
15 yrears after everybody says it should have died.

My point is that to a large degree, setuptools is now a
legacy system. I'm a professional legacy system maintainer.

For setuptools, If I was given the job as temporary maintainer,
I would have no intentions to introduce any new features..
(instead leaving that for the author), or make any significant
changes.

The only job would be to apply patches.. perphaps changing
the coding style into the "original" style.

Maintaining something like setuptools is like changing the
oil and keeping air in the tyres.

By not allowing maintainance (or only allowing people that
don't have the time to do it), there will be no oil changes
and no air in the tyres. The predictable outcome is going to
be that the machinery is heading for a major seizure.

$25 worth of oil could have prevented it...

Maybe there are bargain-hunters who want to take over
setuptools for the price of $25.. but I'm not one of them.

Rather, we have $25 that we want to give for oil so
we can keep having rides on the machine and so that
it doesn't die...

David

(ps - to keep an old car in the garage, if you want
the motor not to sieze, you still have to change the
oil and let it run for ten minutes every month or
so.)






> 
> Since there are people who have demonstrated significant desire to
> continue development of setuptools ? heck, they're organising a fork of
> it solely because they want its development to proceed ? the ?wants
> to?
> criterion is evidently satisfied.
> 
> So I can only interpret the above as saying that those who have
> demonstrated that they want to, are not qualified.
> 
> Is that what you're saying? If not, what *are* you saying?
> 
>> But lack of qualified volunteers is not me "preventing" anyone doing
>> anything.
> 
> You are preventing people from continuing development of setuptools *as
> setuptools*. That's the main complaint I'm seeing in this discussion,
> and your explanation in this latest message reinforces that.
> 
> You may have good justification for preventing people from doing that,
> but I wish you'd acknowledge that this *is* preventing people from doing
> something they've expressed a clear desire to do.
> 
>> Obviously, I am not "preventing" anyone from forking it.
> 
> Forking is the option of last resort. It's good that we *have* that
> option ? heck, it's one of the main reasons to prefer free software ?
> but it's far less preferable than continuance of the project under the
> same banner.

From greg.ewing at canterbury.ac.nz  Sat Jul 18 03:40:27 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 18 Jul 2009 13:40:27 +1200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <878winhcny.fsf_-_@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5F3733.8050604@simplistix.co.uk>
	<ca816810907160736n72b5afefy5ce8d9e77a865c53@mail.gmail.com>
	<94bdd2610907160749j7dd22c68t5807b3cb5aae0f7a@mail.gmail.com>
	<e5fff6640907160802p1a5a0d68r76dc4a27bc01c4dd@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz> <878winhcny.fsf_-_@benfinney.id.au>
Message-ID: <4A61280B.6000309@canterbury.ac.nz>

Ben Finney wrote:

> Also, there never really was a ?setuptools 1?. I think it's only going
> to be confusing to call this ?setuptools 2?.

Return of Setuptools?

Revenge of the Setuptools?

Setuptools Strikes Back?

-- 
Greg

From greg.ewing at canterbury.ac.nz  Sat Jul 18 04:21:15 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 18 Jul 2009 14:21:15 +1200
Subject: [Distutils] Announcing the 'Distribute' project
In-Reply-To: <87ab33fmhg.fsf@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
	<87ab33fmhg.fsf@benfinney.id.au>
Message-ID: <4A61319B.9060307@canterbury.ac.nz>

Ben Finney wrote:

> Fails the web search test: a search for ?python packaging? will not
> find this project specifically.

The same criticism probably applies to "distribute", which
seems to be ahead in the poll right now.

-- 
Greg


From ben+python at benfinney.id.au  Sat Jul 18 04:25:38 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 12:25:38 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
Message-ID: <87my72d8wt.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> Ok I'll act a bit like a dictactor for this ;)

I think that would be an excellent idea. A dictator would consider all
the arguments, and *declare* the name, knowing they would be responsible
for the consequences of that decision.

> here's a Poll with the two finalists

Huh? A dictatorship doesn't involve a poll. A poll is what you use when
you don't want responsibility for the decision. Or are you saying the
results of the poll don't matter?

-- 
 \      ?I guess we were all guilty, in a way. We all shot him, we all |
  `\   skinned him, and we all got a complimentary bumper sticker that |
_o__)                         said, ?I helped skin Bob.?? ?Jack Handey |
Ben Finney


From chrism at plope.com  Sat Jul 18 04:37:18 2009
From: chrism at plope.com (Chris McDonough)
Date: Fri, 17 Jul 2009 22:37:18 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <87my72d8wt.fsf@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>	<878winhcny.fsf_-_@benfinney.id.au>	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>	<87r5wffsdz.fsf@benfinney.id.au>	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>	<4A607BF3.8060908@gulfsat.mg>	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au>
Message-ID: <4A61355E.50706@plope.com>

I'd be quite happy if Tarek ignored the meta-drivel in this thread and made some 
checkins, even if the project was named the empty string.  You gotta realize 
that fielding all these bikeshed emails takes a lot of time; if it gets named 
"distribute" or one of the two options from the poll, so be it.  Give the poor 
man a mail-responding rest. ;-)  There's all of eternity to bikeshed the name 
after the first release, but a release is required for there to be anything to 
bikeshed about.

- C

On 7/17/09 10:25 PM, Ben Finney wrote:
> Tarek Ziad?<ziade.tarek at gmail.com>  writes:
>
>> Ok I'll act a bit like a dictactor for this ;)
>
> I think that would be an excellent idea. A dictator would consider all
> the arguments, and *declare* the name, knowing they would be responsible
> for the consequences of that decision.
>
>> here's a Poll with the two finalists
>
> Huh? A dictatorship doesn't involve a poll. A poll is what you use when
> you don't want responsibility for the decision. Or are you saying the
> results of the poll don't matter?
>


From ben+python at benfinney.id.au  Sat Jul 18 05:47:07 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 13:47:07 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
Message-ID: <87eised550.fsf@benfinney.id.au>

Chris McDonough <chrism at plope.com> writes:

> You gotta realize that fielding all these bikeshed emails takes a lot
> of time; if it gets named "distribute" or one of the two options from
> the poll, so be it.  Give the poor man a mail-responding rest. ;-)

Agreed.

> There's all of eternity to bikeshed the name after the first release,
> but a release is required for there to be anything to bikeshed about.

I couldn't disagree more. Discussing the name *after* release will be
even less useful because it's so much more difficult to actually change
it at that point.

A project name, once it becomes established through use (even well
before a release happens) is very difficult to change effectively.
That's a big reason I see to choose a least-worst name long before that
happens.

I do agree, though, with letting the appointed dictator take the weight
of that decision and giving him the breathing room to do so. In that
spirit, I'll let my objections stand and not re-raise them unsolicited.

-- 
 \          ?I hope if dogs ever take over the world, and they chose a |
  `\    king, they don't just go by size, because I bet there are some |
_o__)                   Chihuahuas with some good ideas.? ?Jack Handey |
Ben Finney


From greg.ewing at canterbury.ac.nz  Sat Jul 18 05:55:12 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 18 Jul 2009 15:55:12 +1200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <87my72d8wt.fsf@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz> <878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au>
Message-ID: <4A6147A0.1040602@canterbury.ac.nz>

Ben Finney wrote:

> Huh? A dictatorship doesn't involve a poll.

Nonsense, it's perfectly legitimate dictatorial
behaviour to have a poll - you just have to make
sure you know what the result will be. :-)

(Of course it's a good idea to first check that you
have enough security forces on hand to suppress the
following popular uprising.)

-- 
Greg

From ben+python at benfinney.id.au  Sat Jul 18 05:51:37 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 13:51:37 +1000
Subject: [Distutils] Announcing the 'Distribute' project
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<op.uw6xv2ev1q4jlt@whymac.activestate.com>
	<94bdd2610907170117x6cac58d1nfdbe0ff43363068a@mail.gmail.com>
	<9a5612039cb3991de00ae32bce93975d@preisshare.net>
	<87ab33fmhg.fsf@benfinney.id.au>
	<4A61319B.9060307@canterbury.ac.nz>
Message-ID: <87ab32d4xi.fsf@benfinney.id.au>

Greg Ewing <greg.ewing at canterbury.ac.nz> writes:

> Ben Finney wrote:
> 
> > Fails the web search test: a search for ?python packaging? will
> > not find this project specifically.
> 
> The same criticism probably applies to "distribute", which
> seems to be ahead in the poll right now.

I can only interpret that as (a) a sign that people just want whatever
is the status quo and don't really care about arguments against; and (b)
deciding the name is probably best done by an individual who has
considered the options rather than a poll.

-- 
 \       ?They can not take away our self respect if we do not give it |
  `\                                         to them.? ?Mahatma Gandhi |
_o__)                                                                  |
Ben Finney


From chrism at plope.com  Sat Jul 18 06:50:56 2009
From: chrism at plope.com (Chris McDonough)
Date: Sat, 18 Jul 2009 00:50:56 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <87eised550.fsf@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>	<878winhcny.fsf_-_@benfinney.id.au>	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>	<87r5wffsdz.fsf@benfinney.id.au>	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>	<4A607BF3.8060908@gulfsat.mg>	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>	<87my72d8wt.fsf@benfinney.id.au>
	<4A61355E.50706@plope.com> <87eised550.fsf@benfinney.id.au>
Message-ID: <4A6154B0.6000707@plope.com>

On 7/17/09 11:47 PM, Ben Finney wrote:
> Chris McDonough<chrism at plope.com>  writes:
>
>> You gotta realize that fielding all these bikeshed emails takes a lot
>> of time; if it gets named "distribute" or one of the two options from
>> the poll, so be it.  Give the poor man a mail-responding rest. ;-)
>
> Agreed.
>
>> There's all of eternity to bikeshed the name after the first release,
>> but a release is required for there to be anything to bikeshed about.
>
> I couldn't disagree more. Discussing the name *after* release will be
> even less useful because it's so much more difficult to actually change
> it at that point.

Note that the primary package name that the "distribute" distribution embeds is 
still named "setuptools" at this point, for better or worse.  I don't know how 
long this will be true, but it's still true right now, and I suspect it won't 
change before the first release.  That may be another can of worms, but at this 
point it's probably not worth losing any sleep over.

In any case, changing the distribution name ("distribute" currently) is pretty 
trivial in comparison to changing a package name because imports don't need to 
change.  I'd begin to get more nervous when the package names change. ;-)

- C

From ben+python at benfinney.id.au  Sat Jul 18 07:19:01 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 18 Jul 2009 15:19:01 +1000
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
Message-ID: <871voed0vu.fsf@benfinney.id.au>

Chris McDonough <chrism at plope.com> writes:

> In any case, changing the distribution name ("distribute" currently)
> is pretty trivial in comparison to changing a package name because
> imports don't need to change.

Quite the opposite is true in my experience. Computers are our willing
slaves; if we tell them sternly that an object is henceforth to be known
by a different name, they will use that name unquestioningly, and won't
get the two names confused.

People's usage of names, though, is far less easy to change. Once the
project is discussed consistently by a particular name, that name will
stick around for better or worse for a *very* long time. To deny this
reality and hastily choose a bad name is a foolish move, precisely
because it is so predictable for the name to stick indelibly once
chosen.

-- 
 \          ?All good things are cheap; all bad are very dear.? ?Henry |
  `\                                                     David Thoreau |
_o__)                                                                  |
Ben Finney


From regebro at gmail.com  Sat Jul 18 08:20:12 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 08:20:12 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
Message-ID: <319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>

2009/7/18 Hanno Schlichting <hanno at hannosch.eu>:
> On Fri, Jul 17, 2009 at 11:18 PM, Lennart Regebro<regebro at gmail.com> wrote:
>> I checked in the Python 3 support, which for some reason made the new
>> python3 branch the main active branch. Which of course wasn't the
>> intention. Also, an earlier name of the branch got added. I want that
>> removed.
>
> Thanks for the Python 3 support work.
>
> I've cleaned up your commits a bit. The "regebro-python3" branch is
> now marked as closed and merged into the "python3" branch. I've also
> made a new commit on the setuptools-0.6 branch to create a proper
> second head again. We are back at two active branches and
> corresponding heads as shown at
> http://bitbucket.org/tarek/distribute/changesets/.

OK, great, thanks!
(The regebro-python3 branch is still visible though, which is
unfortunate, and I of course still have no idea what I did wrong.)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Sat Jul 18 08:36:02 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 08:36:02 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
Message-ID: <319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>

2009/7/18 Lennart Regebro <regebro at gmail.com>:
> OK, great, thanks!
> (The regebro-python3 branch is still visible though, which is
> unfortunate, and I of course still have no idea what I did wrong.)

And, when you make a new clone, you get the python3-branch, not the
setuptools-0.6 branch, which you are supposed to.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Sat Jul 18 09:01:00 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 09:01:00 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
Message-ID: <319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>

Annnd... Hannos fixes now means it somehow broke completely.

I think I give up.


The best path forward right now seems to me to completely delete the
branches, including from history, which is possible in Mercurial,
assuming everybody recreated their clones afterwards, apparently.

I then make the changes again. Don't commit them anywhere, but send
them to somebody who checks them into a branch, the correct way.

I do not have the time to fight with a brain-dead VCS.

2009/7/18 Lennart Regebro <regebro at gmail.com>:
> 2009/7/18 Lennart Regebro <regebro at gmail.com>:
>> OK, great, thanks!
>> (The regebro-python3 branch is still visible though, which is
>> unfortunate, and I of course still have no idea what I did wrong.)
>
> And, when you make a new clone, you get the python3-branch, not the
> setuptools-0.6 branch, which you are supposed to.
>
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
>



-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From kevin at bud.ca  Sat Jul 18 10:25:33 2009
From: kevin at bud.ca (Kevin Teague)
Date: Sat, 18 Jul 2009 01:25:33 -0700
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <87my72d8wt.fsf@benfinney.id.au>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au>
Message-ID: <F6C6826A-7E28-4988-A9BF-D24337D5291C@bud.ca>


On Jul 17, 2009, at 7:25 PM, Ben Finney wrote:

> Tarek Ziad? <ziade.tarek at gmail.com> writes:
>
>> here's a Poll with the two finalists
>
> Huh? A dictatorship doesn't involve a poll.
>

Exactly! A *true* dictator would write something like:

"Enough is enough! The project shall now and forever be knwon as  
'tarektools'. Do not bother wasting your time objecting, as I am no  
longer going to respond to this thread."


From regebro at gmail.com  Sat Jul 18 11:07:45 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 11:07:45 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <F6C6826A-7E28-4988-A9BF-D24337D5291C@bud.ca>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au>
	<F6C6826A-7E28-4988-A9BF-D24337D5291C@bud.ca>
Message-ID: <319e029f0907180207q37978b3fj37ebc9ace9be367f@mail.gmail.com>

I'm also extremely upset that none of the following options were not
present in the poll:

awesometools: Best name suggested so far.
cheesecloth: Because it's what you have cheese in.
dinsdale: A Monthy Python reference that has nothing to do with packaging.
tzat: Tarek Ziad?s Awesome Tools. Never mind everybody will think it
has to do with timezones.
distsetuputiltools: Because its what it is.
packaging.tools.setup.distribute: Because namespaces are awesome.
bikesheddingNG: So people know where the important discussions lie.

2009/7/18 Kevin Teague <kevin at bud.ca>:
>
> On Jul 17, 2009, at 7:25 PM, Ben Finney wrote:
>
>> Tarek Ziad? <ziade.tarek at gmail.com> writes:
>>
>>> here's a Poll with the two finalists
>>
>> Huh? A dictatorship doesn't involve a poll.
>>
>
> Exactly! A *true* dictator would write something like:
>
> "Enough is enough! The project shall now and forever be knwon as
> 'tarektools'. Do not bother wasting your time objecting, as I am no longer
> going to respond to this thread."
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From p.f.moore at gmail.com  Sat Jul 18 11:23:15 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 18 Jul 2009 10:23:15 +0100
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
Message-ID: <79990c6b0907180223k55336527sbeb51898ad64652d@mail.gmail.com>

2009/7/18 Lennart Regebro <regebro at gmail.com>:
> 2009/7/18 Lennart Regebro <regebro at gmail.com>:
>> OK, great, thanks!
>> (The regebro-python3 branch is still visible though, which is
>> unfortunate, and I of course still have no idea what I did wrong.)
>
> And, when you make a new clone, you get the python3-branch, not the
> setuptools-0.6 branch, which you are supposed to.

I'm not familiar with the structure of the repository, and I don't
want to start a "how to use Mercurial" thread here, but it sounds to
me like the issue may be that you're using named branches - which to
me seem like an "advanced" and somewhat difficult to use feature.

I'd recommend using separate clones for branching.
Paul.

From hanno at hannosch.eu  Sat Jul 18 11:39:29 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sat, 18 Jul 2009 11:39:29 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
Message-ID: <5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>

On Sat, Jul 18, 2009 at 9:01 AM, Lennart Regebro<regebro at gmail.com> wrote:
> The best path forward right now seems to me to completely delete the
> branches, including from history, which is possible in Mercurial,
> assuming everybody recreated their clones afterwards, apparently.

I don't see the problem. Note that branches in Mercurial are quite
different from branches in SVN. Also typical SVN-style use might not
be appropriate for Mercurial. I'm myself using this only for a very
short time, so I'm in no position to lecture people about anything
here.

But looking at http://bitbucket.org/tarek/distribute/changesets/ all
looks fine to me. I gave the setuptools-0.6 branch the name default
now, which seems to cause it to be the "default" you get as a working
copy when cloning the repo.

Doing "hg branches --active" shows me two active branches, default and
python3. You can switch to the python3 one using "hg up -C python3".

What exactly the best practice on reintegrating changes from one
branch to another is, I haven't quite figured out yet.

Hanno

From regebro at gmail.com  Sat Jul 18 12:17:45 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 12:17:45 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
Message-ID: <319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>

2009/7/18 Hanno Schlichting <hanno at hannosch.eu>:
> I don't see the problem. Note that branches in Mercurial are quite
> different from branches in SVN. Also typical SVN-style use might not
> be appropriate for Mercurial. I'm myself using this only for a very
> short time, so I'm in no position to lecture people about anything
> here.
>
> But looking at http://bitbucket.org/tarek/distribute/changesets/ all
> looks fine to me. I gave the setuptools-0.6 branch the name default
> now, which seems to cause it to be the "default" you get as a working
> copy when cloning the repo.

OK, that solved that problem. It's annoying that you can't delete
branches so they won't show up. OK, you can inactivate them, but the
default is to list all, and you have to type --active to not list the
inactive ones. That's just daft. It means that if you make a mistake,
like I did, you have to basically live with that mistake, and you
can't prune old branches in any reasonable way.

In svn, if you delete a branch it's gone. Except in history, so they
still exist if you look at the correct revision. That's the reasonable
way to do things.

Indeed, branches is very different from svn. But it cloning the right
way? What happens when you want to merge from different clones? And
can you have named clones?


Anyway. I found that with the mqextension strip you seem to be able to
delete branches.
I'd be happy to delete all my changes this way, and start over, this
seems doable. (It's not much work).
But before I do this, I would like confirmation that I should do this.
I think it's a good idea. The python3 branch is broken now anyway.


Thanks for helping out with this, Hanno.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Sat Jul 18 12:40:12 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 18 Jul 2009 12:40:12 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
Message-ID: <94bdd2610907180340s22b5f6c0y8ee02f85aeb7ad85@mail.gmail.com>

On Sat, Jul 18, 2009 at 11:39 AM, Hanno Schlichting<hanno at hannosch.eu> wrote:
> On Sat, Jul 18, 2009 at 9:01 AM, Lennart Regebro<regebro at gmail.com> wrote:
>> The best path forward right now seems to me to completely delete the
>> branches, including from history, which is possible in Mercurial,
>> assuming everybody recreated their clones afterwards, apparently.
>
> I don't see the problem. Note that branches in Mercurial are quite
> different from branches in SVN. Also typical SVN-style use might not
> be appropriate for Mercurial. I'm myself using this only for a very
> short time, so I'm in no position to lecture people about anything
> here.
>
> But looking at http://bitbucket.org/tarek/distribute/changesets/ all
> looks fine to me. I gave the setuptools-0.6 branch the name default
> now, which seems to cause it to be the "default" you get as a working
> copy when cloning the repo.
>
> Doing "hg branches --active" shows me two active branches, default and
> python3. You can switch to the python3 one using "hg up -C python3".

Yes that's the way to go

>
> What exactly the best practice on reintegrating changes from one
> branch to another is, I haven't quite figured out yet.

you just activate the branch you want to merge stuff in, and call a
merge with the other
branch name. That's straightforward and very easy compare to svn merging

From ziade.tarek at gmail.com  Sat Jul 18 12:42:54 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 18 Jul 2009 12:42:54 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
	<319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
Message-ID: <94bdd2610907180342l7445d9c0l6f4aebfd17d84660@mail.gmail.com>

> Anyway. I found that with the mqextension strip you seem to be able to
> delete branches.
> I'd be happy to delete all my changes this way, and start over, this
> seems doable. (It's not much work).
> But before I do this, I would like confirmation that I should do this.
> I think it's a good idea. The python3 branch is broken now anyway.

Please re-create it with the "0.8" name directly then, that will be
the future python 3 support branch.

From ziade.tarek at gmail.com  Sat Jul 18 12:45:47 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 18 Jul 2009 12:45:47 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <F6C6826A-7E28-4988-A9BF-D24337D5291C@bud.ca>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au>
	<F6C6826A-7E28-4988-A9BF-D24337D5291C@bud.ca>
Message-ID: <94bdd2610907180345y55a0176x523d48336a2661fb@mail.gmail.com>

On Sat, Jul 18, 2009 at 10:25 AM, Kevin Teague<kevin at bud.ca> wrote:
>
> On Jul 17, 2009, at 7:25 PM, Ben Finney wrote:
>
>> Tarek Ziad? <ziade.tarek at gmail.com> writes:
>>
>>> here's a Poll with the two finalists
>>
>> Huh? A dictatorship doesn't involve a poll.
>>
>
> Exactly! A *true* dictator would write something like:
>
> "Enough is enough! The project shall now and forever be knwon as
> 'tarektools'. Do not bother wasting your time objecting, as I am no longer
> going to respond to this thread."

I said it was a dictatorship because I picked the two finalists arbitrary.

And the poll will help me list the people that we will have to whip in the next
conferences because they didn't pick the right one. ;)

From ziade.tarek at gmail.com  Sat Jul 18 12:46:42 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 18 Jul 2009 12:46:42 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <319e029f0907180207q37978b3fj37ebc9ace9be367f@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au>
	<F6C6826A-7E28-4988-A9BF-D24337D5291C@bud.ca>
	<319e029f0907180207q37978b3fj37ebc9ace9be367f@mail.gmail.com>
Message-ID: <94bdd2610907180346o9816e1ds124a93d5a4ba488a@mail.gmail.com>

On Sat, Jul 18, 2009 at 11:07 AM, Lennart Regebro<regebro at gmail.com> wrote:
> I'm also extremely upset that none of the following options were not
> present in the poll:
> [...]
> tzat: Tarek Ziad?s Awesome Tools. Never mind everybody will think it
> has to do with timezones.

that's the best proposal i've seen so far :D

From hanno at hannosch.eu  Sat Jul 18 13:07:28 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sat, 18 Jul 2009 13:07:28 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090718000240.C42273A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
	<2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
	<5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.com>
	<20090718000240.C42273A403A@sparrow.telecommunity.com>
Message-ID: <5cae42b20907180407r5a658df0ma9aeb0044122dd88@mail.gmail.com>

On Sat, Jul 18, 2009 at 2:05 AM, P.J. Eby<pje at telecommunity.com> wrote:
> (Btw, I'm not sure if you really want to drop entry-points.txt from revision
> control, since ISTM a fresh checkout will not be able to run egg_info and
> rebuild it, unless you also add a hack to Distribution.get_command_class()
> so it (and any other setuptools commands it relies upon) can be found. ?If
> it seems to be working as-is, my guess is it's because an
> already-elsewhere-installed setuptools version on sys.path is providing the
> glue by way of *its* entry-points.txt. ?Try it and see!)

Ah thanks, I could reproduce the problem indeed and put the
entry_points.txt back into version control.

I build all my different Python versions based on a zc.buildout, so
obviously setuptools is installed globally in those, which makes them
quite bad for working on setuptools itself. Luckily I have those
system installed bad Python versions on the Mac, which I never touched
:)

Hanno

From g.brandl at gmx.net  Sat Jul 18 13:08:29 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 18 Jul 2009 13:08:29 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
 and fucked  everything up.
In-Reply-To: <319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
	<319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
Message-ID: <h3sagm$k2f$1@ger.gmane.org>

Lennart Regebro schrieb:
> 2009/7/18 Hanno Schlichting <hanno at hannosch.eu>:
>> I don't see the problem. Note that branches in Mercurial are quite
>> different from branches in SVN. Also typical SVN-style use might not
>> be appropriate for Mercurial. I'm myself using this only for a very
>> short time, so I'm in no position to lecture people about anything
>> here.
>>
>> But looking at http://bitbucket.org/tarek/distribute/changesets/ all
>> looks fine to me. I gave the setuptools-0.6 branch the name default
>> now, which seems to cause it to be the "default" you get as a working
>> copy when cloning the repo.
> 
> OK, that solved that problem. It's annoying that you can't delete
> branches so they won't show up. OK, you can inactivate them, but the
> default is to list all, and you have to type --active to not list the
> inactive ones. That's just daft. It means that if you make a mistake,
> like I did, you have to basically live with that mistake, and you
> can't prune old branches in any reasonable way.

I'm sure that this discussion will be welcome on the mercurial mailing list.
Maybe they haven't given their branches as much thought as you have.

> Anyway. I found that with the mqextension strip you seem to be able to
> delete branches.
> I'd be happy to delete all my changes this way, and start over, this
> seems doable. (It's not much work).
> But before I do this, I would like confirmation that I should do this.
> I think it's a good idea. The python3 branch is broken now anyway.

Note that you cannot push "stripped" changesets.  strip destructively alters
the history, and while that's a good thing as long as you only do it locally,
it would have detrimental effects on other clones, which e.g. could have
new changesets based on those you stripped.  So once you pushed a changeset,
and you really want to get rid of it, you must tell everyone who has a clone
to do the strip as well (starting with Jesper at bitbucket), or risk getting
contributions that reintroduce these changesets.

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  Sat Jul 18 13:15:48 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 18 Jul 2009 13:15:48 +0200
Subject: [Distutils] [Distribute] project status
Message-ID: <94bdd2610907180415o2246f1cchd6818880d6095c37@mail.gmail.com>

Hello,

We are going to freeze our bug fix work on the code and focus on
testing/documenting the release that we are planning to publish at
PyPI asap.

The list of bugs we've fixed are listed here :
http://bitbucket.org/tarek/distribute/wiki/bug_listing
If you feel that we forgot an important bug from the list we didn't
mirror yet, please let us know. Notice that we won't be able to fix
them
all now, and that we will have 0.6.x maintenance releases for that.

The first release will ship the same package/modules and will
overwrite an existing setuptools installation.

The tasks we will do now are:

- write a documentation on how to switch to distribute. This document
will explain the steps to use
  the distribution in a setuptools-based setup.py project or in a
zc.buildout environment.
  For the latter, this will probably require us to provide a custom
bootstrap.py script.

- write a documentation on how to uninstall distribute, if the user
want to go back to setuptools.
  (it's a friendly fork, we don't want to mess things up)

- write a roadmap document, explaining the plans for 0.7 and 0.8, so
the people that are installing 0.6 will
  know where they are heading.

- do extensive tests under various environment/contexts to see how
things work, and to validate that the
  upgrade/install scenarii are working well.  We will try to write
functional tests for that so we can replay
  them. This is very important, especially because the test coverage
in setuptools is very low right now.

- produce a tarball archive so people that wish to help can try out on
their side

Once we feel that the code is ready and enough tested, we will publish
'Distribute 0.6 (or whatever the name become)'
Except this release sometimes next week.

Extra steps if we have time :

- set up a buildbot
- more documentation
- improving test coverage


Cheers
Tarek

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

From hanno at hannosch.eu  Sat Jul 18 13:27:48 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sat, 18 Jul 2009 13:27:48 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <h3sagm$k2f$1@ger.gmane.org>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
	<319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
	<h3sagm$k2f$1@ger.gmane.org>
Message-ID: <5cae42b20907180427g681cba46v7c21af14e61386eb@mail.gmail.com>

On Sat, Jul 18, 2009 at 1:08 PM, Georg Brandl<g.brandl at gmx.net> wrote:
> Lennart Regebro schrieb:
>> 2009/7/18 Hanno Schlichting <hanno at hannosch.eu>:
>> OK, that solved that problem. It's annoying that you can't delete
>> branches so they won't show up. OK, you can inactivate them, but the
>> default is to list all, and you have to type --active to not list the
>> inactive ones. That's just daft. It means that if you make a mistake,
>> like I did, you have to basically live with that mistake, and you
>> can't prune old branches in any reasonable way.

Lennart, if you don't like the default then just add the following to
your hgrc file:

[defaults]
branches = --active

Mercurial just got the explicit notion of "closing" branches in
version 1.2, which seems to be made exactly for this use-case. You
want to see less clutter in the branches list.

> I'm sure that this discussion will be welcome on the mercurial mailing list.
> Maybe they haven't given their branches as much thought as you have.

>From what I can tell, using named branches seems to be considered
advanced and unusual in Mercurial. There's no need to give different
heads names at all and using entirely different clones seems more
usual. It's just those pesky SVN converts, which are so used to using
branches.

>> Anyway. I found that with the mqextension strip you seem to be able to
>> delete branches.
>> I'd be happy to delete all my changes this way, and start over, this
>> seems doable. (It's not much work).
>> But before I do this, I would like confirmation that I should do this.
>> I think it's a good idea. The python3 branch is broken now anyway.
>
> Note that you cannot push "stripped" changesets. ?strip destructively alters
> the history, and while that's a good thing as long as you only do it locally,
> it would have detrimental effects on other clones, which e.g. could have
> new changesets based on those you stripped. ?So once you pushed a changeset,
> and you really want to get rid of it, you must tell everyone who has a clone
> to do the strip as well (starting with Jesper at bitbucket), or risk getting
> contributions that reintroduce these changesets.

Yes. Please don't try to strip anything. Just because you seem to be
able to do this, doesn't make this a good idea.

How often did you manually alter SVN repositories to erase some part
of their history? It's for the rare case where highly confidential
information leaked or otherwise extreme cases - not for beautifying
the log. Learn to live with your mistakes ;-)

Hanno

From ziade.tarek at gmail.com  Sat Jul 18 13:33:55 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 18 Jul 2009 13:33:55 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <5cae42b20907180427g681cba46v7c21af14e61386eb@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
	<319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
	<h3sagm$k2f$1@ger.gmane.org>
	<5cae42b20907180427g681cba46v7c21af14e61386eb@mail.gmail.com>
Message-ID: <94bdd2610907180433r27a83b2bx78f7e356c203ffb3@mail.gmail.com>

On Sat, Jul 18, 2009 at 1:27 PM, Hanno Schlichting<hanno at hannosch.eu> wrote
>
> From what I can tell, using named branches seems to be considered
> advanced and unusual in Mercurial. There's no need to give different
> heads names at all and using entirely different clones seems more
> usual. It's just those pesky SVN converts, which are so used to using
> branches.

I disagree, it's fine to use named branch for all our version branches.

It's much more convenient than cloning the project, and it's faster to switch
from one branch to the other to do merge work.

While cloning if fine for experimentation purposes,

I am -1 for cloning the repo for the py3k branch because it will be
our 'official' branch
at some point.

If it's required, I can write a how-to use branches for this specific project,
and set up Lennart's branch for the py3 support.

Cheers
Tarek

From zooko at zooko.com  Sat Jul 18 14:37:39 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sat, 18 Jul 2009 06:37:39 -0600
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<319e029f0907170942k38c58dafnec3839709d128581@mail.gmail.com>
	<2f2e5f950907170948t58fc2828j43dd7ada6cfd0d99@mail.gmail.com>
	<5cae42b20907171305g60ee1ffajc1cb1d4fed52602c@mail.gmail.com>
Message-ID: <9BCB4D9F-7412-4B9B-9FA5-297172B8AF4A@zooko.com>

On Friday,2009-07-17, at 14:05 , Hanno Schlichting wrote:

> On Fri, Jul 17, 2009 at 6:48 PM, Leonardo  
> Santagada<santagada at gmail.com> wrote:
>> Setuptools is dead, but the fork should be named something else  
>> just to show that development doesn't have anything to do with the  
>> way setuptools and is in fact a new and live project. People that  
>> were burned by setuptools should give distribute a new chance.
...
> Anyone who wants to rewrite setuptools from scratch or thinks  
> "easy_install must die" probably will be very disappointed by the  
> distribute fork.

I'm not one of those people, but I know a lot of people who have  
burned by setuptools and who might give it another chance once  
"respect the PYTHONPATH" [1] and "be more like distutils with regard  
to --prefix=" [2] are fixed.

Regards,

Zooko

[1] http://bugs.python.org/setuptools/issue53
[2] http://bugs.python.org/setuptools/issue54


From zooko at zooko.com  Sat Jul 18 14:45:19 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Sat, 18 Jul 2009 06:45:19 -0600
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907180346o9816e1ds124a93d5a4ba488a@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au>
	<F6C6826A-7E28-4988-A9BF-D24337D5291C@bud.ca>
	<319e029f0907180207q37978b3fj37ebc9ace9be367f@mail.gmail.com>
	<94bdd2610907180346o9816e1ds124a93d5a4ba488a@mail.gmail.com>
Message-ID: <17065283-3744-4F52-9D6A-500C5A5A7214@zooko.com>

>> tzat: Tarek Ziad?s Awesome Tools. Never mind everybody will think it
>> has to do with timezones.
>
> that's the best proposal i've seen so far :D

You could name it "zetuptoolz".

Regards,

Zooko



From him at online.de  Sat Jul 18 16:54:21 2009
From: him at online.de (=?ISO-8859-1?Q?Joachim_K=F6nig?=)
Date: Sat, 18 Jul 2009 16:54:21 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090717163204.A507B3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>	<878winhcny.fsf_-_@benfinney.id.au>	<20090717112359.588423A4099@sparrow.telecommunity.com>	<4A6086C9.7000203@simplistix.co.uk>	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
Message-ID: <4A61E21D.1000508@online.de>

P.J. Eby wrote:
> In other words, people I know and trust to be qualified for the job 
> are quite free to maintain it.  If Jim or Ian wanted to "adopt" 
> setuptools or become primary maintainers, I'd frankly jump at the 
> opportunity!
>
> Mainly, I trust Jim and Ian because they're thorough, cautious, and 
> sensitive to "legacy" issues.  I know they're not going to go in and 
> reverse years of policy until and unless they have a damn good 
> understanding of both the old and the new requirements, and have a 
> plan to address compatibility and migration.

I think this is the main issue with setuptools: it requires maintainers 
capable of mastering a high
degree of complexity. I often admire such people but I rarely admire 
their code if I have to
use it because if it gets in my way, I have a hard time figuring out 
what to change to let that
code do what I need.

About setuptools, it does to much in an intertwined way so that it's 
hard to instruct to do
only the steps I want it to do.

I think, that's also the reason why it's so hard to find a good 
descriptive name for the fork.

So let me also suggest two ironic names to shed some light on it:

- upsettools because it upsets a lot of people
- pjesak PJE's swiss army knife, sounding similar to the german 
"piesack" which means "to badger".

Can't setupstools be split up into individual scripts that can be used 
on their own but working
on a common specification:

- determining dependencies
- determining what's installed and detecting possible conflicts
- fetching code from remote to the local system
- extracting the code for building
- patching the code with local patches
- building the code
- installing to the  destination
- ...

Finding good names for the individual steps should be much easier. The 
fork of setuptools
could then execute the steps in the right order automatically but system 
integrators could
easily only perform the steps they require to be done by the setuptools 
fork, other steps
could be performed by the packaging system.



 

From mihamina at gulfsat.mg  Sat Jul 18 18:25:03 2009
From: mihamina at gulfsat.mg (Rakotomandimby Mihamina)
Date: Sat, 18 Jul 2009 19:25:03 +0300
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <4A61355E.50706@plope.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>	<878winhcny.fsf_-_@benfinney.id.au>	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>	<87r5wffsdz.fsf@benfinney.id.au>	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>	<4A607BF3.8060908@gulfsat.mg>	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>	<87my72d8wt.fsf@benfinney.id.au>
	<4A61355E.50706@plope.com>
Message-ID: <4A61F75F.3070400@gulfsat.mg>

07/18/2009 05:37 AM, Chris McDonough::
> I'd be quite happy if Tarek ignored the meta-drivel in this thread and
> made some checkins,

That's what "community driven" projects are made of.
In the "proprietary world", it would have just been done with a patent search:
no patent on one name -> OK.

I think we'll have to live with.

-- 
                             Architecte Informatique:
    Administration Systeme, Recherche & Developpement
                                   + 261 32 11 401 65
Pensez a l'environnement avant d'imprimer ce message

From regebro at gmail.com  Sat Jul 18 19:43:35 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 19:43:35 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <4A61E21D.1000508@online.de>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<4A61E21D.1000508@online.de>
Message-ID: <319e029f0907181043i736727dcl961e0cc2864747ba@mail.gmail.com>

2009/7/18 Joachim K?nig <him at online.de>:
> - upsettools because it upsets a lot of people

Hah! I'm with you on that one.

> Can't setupstools be split up into individual scripts that can be used on
> their own but working on a common specification:

I think that's part of the plan.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Sat Jul 18 19:45:37 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 19:45:37 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <h3sagm$k2f$1@ger.gmane.org>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
	<319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
	<h3sagm$k2f$1@ger.gmane.org>
Message-ID: <319e029f0907181045j137bd489r69ec8b1cfdbfe9c0@mail.gmail.com>

2009/7/18 Georg Brandl <g.brandl at gmx.net>:
> Note that you cannot push "stripped" changesets. ?strip destructively alters
> the history, and while that's a good thing as long as you only do it locally,
> it would have detrimental effects on other clones, which e.g. could have
> new changesets based on those you stripped. ?So once you pushed a changeset,
> and you really want to get rid of it, you must tell everyone who has a clone
> to do the strip as well (starting with Jesper at bitbucket), or risk getting
> contributions that reintroduce these changesets.

Which is exactly what I intend to do. And if somebody re-pushes those
changeset, I'll spank them.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Sat Jul 18 19:49:59 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 19:49:59 +0200
Subject: [Distutils] [distribute] Python 3 support checked in,
	and fucked 	everything up.
In-Reply-To: <5cae42b20907180427g681cba46v7c21af14e61386eb@mail.gmail.com>
References: <319e029f0907171418t49d14132r32972d310c617dfb@mail.gmail.com>
	<5cae42b20907171614k3785a660n22c02313767074b0@mail.gmail.com>
	<319e029f0907172320q27fcbc9en779cc9c266dd8249@mail.gmail.com>
	<319e029f0907172336s33bd23b6t18603c45c574b6dd@mail.gmail.com>
	<319e029f0907180001s516a660elc4cc94866858b1e3@mail.gmail.com>
	<5cae42b20907180239n11822a55pffa77a5a4d16b732@mail.gmail.com>
	<319e029f0907180317k2abcab57w5060d199edf1e72c@mail.gmail.com>
	<h3sagm$k2f$1@ger.gmane.org>
	<5cae42b20907180427g681cba46v7c21af14e61386eb@mail.gmail.com>
Message-ID: <319e029f0907181049i2f42e9a4oea2cce8195fc0701@mail.gmail.com>

2009/7/18 Hanno Schlichting <hanno at hannosch.eu>:
> From what I can tell, using named branches seems to be considered
> advanced and unusual in Mercurial. There's no need to give different
> heads names at all and using entirely different clones seems more
> usual. It's just those pesky SVN converts, which are so used to using
> branches.

OK, so no 0.8 branch, I will make a python3 clone.

> Yes. Please don't try to strip anything. Just because you seem to be
> able to do this, doesn't make this a good idea.

I think it's an excellent idea, because in this case I've checked in
two branches that should not exist. Those changes should be undone.

> How often did you manually alter SVN repositories to erase some part
> of their history?


Never, because I don't need to. Once I've undone the mistake, it's not
there anymore.

> It's for the rare case where highly confidential
> information leaked or otherwise extreme cases - not for beautifying
> the log. Learn to live with your mistakes ;-)

I can live with them, but why should everyone else have to?

Those branches should go. The checkins I did was misguided based on
the idea that branches in Mercurial are useful. That was wrong.
Removing those branches is without problems, as long as nobody else
has checked them out today (and as far as I know, that's only you,
Hanno), and then makes a commit from them later.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From sridharr at activestate.com  Sat Jul 18 19:56:05 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 10:56:05 -0700
Subject: [Distutils] idea - keeping package index code (in pip,
	distribute) separate
Message-ID: <op.uw9yrriz1q4jlt@whymac>

Both easy_install and pip uses similar method to find download URLs for  
packages. They are not very unreliable - see the new issues in Distribute  
tracker:

   http://bitbucket.org/tarek/distribute/issues/?status=new&reported_by=srid

Hence I suggest that we create a separate project containing just this  
indexing code .. and let Distribute and pip use it via install_requires.  
Thoughts?

-srid

From pje at telecommunity.com  Sat Jul 18 21:50:34 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Jul 2009 15:50:34 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <4A6154B0.6000707@plope.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
Message-ID: <20090718194729.D5B8D3A403A@sparrow.telecommunity.com>

At 12:50 AM 7/18/2009 -0400, Chris McDonough wrote:
>On 7/17/09 11:47 PM, Ben Finney wrote:
>>Chris McDonough<chrism at plope.com>  writes:
>>
>>>You gotta realize that fielding all these bikeshed emails takes a lot
>>>of time; if it gets named "distribute" or one of the two options from
>>>the poll, so be it.  Give the poor man a mail-responding rest. ;-)
>>
>>Agreed.
>>
>>>There's all of eternity to bikeshed the name after the first release,
>>>but a release is required for there to be anything to bikeshed about.
>>
>>I couldn't disagree more. Discussing the name *after* release will be
>>even less useful because it's so much more difficult to actually change
>>it at that point.
>
>Note that the primary package name that the "distribute" 
>distribution embeds is still named "setuptools" at this point, for 
>better or worse.  I don't know how long this will be true, but it's 
>still true right now, and I suspect it won't change before the first 
>release.  That may be another can of worms, but at this point it's 
>probably not worth losing any sleep over.
>
>In any case, changing the distribution name ("distribute" currently) 
>is pretty trivial in comparison to changing a package name because 
>imports don't need to change.  I'd begin to get more nervous when 
>the package names change. ;-)

Also, this entire discussion may be moot if, as I'm currently 
understanding it, this is simply a matter of other people doing 
maintenance and bug fixes to the 0.6 branch...  in which case there 
is a very strong possibility that I'll just bless various versions of 
it as official 0.6 versions of setuptools.

(One obstacle to this actually happening, though, is the part where 
they're stripping out my release tools, like wikiup.cfg, 
version+version.dat, etc., as I would need to add these back in order 
to actually do a release.)


From pje at telecommunity.com  Sat Jul 18 22:02:33 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Jul 2009 16:02:33 -0400
Subject: [Distutils] [Distribute] project status
In-Reply-To: <94bdd2610907180415o2246f1cchd6818880d6095c37@mail.gmail.co
 m>
References: <94bdd2610907180415o2246f1cchd6818880d6095c37@mail.gmail.com>
Message-ID: <20090718195929.1D6833A403A@sparrow.telecommunity.com>

At 01:15 PM 7/18/2009 +0200, Tarek Ziad? wrote:
>Hello,
>
>We are going to freeze our bug fix work on the code and focus on
>testing/documenting the release that we are planning to publish at
>PyPI asap.
>
>The list of bugs we've fixed are listed here :
>http://bitbucket.org/tarek/distribute/wiki/bug_listing
>If you feel that we forgot an important bug from the list we didn't
>mirror yet, please let us know. Notice that we won't be able to fix
>them
>all now, and that we will have 0.6.x maintenance releases for that.


Btw, does this changeset:

    http://bitbucket.org/tarek/distribute/changeset/52bb77ad5030/

Work on Python 2.3 on the Mac?  platform.mac_ver() was not documented 
until 2.4; was it actually introduced in 2.3?


From pje at telecommunity.com  Sat Jul 18 22:08:48 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Jul 2009 16:08:48 -0400
Subject: [Distutils] idea - keeping package index code (in pip,
 distribute) separate
In-Reply-To: <op.uw9yrriz1q4jlt@whymac>
References: <op.uw9yrriz1q4jlt@whymac>
Message-ID: <20090718200543.E42323A403A@sparrow.telecommunity.com>

At 10:56 AM 7/18/2009 -0700, Sridhar Ratnakumar wrote:
>Both easy_install and pip uses similar method to find download URLs for
>packages. They are not very unreliable - see the new issues in Distribute
>tracker:
>
>   http://bitbucket.org/tarek/distribute/issues/?status=new&reported_by=srid
>
>Hence I suggest that we create a separate project containing just this
>indexing code .. and let Distribute and pip use it via install_requires.
>Thoughts?

In order for install_requires to work, you need something like 
easy_install in the first place...  and a way to bootstrap it.

You could perhaps take setuptools.package_index or something like it, 
bundle it with pkg_resources, and have a nice little core support for 
dependency handling, downloading, and local package queries.  Then, 
you could put it in the stdlib... kind of like I proposed in PEP 365.  ;-)

Alternately, you need a replacement for ez_setup.py that's a 
stripped-down cross between pkg_resources and 
setuptools.package_index, or that can at least *download* that 
combination for you and then run other stuff.


From regebro at gmail.com  Sat Jul 18 22:07:48 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 18 Jul 2009 22:07:48 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
Message-ID: <319e029f0907181307i3de45c2ah8b665777392b7716@mail.gmail.com>

2009/7/18 P.J. Eby <pje at telecommunity.com>:
> Also, this entire discussion may be moot if, as I'm currently understanding
> it, this is simply a matter of other people doing maintenance and bug fixes
> to the 0.6 branch... ?in which case there is a very strong possibility that
> I'll just bless various versions of it as official 0.6 versions of
> setuptools.

That is indeed the idea for the first release.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pje at telecommunity.com  Sat Jul 18 22:25:28 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Jul 2009 16:25:28 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <4A61E21D.1000508@online.de>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<4A61E21D.1000508@online.de>
Message-ID: <20090718202224.3FC833A403A@sparrow.telecommunity.com>

At 04:54 PM 7/18/2009 +0200, Joachim K?nig wrote:
>I think this is the main issue with setuptools: it requires 
>maintainers capable of mastering a high
>degree of complexity.

That's because:

1. It started as some project-specific distutils hacks to make life easier,
2. It got a whole bunch of new hacks added on to support eggs and 
automated installation, and
3. The distutils were already way too f'ing flexible.  A ridiculous 
amount of setuptools' complexity stems from trying to be 99% backward 
compatible with the bizarre configurations that distutils allows.


>- upsettools because it upsets a lot of people

I actually like that one, and if this project doesn't use it, I will 
probably steal it for something else of my own at a future date.  ;-)


>Can't setupstools be split up into individual scripts that can be 
>used on their own but working
>on a common specification:
>
>- determining dependencies
>- determining what's installed and detecting possible conflicts

These two are in the pkg_resources module...

>- fetching code from remote to the local system

...the setuptools.package_index module...

>- extracting the code for building
>- patching the code with local patches
>- building the code
>- installing to the  destination

...and the setuptools.command.easy_install module (except for the 
patching part).  So there is already a good degree to which these can 
be split out and reused for another project.

The only reason why all this stuff is bundled in a single setuptools 
distribution is simplicity of bootstrapping.  If pkg_resources and a 
cleaned-up version of setuptools.package_index were in the stdlib, 
then other distribution tools could build on them without needing to 
bundle them.

OTOH, maybe part of what we need is better tools for bundling on the 
build side, so that packaging tools could just throw a few .egg or 
.zip files into their sdists for bootstrapping support.  That'd 
probably be even more useful than an improved download-and-bootstrap 
facility, at least for packaging tools.


From hanno at hannosch.eu  Sat Jul 18 22:40:52 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sat, 18 Jul 2009 22:40:52 +0200
Subject: [Distutils] [Distribute] project status
In-Reply-To: <20090718195929.1D6833A403A@sparrow.telecommunity.com>
References: <94bdd2610907180415o2246f1cchd6818880d6095c37@mail.gmail.com>
	<20090718195929.1D6833A403A@sparrow.telecommunity.com>
Message-ID: <5cae42b20907181340l2556e5fex2a1ac6db6c34b8aa@mail.gmail.com>

2009/7/18 P.J. Eby <pje at telecommunity.com>:
> Btw, does this changeset:
>
> ? http://bitbucket.org/tarek/distribute/changeset/52bb77ad5030/
>
> Work on Python 2.3 on the Mac? ?platform.mac_ver() was not documented until
> 2.4; was it actually introduced in 2.3?

In my build of Python 2.3 the function is available. It's also visible
in the source tree for easy reference:

http://svn.python.org/view/python/branches/release23-maint/Lib/platform.py?view=markup

Hanno

From ziade.tarek at gmail.com  Sat Jul 18 22:42:49 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 18 Jul 2009 22:42:49 +0200
Subject: [Distutils] [Distribute] project status
In-Reply-To: <20090718195929.1D6833A403A@sparrow.telecommunity.com>
References: <94bdd2610907180415o2246f1cchd6818880d6095c37@mail.gmail.com>
	<20090718195929.1D6833A403A@sparrow.telecommunity.com>
Message-ID: <94bdd2610907181342n5b354c96h4da9e1a4faa786e6@mail.gmail.com>

2009/7/18 P.J. Eby <pje at telecommunity.com>:
> At 01:15 PM 7/18/2009 +0200, Tarek Ziad? wrote:
>>
>> Hello,
>>
>> We are going to freeze our bug fix work on the code and focus on
>> testing/documenting the release that we are planning to publish at
>> PyPI asap.
>>
>> The list of bugs we've fixed are listed here :
>> http://bitbucket.org/tarek/distribute/wiki/bug_listing
>> If you feel that we forgot an important bug from the list we didn't
>> mirror yet, please let us know. Notice that we won't be able to fix
>> them
>> all now, and that we will have 0.6.x maintenance releases for that.
>
>
> Btw, does this changeset:
>
> ? http://bitbucket.org/tarek/distribute/changeset/52bb77ad5030/
>
> Work on Python 2.3 on the Mac? ?platform.mac_ver() was not documented until
> 2.4; was it actually introduced in 2.3?

Yes it's present in 2.3. I'm having problems though to build a 2.3
version to run the tests
under Leopard, I have to change the configure file to compile it.
(the __dummy reference doesn't not exist anymore)



>
>



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

From hanno at hannosch.eu  Sun Jul 19 01:05:03 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sun, 19 Jul 2009 01:05:03 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
Message-ID: <5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>

On Sat, Jul 18, 2009 at 9:50 PM, P.J. Eby<pje at telecommunity.com> wrote:
> Also, this entire discussion may be moot if, as I'm currently understanding
> it, this is simply a matter of other people doing maintenance and bug fixes
> to the 0.6 branch... ?in which case there is a very strong possibility that
> I'll just bless various versions of it as official 0.6 versions of
> setuptools.
>
> (One obstacle to this actually happening, though, is the part where they're
> stripping out my release tools, like wikiup.cfg, version+version.dat, etc.,
> as I would need to add these back in order to actually do a release.)

In order to make it easier for you to bless things, I created a branch
of our work, which very closely resembles the official setuptools 0.6
branch, including the correct distribution name and including all your
build and release tools.

It's a "hg up -C setuptools-compatible-0.6" away after cloning the
repo. It does need some more tweaks to version identifiers (is it 0.6
or 0.6.0 or 0.6-final ...) and lacks the md5 checksums for release
files, since these are obviously not produced yet.

I'd be happy to produce the Windows binary installers for an official release.

I'm sure we do have some disagreements about how to evolve setuptools
after the 0.6 branch. But our ideas of what is appropriate for
maintenance releases seem to match quite well.

Cheers,
Hanno

From greg.ewing at canterbury.ac.nz  Sun Jul 19 03:59:38 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 19 Jul 2009 13:59:38 +1200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090718202224.3FC833A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<79990c6b0907160808n5479d8f8t2731472f6621bb4d@mail.gmail.com>
	<94bdd2610907160818m7941478r280fe422ec54e3d1@mail.gmail.com>
	<319e029f0907160833t44cdc01an9b718eb819db18a1@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz> <878winhcny.fsf_-_@benfinney.id.au>
	<20090717112359.588423A4099@sparrow.telecommunity.com>
	<4A6086C9.7000203@simplistix.co.uk>
	<20090717144125.5C12A3A403A@sparrow.telecommunity.com>
	<319e029f0907170753j7e20d941ke3d8e47de2d8b440@mail.gmail.com>
	<20090717163204.A507B3A403A@sparrow.telecommunity.com>
	<4A61E21D.1000508@online.de>
	<20090718202224.3FC833A403A@sparrow.telecommunity.com>
Message-ID: <4A627E0A.3060303@canterbury.ac.nz>

> At 04:54 PM 7/18/2009 +0200, Joachim K?nig wrote:
> 
> > - upsettools because it upsets a lot of people

+10 -- that's brilliant!

-- 
Greg


From pje at telecommunity.com  Sun Jul 19 04:31:36 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Jul 2009 22:31:36 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.co
 m>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
Message-ID: <20090719022831.959983A403A@sparrow.telecommunity.com>

At 01:05 AM 7/19/2009 +0200, Hanno Schlichting wrote:
>On Sat, Jul 18, 2009 at 9:50 PM, P.J. Eby<pje at telecommunity.com> wrote:
> > Also, this entire discussion may be moot if, as I'm currently understanding
> > it, this is simply a matter of other people doing maintenance and bug fixes
> > to the 0.6 branch... ? in which case there is a very strong 
> possibility that
> > I'll just bless various versions of it as official 0.6 versions of
> > setuptools.
> >
> > (One obstacle to this actually happening, though, is the part where they're
> > stripping out my release tools, like wikiup.cfg, version+version.dat, etc.,
> > as I would need to add these back in order to actually do a release.)
>
>In order to make it easier for you to bless things, I created a branch
>of our work, which very closely resembles the official setuptools 0.6
>branch, including the correct distribution name and including all your
>build and release tools.
>
>It's a "hg up -C setuptools-compatible-0.6" away after cloning the
>repo. It does need some more tweaks to version identifiers (is it 0.6
>or 0.6.0 or 0.6-final ...) and lacks the md5 checksums for release
>files, since these are obviously not produced yet.
>
>I'd be happy to produce the Windows binary installers for an official release.

Good to know.  I'll take a look at it soon.


>I'm sure we do have some disagreements about how to evolve setuptools
>after the 0.6 branch.

Perhaps.  But it occurs to me that there is something I can do to 
help that in the long run.  After giving it some thought today, it 
seems that it would be a good idea to take the "good" (i.e. 
relatively uncontroversial) parts of setuptools and split them out 
into another package, which I am tentatively naming "Discovery".

Rather than a set of executable tools, it would just be a collection 
of libraries to be called by package management tools, and other 
Python code needing to discover packages either installed on the 
system, on the package index, be notified when they're imported, etc. etc.

The package itself would look something like this:

discovery.resources -- basically pkg_resources under a different name

discovery.sandbox -- basically setuptools.sandbox, less distutils dependency

discovery.unpack -- setuptools.archive_util, less distutils dependency

discovery.downloads -- a hugely refactored version of parts of 
setuptools.package_index, redesigned for pluggable extendibility 
(e.g. to handle Sourceforge crap, checkouts from other revision 
control systems, etc.)

discovery.install -- selected subroutines from easy_install, 
refactored for narrow functionality and minimal coupling, combined 
with PEP 376 support code

discovery.importing -- basically peak.util.imports under a different 
name, but with a more modern/decorator-friendly API

discovery.plugins -- basically peak.util.plugins, refactored to drop 
dependencies on other PEAK modules

Then, easy_install could be refactored to consist mostly of calls to 
these other modules, along with whatever "legacy" logic needs to be 
retained for compatibility reasons, and setuptools proper could 
evolve towards just being build support, and become more pluggable generally.

It wouldn't be possible to switch setuptools to do this right away, 
since there would remain the problem of bootstrapping the 
installation of the discovery package prior to setuptools 
installation.  But setuptools' source distribution could perhaps 
bundle a copy of discovery within itself, and the ez_setup.py script 
could perhaps then be changed to download *discovery* first -- and 
then ask discovery to download setuptools to a temporary location.

However, now that somebody else is effectively looking out for 0.6 
maintenance, this lets me bump up the priority of working on 0.7, and 
has given me ideas for how to get out from under the rest of the 
"legacy" problems of setuptools, while also making reuse easier for 
competing and/or complementary projects (such as buildout, pip, etc.)


From pje at telecommunity.com  Sun Jul 19 04:34:45 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Jul 2009 22:34:45 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090719022831.959983A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
Message-ID: <20090719023140.533F93A403A@sparrow.telecommunity.com>

At 10:31 PM 7/18/2009 -0400, P.J. Eby wrote:
>But setuptools' source distribution could perhaps bundle a copy of 
>discovery within itself, and the ez_setup.py script could perhaps 
>then be changed to download *discovery* first -- and then ask 
>discovery to download setuptools to a temporary location.

Oops.  I meant, "OR the ez_setup.py script could perhaps be changed 
to download discovery first".


From sridharr at activestate.com  Sun Jul 19 04:39:00 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 19:39:00 -0700
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090719022831.959983A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
Message-ID: <op.uxamy6gp1q4jlt@whymac>

On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> The package itself would look something like this:
>  discovery.resources -- basically pkg_resources under a different name
>  discovery.sandbox -- basically setuptools.sandbox, less distutils  
> dependency
>  discovery.unpack -- setuptools.archive_util, less distutils dependency
>  discovery.downloads -- a hugely refactored version of parts of  
> setuptools.package_index, redesigned for pluggable extendibility (e.g.  
> to handle Sourceforge crap, checkouts from other revision control  
> systems, etc.)
>  discovery.install -- selected subroutines from easy_install, refactored  
> for narrow functionality and minimal coupling, combined with PEP 376  
> support code
>  discovery.importing -- basically peak.util.imports under a different  
> name, but with a more modern/decorator-friendly API
>  discovery.plugins -- basically peak.util.plugins, refactored to drop  
> dependencies on other PEAK modules

PyPM currently uses `setuptools.package_index` in the backend mirror ..  
but that module is not very API-friendly (prints to stderr, throws  
network-related exceptions without handling them, and not flexible).

Eventually, if possible, I would like to add support for 'installing from  
source tarballs' (for packages that are not available in the ActiveState  
binary repository).

So, +1 on discovery.downloads (our backend mirror) and  
discovery.sandbox/resources at least (the idea being to co-operate with  
both activestate repo binaries and easy_install'ble tarballs).

-srid

From pje at telecommunity.com  Sun Jul 19 05:17:59 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Jul 2009 23:17:59 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <op.uxamy6gp1q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxamy6gp1q4jlt@whymac>
Message-ID: <20090719031455.55DB93A403A@sparrow.telecommunity.com>

At 07:39 PM 7/18/2009 -0700, Sridhar Ratnakumar wrote:
>PyPM currently uses `setuptools.package_index` in the backend mirror ..
>but that module is not very API-friendly (prints to stderr, throws
>network-related exceptions without handling them, and not flexible).

Yep, that's exactly the sort of thing I'd like to refactor.  (At 
least, the logging and flexibility bits -- it may actually delegate 
*more* error handling to the invoking application, for flexibility reasons.)

Anyway, splitting these things off into a separate package would 
certainly make it easier to keep the API clean, and clearly 
distinguished from any leftover legacy cruft.

As far as flexibility goes, the rough idea would be to have a 
PackageIndex be able to have  a custom logger and a "download 
manager", where the download manager's job is to vet URLs (e.g. 
filtering ala --allow-hosts) and to actually open/download 
URLs.  This would allow easier testing of the PackageIndex's main 
functionality, since a mock "download manager" could simulate 
downloads without actually downloading anything.

There would also be entry points for URL parsers (to figure out what 
distributions, if any, that URL might point to), index page readers 
(to handle specialized index pages like Sourceforge) and 
html-download handlers (to do things like detect an SVN, hg, git, 
bzr, etc. HTTP repository), as well as URL scheme handlers (to do 
e.g. svn checkouts).  All of the current cheesy special case code for 
these things would go away, replaced with independent functions or 
classes that simply act as plugins within the overall scheme.


>Eventually, if possible, I would like to add support for 'installing from
>source tarballs' (for packages that are not available in the ActiveState
>binary repository).

Certainly, between the .download, .unpack, and .sandbox modules, 
you'd be able to roll your own version of that, even if the .install 
module didn't include its own version.


From ziade.tarek at gmail.com  Sun Jul 19 11:12:00 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 19 Jul 2009 11:12:00 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090719022831.959983A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
Message-ID: <94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>

On Sun, Jul 19, 2009 at 4:31 AM, P.J. Eby<pje at telecommunity.com> wrote:
> [...]
> Perhaps. ?But it occurs to me that there is something I can do to help that
> in the long run. ?After giving it some thought today, it seems that it would
> be a good idea to take the "good" (i.e. relatively uncontroversial) parts of
> setuptools and split them out into another package, which I am tentatively
> naming "Discovery".
>
> Rather than a set of executable tools, it would just be a collection of
> libraries to be called by package management tools, and other Python code
> needing to discover packages either installed on the system, on the package
> index, be notified when they're imported, etc. etc.
>
> The package itself would look something like this:
>
> discovery.resources -- basically pkg_resources under a different name
>
> discovery.sandbox -- basically setuptools.sandbox, less distutils dependency
>
> discovery.unpack -- setuptools.archive_util, less distutils dependency
>
> discovery.downloads -- a hugely refactored version of parts of
> setuptools.package_index, redesigned for pluggable extendibility (e.g. to
> handle Sourceforge crap, checkouts from other revision control systems,
> etc.)
>
> discovery.install -- selected subroutines from easy_install, refactored for
> narrow functionality and minimal coupling, combined with PEP 376 support
> code
>
> discovery.importing -- basically peak.util.imports under a different name,
> but with a more modern/decorator-friendly API
>
> discovery.plugins -- basically peak.util.plugins, refactored to drop
> dependencies on other PEAK modules
>
> Then, easy_install could be refactored to consist mostly of calls to these
> other modules, along with whatever "legacy" logic needs to be retained for
> compatibility reasons, and setuptools proper could evolve towards just being
> build support, and become more pluggable generally.
>
> It wouldn't be possible to switch setuptools to do this right away, since
> there would remain the problem of bootstrapping the installation of the
> discovery package prior to setuptools installation. ?But setuptools' source
> distribution could perhaps bundle a copy of discovery within itself, and the
> ez_setup.py script could perhaps then be changed to download *discovery*
> first -- and then ask discovery to download setuptools to a temporary
> location.
>
> However, now that somebody else is effectively looking out for 0.6
> maintenance, this lets me bump up the priority of working on 0.7, and has
> given me ideas for how to get out from under the rest of the "legacy"
> problems of setuptools, while also making reuse easier for competing and/or
> complementary projects (such as buildout, pip, etc.)
>

That's very interesting but you previously said that you needed time
and/or someone
paying you to continue the work in this area. And that you didn't have time
so setuptools was just "sleeping" (that's your own word)

Now, suddenly, you want to do what we planned to do in Distribute 0.7,
e.g. splitting
setuptools in several packages.

That would be nice but I am a bit surprised, and very suspicious in fact.

I am scared that at the end, you will still lock us by not blessing
people to maintain
yet another collection of packages you don't have time to maintain.

So, I am glad that our fork made you think about your future plans, but unless
you give us some guarantees, I don't see anything changing. And I'd prefer not
relying on you for this because you have proven with the past year
you didn't have time at all to work on the code.

So are you willing to bless us maintaining/working with you with these
new packages,
or is that going to be a PJE-locked thing again ?

If this is not stated clearly, Distribute will probably compete with
your new "Discovery" packages
I am afraid.

Now for the packages, they all look great

just a question :
> discovery.unpack -- setuptools.archive_util, less distutils dependency

how this will be 'less distutils dependent' ? because I was planning
to integrated setuptools.archive_util in distutils.

Regards
Tarek

From regebro at gmail.com  Sun Jul 19 11:37:20 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 19 Jul 2009 11:37:20 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
Message-ID: <319e029f0907190237l2c3cd3ack86c865558dbb979d@mail.gmail.com>

2009/7/19 Tarek Ziad? <ziade.tarek at gmail.com>:
> That would be nice but I am a bit surprised, and very suspicious in fact.

No need for paranoia. :)

> I am scared that at the end, you will still lock us by not blessing
> people to maintain
> yet another collection of packages you don't have time to maintain.

Yes!

PJE: It would be great if we could cooperate on this, if this could
happen in a repository where more people have access. And I don't mean
just Gurus with more Python experience than Guido and less time than a
quantum fluctuation, but people who have both the time and the
knowledge to work on this. And they do exist, and we have several of
them involved in Distribute already.

> So are you willing to bless us maintaining/working with you with these
> new packages, or is that going to be a PJE-locked thing again ?

If it is, everybody is just going to ignore it. Except that we may
fork useful bits if licensing allows. It's not a problem, it's just
that it would be better if this didn't happen. These issues are
complex enough that we need everybody help we can find.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From jim at zope.com  Sun Jul 19 17:13:44 2009
From: jim at zope.com (Jim Fulton)
Date: Sun, 19 Jul 2009 11:13:44 -0400
Subject: [Distutils] [Buildout] Download API and extends caching -
	please	review
In-Reply-To: <pan.2009.06.24.15.51.01.221130@ID-174572.user.uni-berlin.de>
References: <pan.2009.06.11.06.55.07.449140@ID-174572.user.uni-berlin.de>
	<pan.2009.06.24.15.51.01.221130@ID-174572.user.uni-berlin.de>
Message-ID: <7B73406B-7D3C-40B8-866F-FC1F0F3156D9@zope.com>


On Jun 24, 2009, at 1:04 PM, Thomas Lotze wrote:

> Thomas Lotze wrote:
>
>> As discussed before on this list, I've been working on an internal
>> download API for zc.buildout that takes care of handling the download
>> cache, offline mode, MD5 checks etc and is used for fetching  
>> configuration
>> files (as specified by the buildout:extends option). I consider the
>> feature finished and I'd be grateful if someone could review it  
>> before it
>> gets merged to the trunk. The branch I've been developing this on is
>> <svn://svn.zope.org/repos/main/zc.buildout/branches/tlotze-download-api 
>> >.
>
> Since I wrote that message, I've been working on using the download  
> API in
> zc.recipe.cmmi. The recipe is now able to perform MD5 checksum
> verification on downloaded source archives and patches and I've used  
> this
> opportunity of seeing the new download code in action to improve it
> further.
>
> I'd like to ask again for a code review of both projects' feature  
> branches
> (the recipe's being at
> <svn://svn.zope.org/repos/main/zc.buildout/branches/tlotze-download-api 
> >)
> before merging them to the respective trunks. Jim, as you've  
> responded to
> questions on the subject before, would you be willing and find some  
> time
> to have a look at the code?


This looks good. Thanks.  I'm getting a test failure on Mac OS X that  
I'll write about separately.

Jim

--
Jim Fulton
Zope Corporation



From jannis at leidel.info  Sun Jul 19 18:46:53 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Sun, 19 Jul 2009 18:46:53 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
Message-ID: <E84A7B8E-6F2B-41C2-BF29-209F3D913E95@leidel.info>

>> Note that the primary package name that the "distribute"  
>> distribution embeds is still named "setuptools" at this point, for  
>> better or worse.  I don't know how long this will be true, but it's  
>> still true right now, and I suspect it won't change before the  
>> first release.  That may be another can of worms, but at this point  
>> it's probably not worth losing any sleep over.
>>
>> In any case, changing the distribution name ("distribute"  
>> currently) is pretty trivial in comparison to changing a package  
>> name because imports don't need to change.  I'd begin to get more  
>> nervous when the package names change. ;-)
>
> Also, this entire discussion may be moot if, as I'm currently  
> understanding it, this is simply a matter of other people doing  
> maintenance and bug fixes to the 0.6 branch...  in which case there  
> is a very strong possibility that I'll just bless various versions  
> of it as official 0.6 versions of setuptools.
>
> (One obstacle to this actually happening, though, is the part where  
> they're stripping out my release tools, like wikiup.cfg, version 
> +version.dat, etc., as I would need to add these back in order to  
> actually do a release.)

If you'd bless distribute as one of setuptools versions, wouldn't it  
be a perfect moment to move its documentation away from the (often  
slow) PEAK wiki, use a Sphinx build (as already worked out in the  
setuptools-0.6 branch) and publish it on http://packages.python.org/setuptools/? 
  There is even a useful setup.py command to help publishing it: http://pypi.python.org/pypi/Sphinx-PyPI-upload/

Best,
Jannis


From mihamina at gulfsat.mg  Sun Jul 19 18:57:08 2009
From: mihamina at gulfsat.mg (Rakotomandimby Mihamina)
Date: Sun, 19 Jul 2009 19:57:08 +0300
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <319e029f0907190237l2c3cd3ack86c865558dbb979d@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>	<87my72d8wt.fsf@benfinney.id.au>
	<4A61355E.50706@plope.com>	<87eised550.fsf@benfinney.id.au>
	<4A6154B0.6000707@plope.com>	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>	<20090719022831.959983A403A@sparrow.telecommunity.com>	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<319e029f0907190237l2c3cd3ack86c865558dbb979d@mail.gmail.com>
Message-ID: <4A635064.6010802@gulfsat.mg>

07/19/2009 12:37 PM, Lennart Regebro:
> If it is, everybody is just going to ignore it. Except that we may
> fork useful bits if licensing allows. It's not a problem, it's just
> that it would be better if this didn't happen.

Agreed.

-- 
                             Architecte Informatique:
    Administration Systeme, Recherche & Developpement
                                   + 261 32 11 401 65
Pensez a l'environnement avant d'imprimer ce message

From ianb at colorstudy.com  Sun Jul 19 19:28:54 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Sun, 19 Jul 2009 12:28:54 -0500
Subject: [Distutils] idea - keeping package index code (in pip,
	distribute) separate
In-Reply-To: <op.uw9yrriz1q4jlt@whymac>
References: <op.uw9yrriz1q4jlt@whymac>
Message-ID: <b654cd2e0907191028g4d9575fama46072f9e9069e56@mail.gmail.com>

On Sat, Jul 18, 2009 at 12:56 PM, Sridhar Ratnakumar <
sridharr at activestate.com> wrote:

> Both easy_install and pip uses similar method to find download URLs for
> packages. They are not very unreliable - see the new issues in Distribute
> tracker:
>
>  http://bitbucket.org/tarek/distribute/issues/?status=new&reported_by=srid
>
> Hence I suggest that we create a separate project containing just this
> indexing code .. and let Distribute and pip use it via install_requires.
> Thoughts?
>

pip won't require any installer, or have any dependencies, because that
would be too cruel to users.  Potentially pip could include code via a build
process (what virtualenv does for few things), but the code would have to be
small and light.  And I'm not sure if the code would be acceptable even
then.  pip's code for finding packages includes a lot of logging (using
pip's logging system) and I wouldn't replace it with something that had less
functionality.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090719/ab35f335/attachment.htm>

From pje at telecommunity.com  Sun Jul 19 20:55:25 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 19 Jul 2009 14:55:25 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com
 >
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
Message-ID: <20090719185220.C15EE3A40D9@sparrow.telecommunity.com>

At 11:12 AM 7/19/2009 +0200, Tarek Ziad? wrote:
>That's very interesting but you previously said that you needed time
>and/or someone
>paying you to continue the work in this area.

No, I said that was needed to get me to work on *setuptools*.  Since 
you guys are doing that for me now, I don't have to think about all 
the hard, boring work that I felt I had to do first.  ;-)

If I do "Discovery" at all, it will be because it's fun and pleasing 
to me, without all the nasty stuff I didn't want to think about 
needing to be done first.  I've wanted to do this sort of refactoring 
for some time, but felt like I had to take care of stability and all 
that first.

I'm actually kind of hoping that if I make Discovery nice enough, 
somebody else will refactor setuptools to use it.  ;-)  (Or just 
replace setuptools with something better.)


>So are you willing to bless us maintaining/working with you with these
>new packages,
>or is that going to be a PJE-locked thing again ?

I would suggest that you not try to make plans based on what I am or 
am not doing, until and unless I've already done it.  That way, you 
can't be disappointed.  Since this will be a fun/hobby project for 
me, I am not at this making ANY commitments about when, what, or 
how.  I do expect to be using Mercurial, though, and accepting 
feature patches as well as bug fixes.


>just a question :
> > discovery.unpack -- setuptools.archive_util, less distutils dependency
>
>how this will be 'less distutils dependent' ?

I want discovery to have as close to zero dependence on distutils as 
possible because some OS distributors like to split out "development" 
tools and I'd prefer they not split up Discovery because it imports 
from distutils.  So if possible, I would like Discovery to be 100% 
self-contained -- which means not importing distutils.error, 
distutils.log, etc., or at least having a fallback in the event those 
modules can't be imported (due to a python-devel package being missing).


From pje at telecommunity.com  Sun Jul 19 20:56:48 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 19 Jul 2009 14:56:48 -0400
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <E84A7B8E-6F2B-41C2-BF29-209F3D913E95@leidel.info>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>
	<4A5FDE57.4060207@canterbury.ac.nz>
	<878winhcny.fsf_-_@benfinney.id.au>
	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>
	<87r5wffsdz.fsf@benfinney.id.au>
	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<E84A7B8E-6F2B-41C2-BF29-209F3D913E95@leidel.info>
Message-ID: <20090719185342.6A09C3A40D9@sparrow.telecommunity.com>

At 06:46 PM 7/19/2009 +0200, Jannis Leidel wrote:
>If you'd bless distribute as one of setuptools versions, wouldn't it
>be a perfect moment to move its documentation away from the (often
>slow) PEAK wiki,

It's fast now, actually.  I fixed it a couple days ago when I 
couldn't sleep.  I'd long meant to set up a mod_rewrite-based cache 
for the long, dynamically-generated pages.


>use a Sphinx build (as already worked out in the
>setuptools-0.6 branch) and publish it on 
>http://packages.python.org/setuptools/?  There is even a useful 
>setup.py command to help publishing it: 
>http://pypi.python.org/pypi/Sphinx-PyPI-upload/

Hm.  Maybe I should just let you guys take over the thing entirely 
and do the releases however you like.  More free time for me.  ;-)


From pje at telecommunity.com  Sun Jul 19 21:14:08 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 19 Jul 2009 15:14:08 -0400
Subject: [Distutils] Distutils 2.7/3.1 and setuptools stack overflow
In-Reply-To: <4A632068.3020700@v.loewis.de>
References: <4A632068.3020700@v.loewis.de>
Message-ID: <20090719191103.7122D3A40D9@sparrow.telecommunity.com>

At 03:32 PM 7/19/2009 +0200, Martin v. L?wis wrote:
>Hi Phillip,
>
>I have investigated the problem of mutual recursion between setuptools
>and distutils a little. I read a message somewhere that you didn't
>understand the problem, so here is my analysis:
>
>1. build_py.data_files gets accessed, and is delayed-computed in
>    setuptools
>2. build_py tries to load the manifest, and goes to egg_info for that
>3. egg_info invokes add_defaults for the manifest
>4. manifest_maker.add_defaults invokes sdist.add_defaults
>5. in response to issue 2279, add_defaults now also adds build_py
>    data_files and package_data to the default files.
>
>As a work-around, I have now copied the 2.6 code of sdist.add_defaults
>into manifest_maker.sdist_add_defaults.

I don't understand.  Where did you do this?  In setuptools or distutils?


>In the long run, I think setuptools should revise its computation of
>data_files. Couldn't you simply use distutils' get_data_files()?

Setuptools supports an 'include_package_data' option that 
automatically includes any revision-controlled files found in package 
directories.  Distutils doesn't.  The somewhat-recursive aspect is 
that when an sdist is used instead of a checkout, the previous 
revision control info is not available, so setuptools must use the 
previously-computed list of included files in order to find out which 
files are "package data".

It's possible that this could be resolved in some other way, but IIUC 
Tarek has already implemented a setuptools patch to fix this, which 
has been applied to the "Distribute" fork of setuptools.  I am 
seriously considering simply blessing that fork *as* setuptools, at 
least with respect to the 0.6 maintenance branch, and turning over 
its stewardship to the Package Inquisition, or whatever they're 
calling themselves.  ;-)

("The Society For Packaging Things On Top Of Other Things" would 
probably be another good Monty Python-inspired name for the group.)


From regebro at gmail.com  Sun Jul 19 21:13:25 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 19 Jul 2009 21:13:25 +0200
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
Message-ID: <319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>

2009/7/19 P.J. Eby <pje at telecommunity.com>:
> I'm actually kind of hoping that if I make Discovery nice enough, somebody
> else will refactor setuptools to use it. ?;-) ?(Or just replace setuptools
> with something better.)

We hope that too. But we don't think Discovery will be nice enough if
only you work on it. That is after all the greatness of open source:
It enables people from all around the world cooperate to make
something much greater than each one can create by himself. We can
sure use your experience, insight and help. And you can use our work
time. Discovery can become way greater if we work together instead of
each by ourself.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Sun Jul 19 21:34:03 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 19 Jul 2009 21:34:03 +0200
Subject: [Distutils] Distutils 2.7/3.1 and setuptools stack overflow
In-Reply-To: <20090719191103.7122D3A40D9@sparrow.telecommunity.com>
References: <4A632068.3020700@v.loewis.de>
	<20090719191103.7122D3A40D9@sparrow.telecommunity.com>
Message-ID: <94bdd2610907191234k6459d8e4r2d7f9ea2e82f5fb8@mail.gmail.com>

On Sun, Jul 19, 2009 at 9:14 PM, P.J. Eby<pje at telecommunity.com> wrote:
> It's possible that this could be resolved in some other way, but IIUC Tarek
> has already implemented a setuptools patch to fix this, which has been
> applied to the "Distribute" fork of setuptools.

Yes I came up with the same analysis, and I have applied the same fix
Martin is mentioning in
Distribute, which is also the latest patch added in setuptools tracker
some times ago.

From sridharr at activestate.com  Sun Jul 19 21:50:34 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sun, 19 Jul 2009 12:50:34 -0700
Subject: [Distutils] Fork mess
In-Reply-To: <319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
Message-ID: <op.uxbyqkl71q4jlt@whymac>

On Sun, 19 Jul 2009 12:13:25 -0700, Lennart Regebro <regebro at gmail.com>  
wrote:

> 2009/7/19 P.J. Eby <pje at telecommunity.com>:
>> I'm actually kind of hoping that if I make Discovery nice enough,  
>> somebody
>> else will refactor setuptools to use it.  ;-)  (Or just replace  
>> setuptools
>> with something better.)
> We hope that too. But we don't think Discovery will be nice enough if
> only you work on it. That is after all the greatness of open source:
> It enables people from all around the world cooperate to make
> something much greater than each one can create by himself. We can
> sure use your experience, insight and help. And you can use our work
> time. Discovery can become way greater if we work together instead of
> each by ourself.

+1

I'm already sensing some vague inconvenience .. distutils, setuptools,  
Distribute, Discovery??? Too much for a language that boasts about having  
only one obvious way to do it.

Is it not sensible to combine the efforts put into Distribute and  
Discovery? Call Discovery 'Distribute 2.0' (future work) while we work on  
stabilizing setuptools as Distribute 1.0?

If it was me - I'd certainly do it and that wouldn't jeopardize the  
potential fun involved.

-srid


From martin at v.loewis.de  Sun Jul 19 22:02:19 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 19 Jul 2009 22:02:19 +0200
Subject: [Distutils] Distutils 2.7/3.1 and setuptools stack overflow
In-Reply-To: <20090719191103.7122D3A40D9@sparrow.telecommunity.com>
References: <4A632068.3020700@v.loewis.de>
	<20090719191103.7122D3A40D9@sparrow.telecommunity.com>
Message-ID: <4A637BCB.2000701@v.loewis.de>

>> I have investigated the problem of mutual recursion between setuptools
>> and distutils a little. I read a message somewhere that you didn't
>> understand the problem, so here is my analysis:
>>
>> 1. build_py.data_files gets accessed, and is delayed-computed in
>>    setuptools
>> 2. build_py tries to load the manifest, and goes to egg_info for that
>> 3. egg_info invokes add_defaults for the manifest
>> 4. manifest_maker.add_defaults invokes sdist.add_defaults
>> 5. in response to issue 2279, add_defaults now also adds build_py
>>    data_files and package_data to the default files.
>>
>> As a work-around, I have now copied the 2.6 code of sdist.add_defaults
>> into manifest_maker.sdist_add_defaults.
> 
> I don't understand.  Where did you do this?  In setuptools or distutils?

In setuptools, more precisely, in the manifest_maker class.

>> In the long run, I think setuptools should revise its computation of
>> data_files. Couldn't you simply use distutils' get_data_files()?
> 
> Setuptools supports an 'include_package_data' option that automatically
> includes any revision-controlled files found in package directories. 
> Distutils doesn't.  The somewhat-recursive aspect is that when an sdist
> is used instead of a checkout, the previous revision control info is not
> available, so setuptools must use the previously-computed list of
> included files in order to find out which files are "package data".

So how does that interwork with the list of data files specified in
an explicit package_data setting of setup.py?

Also, if all it wants is to compute the list of version-controlled
files, and deduce data_files from that, why does it have to go through
the manifest computation?

> It's possible that this could be resolved in some other way, but IIUC
> Tarek has already implemented a setuptools patch to fix this, which has
> been applied to the "Distribute" fork of setuptools.

I found that patch afterwards. It is similar to mine, except that he
modifies setuptools' sdist class, instead of manifest_maker. So my
change is less intrusive, but his change possibly fixes other cases
as well.

Regards,
Martin

From pje at telecommunity.com  Sun Jul 19 22:08:01 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 19 Jul 2009 16:08:01 -0400
Subject: [Distutils] Fork mess
In-Reply-To: <op.uxbyqkl71q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
Message-ID: <20090719200456.9E9193A411C@sparrow.telecommunity.com>

At 12:50 PM 7/19/2009 -0700, Sridhar Ratnakumar wrote:
>On Sun, 19 Jul 2009 12:13:25 -0700, Lennart Regebro <regebro at gmail.com>
>wrote:
>
>>2009/7/19 P.J. Eby <pje at telecommunity.com>:
>>>I'm actually kind of hoping that if I make Discovery nice enough,
>>>somebody
>>>else will refactor setuptools to use it.  ;-)  (Or just replace
>>>setuptools
>>>with something better.)
>>We hope that too. But we don't think Discovery will be nice enough if
>>only you work on it. That is after all the greatness of open source:
>>It enables people from all around the world cooperate to make
>>something much greater than each one can create by himself. We can
>>sure use your experience, insight and help. And you can use our work
>>time. Discovery can become way greater if we work together instead of
>>each by ourself.
>
>+1
>
>I'm already sensing some vague inconvenience .. distutils, setuptools,
>Distribute, Discovery??? Too much for a language that boasts about having
>only one obvious way to do it.
>
>Is it not sensible to combine the efforts put into Distribute and
>Discovery? Call Discovery 'Distribute 2.0' (future work) while we work on
>stabilizing setuptools as Distribute 1.0?
>
>If it was me - I'd certainly do it and that wouldn't jeopardize the
>potential fun involved.

Already, just this bit where strangers on the internet discuss how I 
should spend my spare time for their benefit is making the whole idea 
less fun.  If people want to tell me how I should spend my time, they 
can pay me.  (Otherwise, they can ask nicely, instead of lecturing.)


From sridharr at activestate.com  Sun Jul 19 23:30:57 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sun, 19 Jul 2009 14:30:57 -0700
Subject: [Distutils] Fork mess
In-Reply-To: <20090719200456.9E9193A411C@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
Message-ID: <op.uxb3dvmo1q4jlt@whymac>

On Sun, 19 Jul 2009 13:08:01 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> At 12:50 PM 7/19/2009 -0700, Sridhar Ratnakumar wrote:
>> If it was me - I'd certainly do it and that wouldn't jeopardize the
>> potential fun involved.
>
> Already, just this bit where strangers on the internet discuss how I  
> should spend my spare time for their benefit is making the whole idea  
> less fun.  If people want to tell me how I should spend my time, they  
> can pay me.  (Otherwise, they can ask nicely, instead of lecturing.)

Ok. As this thread was primarily started to discuss about the various  
projects (current and potential) we are going through at the moment and  
their implications on the Python community (not just a particular  
individual), do you have something to add to the quoted message below?

> At 12:50 PM 7/19/2009 -0700, Sridhar Ratnakumar wrote:
>> I'm already sensing some vague inconvenience .. distutils, setuptools,
>> Distribute, Discovery??? Too much for a language that boasts about  
>> having
>> only one obvious way to do it.
>>
>> Is it not sensible to combine the efforts put into Distribute and
>> Discovery? Call Discovery 'Distribute 2.0' (future work) while we work  
>> on
>> stabilizing setuptools as Distribute 1.0?


-srid

From regebro at gmail.com  Sun Jul 19 23:48:40 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 19 Jul 2009 23:48:40 +0200
Subject: [Distutils] Fork mess
In-Reply-To: <20090719200456.9E9193A411C@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
Message-ID: <319e029f0907191448w342d0633j90d567a7c5d06d59@mail.gmail.com>

2009/7/19 P.J. Eby <pje at telecommunity.com>:
> Already, just this bit where strangers on the internet discuss how I should
> spend my spare time for their benefit is making the whole idea less fun. ?If
> people want to tell me how I should spend my time, they can pay me.
> ?(Otherwise, they can ask nicely, instead of lecturing.)

I don't know if this was also aimed at me or not, but if, i would
point out that my intention was to ask, or maybe rather beg, nicely.
:)

What you *should* do is after all whatever you feel is most likely to
improve your well being.

Again, should you choose to build this by yourself, that is in no way a problem.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From lists at zopyx.com  Mon Jul 20 07:11:21 2009
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 20 Jul 2009 07:11:21 +0200
Subject: [Distutils] Fork mess
In-Reply-To: <4A63F79A.8060301@gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<87my72d8wt.fsf@benfinney.id.au>
	<4A61355E.50706@plope.com>	<87eised550.fsf@benfinney.id.au>
	<4A6154B0.6000707@plope.com>	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>	<20090719022831.959983A403A@sparrow.telecommunity.com>	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
	<4A63F79A.8060301@gmail.com>
Message-ID: <4A63FC79.6090402@zopyx.com>

On 19.07.09 22:08, P.J. Eby wrote:

> > At 12:50 PM 7/19/2009 -0700, Sridhar Ratnakumar wrote:
>   
>> >> On Sun, 19 Jul 2009 12:13:25 -0700, Lennart Regebro <regebro at gmail.com>
>> >> wrote:
>> >>
>>     
>>> >>> 2009/7/19 P.J. Eby <pje at telecommunity.com>:
>>>       
>>>> >>>> I'm actually kind of hoping that if I make Discovery nice enough,
>>>> >>>> somebody
>>>> >>>> else will refactor setuptools to use it.  ;-)  (Or just replace
>>>> >>>> setuptools
>>>> >>>> with something better.)
>>>>         
>>> >>> We hope that too. But we don't think Discovery will be nice enough if
>>> >>> only you work on it. That is after all the greatness of open source:
>>> >>> It enables people from all around the world cooperate to make
>>> >>> something much greater than each one can create by himself. We can
>>> >>> sure use your experience, insight and help. And you can use our work
>>> >>> time. Discovery can become way greater if we work together instead of
>>> >>> each by ourself.
>>>       
>> >>
>> >> +1
>> >>
>> >> I'm already sensing some vague inconvenience .. distutils, setuptools,
>> >> Distribute, Discovery??? Too much for a language that boasts about
>> >> having
>> >> only one obvious way to do it.
>> >>
>> >> Is it not sensible to combine the efforts put into Distribute and
>> >> Discovery? Call Discovery 'Distribute 2.0' (future work) while we
>> >> work on
>> >> stabilizing setuptools as Distribute 1.0?
>> >>
>> >> If it was me - I'd certainly do it and that wouldn't jeopardize the
>> >> potential fun involved.
>>     
> >
> > Already, just this bit where strangers on the internet discuss how I
> > should spend my spare time for their benefit is making the whole idea
> > less fun.  If people want to tell me how I should spend my time, they
> > can pay me.  (Otherwise, they can ask nicely, instead of lecturing.)
>   
Nobody cares about how you spend your spare time. The point is that the
maintainer is sitting like a clucking hen on their eggs without
giving them any care and without letting other people care about them.
So we are at the point where the hen must go in order to save the eggs
or it must be shot in order proceed for the sake of the community. The
discussion about a qualified maintainer is just absurd. All people
involved in this issue for bring setuptools forward have a strong record
in managing packages and a deep understanding in the setuptools problem.
Please don't treat highly respected members of the Zope and Plone world
like idiots.

Andreas


-- 
ZOPYX Ltd. & Co KG          \  ZOPYX & Friends
Charlottenstr. 37/1          \  The experts for your Python, Zope and
D-72070 T?bingen              \  Plone projects
www.zopyx.com, info at zopyx.com  \  www.zopyx.de/friends, friends at zopyx.de
------------------------------------------------------------------------
E-Publishing, Python, Zope & Plone development, Consulting


-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090720/6e422cc0/attachment.vcf>

From jim at zope.com  Mon Jul 20 12:48:50 2009
From: jim at zope.com (Jim Fulton)
Date: Mon, 20 Jul 2009 06:48:50 -0400
Subject: [Distutils] Fork mess
In-Reply-To: <4A63FC79.6090402@zopyx.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
	<4A63F79A.8060301@gmail.com> <4A63FC79.6090402@zopyx.com>
Message-ID: <1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>

On Mon, Jul 20, 2009 at 1:11 AM, Andreas Jung<lists at zopyx.com> wrote:
> Please don't treat highly respected members of the Zope and Plone world
> like idiots.

Please show the person who actually gave us a working packaging system
more respect.

Jim

-- 
Jim Fulton

From chris at simplistix.co.uk  Mon Jul 20 12:59:27 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 20 Jul 2009 11:59:27 +0100
Subject: [Distutils] Fork mess
In-Reply-To: <1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>	<20090719022831.959983A403A@sparrow.telecommunity.com>	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>	<op.uxbyqkl71q4jlt@whymac>	<20090719200456.9E9193A411C@sparrow.telecommunity.com>	<4A63F79A.8060301@gmail.com>
	<4A63FC79.6090402@zopyx.com>
	<1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
Message-ID: <4A644E0F.4070400@simplistix.co.uk>

Jim Fulton wrote:
> On Mon, Jul 20, 2009 at 1:11 AM, Andreas Jung<lists at zopyx.com> wrote:
>> Please don't treat highly respected members of the Zope and Plone world
>> like idiots.
> 
> Please show the person who actually gave us a working packaging system
> more respect.

Working, except for the bugs and the stubborn refusal to let anyone help 
fix them without forking the project...

Chris

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

From lists at zopyx.com  Mon Jul 20 13:28:42 2009
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 20 Jul 2009 13:28:42 +0200
Subject: [Distutils] Fork mess
In-Reply-To: <1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>	
	<20090719022831.959983A403A@sparrow.telecommunity.com>	
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>	
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>	
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>	
	<op.uxbyqkl71q4jlt@whymac>	
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>	
	<4A63F79A.8060301@gmail.com> <4A63FC79.6090402@zopyx.com>
	<1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
Message-ID: <4A6454EA.2060808@zopyx.com>

On 20.07.09 12:48, Jim Fulton wrote:
> On Mon, Jul 20, 2009 at 1:11 AM, Andreas Jung<lists at zopyx.com> wrote:
>   
>> Please don't treat highly respected members of the Zope and Plone world
>> like idiots.
>>     
> Please show the person who actually gave us a working packaging system
> more respect.
I do respect his work on setuptools.
I do not respect all the circumstances that led to the necessary fork.

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090720/54850759/attachment.vcf>

From regebro at gmail.com  Mon Jul 20 13:36:17 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 20 Jul 2009 13:36:17 +0200
Subject: [Distutils] Fork mess
In-Reply-To: <1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
	<4A63F79A.8060301@gmail.com> <4A63FC79.6090402@zopyx.com>
	<1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
Message-ID: <319e029f0907200436h59355405p887c868845598d72@mail.gmail.com>

2009/7/20 Jim Fulton <jim at zope.com>:
> On Mon, Jul 20, 2009 at 1:11 AM, Andreas Jung<lists at zopyx.com> wrote:
>> Please don't treat highly respected members of the Zope and Plone world
>> like idiots.
>
> Please show the person who actually gave us a working packaging system
> more respect.

I agree with both these statements. In general, and that's one of the
reasons that I promised myself never to join this list again, I feel
that packaging discussions have a tendency to be severely lacking in
both mutual respect and ability to listen to others. This is not
limited to this list, and it seems to affect people who are normally
the friendliest ever.

I don't know why that is, and I don't know if we can do something about it.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From frank.hoffsummer at gmail.com  Mon Jul 20 15:45:03 2009
From: frank.hoffsummer at gmail.com (=?ISO-8859-1?Q?Frank_Hoffs=FCmmer?=)
Date: Mon, 20 Jul 2009 15:45:03 +0200
Subject: [Distutils] exclude a module,
	or can setuptools honor svn:ignore flag?
Message-ID: <60fae7c30907200645y22c9f240q738eb2369398cd51@mail.gmail.com>

Hello
I have a python project, 'myproject', that contains several packages. one of
those packages, 'myproject.settings', contains a module
'myproject.settings.local' that is excluded from version control via
'svn:ignore' property.
I would like setuptools to ignore this file when making a bdist or bdist_egg
target.
I have experimented with find_packages(exclude..) to no avail. Ideally I was
hoping that only files that are not ignored by svn would be included.
Is there a way to achieve the exclusion of my module? I am on a patched (
http://bugs.python.org/setuptools/issue64) version of setuptools trunk, with
subversion 1.6.
thanks for any insight you might have
-frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090720/daeac105/attachment.htm>

From pje at telecommunity.com  Mon Jul 20 20:28:37 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 20 Jul 2009 14:28:37 -0400
Subject: [Distutils] exclude a module,
 or can setuptools honor  svn:ignore flag?
In-Reply-To: <60fae7c30907200645y22c9f240q738eb2369398cd51@mail.gmail.co
 m>
References: <60fae7c30907200645y22c9f240q738eb2369398cd51@mail.gmail.com>
Message-ID: <20090720182532.779803A40D9@sparrow.telecommunity.com>

At 03:45 PM 7/20/2009 +0200, Frank Hoffs?mmer wrote:
>Hello
>I have a python project, 'myproject', that contains several 
>packages. one of those packages, 'myproject.settings', contains a 
>module 'myproject.settings.local' that is excluded from version 
>control via 'svn:ignore' property.
>I would like setuptools to ignore this file when making a bdist or 
>bdist_egg target.
>I have experimented with find_packages(exclude..) to no avail. 
>Ideally I was hoping that only files that are not ignored by svn 
>would be included.
>Is there a way to achieve the exclusion of my module? I am on a 
>patched 
>(<http://bugs.python.org/setuptools/issue64>http://bugs.python.org/setuptools/issue64) 
>version of setuptools trunk, with subversion 1.6.
>thanks for any insight you might have
>-frank

You might be able to use an exclusion rule in MANIFEST.in... but I 
think it would probably only affect an sdist.  You'd then have to 
build from the sdist to get it to exclude.  This is certainly 
something that should be fixed in setuptools.


From techtonik at gmail.com  Mon Jul 20 20:56:49 2009
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 20 Jul 2009 14:56:49 -0400
Subject: [Distutils] Distutils cookbook or how to specify a dependency?
Message-ID: <d34314100907201156q4a7ea0fcw1ca81074f70c3d48@mail.gmail.com>

Hello,

I've noticed there is a Cookbook dedicated to distutils at
http://wiki.python.org/moin/Distutils/Cookbook

It looks a little deserted, so before asking to include my own
specific problem into this Cookbook I would like to ask if developers
are interested in using Cookbook approach as a supplement to a PEP.
PEPs are good at presenting a solution, but bad at collecting primary
information for testing the proposal. For example, most of us would
like to see setuptools distributed with Python instead of downloading
bootstrap script again and again. But there is already distutils
module, so we should concentrate on enhancing it instead. But there is
another but - distutils can not be enhanced, because... (well, why?)
... I can only suggest that distutils can not be enhanced, because it
needs serious redesign, because it lacks too many features and there
is a fear that redesign can break existing API and nobody can step in,
because it is all the way too complex.

But if there was a primary Cookbook page with listing of all the tasks
you need distutils for and tasks you need setuptools for, it will be
possible to port feature-by-feature. Having such page may save some
time and present a tutorial and a reference for people who
occasionally use setuptools to distribute their application without
wasting too much time studying all the gory details of
distutils/setuptools API. I've noticed that many developers find it
hard to find an entrypoint into proper way to distribute their
apps/modules, because of the lack of time. Don't you think that
documentation for these people is something to be considered more
seriously than PEP implementation or even the primary thing to start
with?


As for my specific problem - is there a way to specify dependency
required to _install_ a package, so that easy_install would download
that dependency prior to executing setup.py?


--anatoly t.

From tseaver at palladion.com  Mon Jul 20 21:11:05 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 20 Jul 2009 15:11:05 -0400
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>	<5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
	<94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
Message-ID: <h42fga$cna$1@ger.gmane.org>

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

Tarek Ziad? wrote:
> On Fri, Jul 17, 2009 at 11:50 AM, Hanno Schlichting<hanno at hannosch.eu> wrote:
>> Hi.
>>
>> On Fri, Jul 17, 2009 at 2:07 AM, David Lyon<david.lyon at preisshare.net> wrote:
>>> If I find anymore issues I can post them to there instead of the
>>> mailing list.
>> Our bug tracker is open for submission by anyone. It's not a magical
>> thing though. So the same rules about good bug reports, repeatable
>> steps, preferably patches with tests and so on apply. Meta questions
>> and general observations about controversial issues are as likely to
>> get a non-optimal treatment as everywhere else ;)
>>
>>> Somebody should update the easy_install web site to direct users
>>> to post to the tracker and not to the mailing list.
>> We'll update the documentation soon. We will need to find a new place
>> to put the documentation for this fork, though.
> 
> Let's create a Sphinx-based website. I can host it on my server. As
> soon as the name is chosen, we can set a domain
> name too.
> 
> We can start to build the sphinx-based doc in the docs/ directory.

Why not put it in the "standard" package docs location, e.g.:

 http://packages.python.org/distribute

(or however the name is spelled).

See for instance:

 http://packages.python.org/repoze.urispace/


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKZMFJ+gerLs4ltQ4RAtUmAKCJQbz2nsJf0rotMQviqM77j2ZxogCgzFke
NTMvNK496aiGe9v28r6iW1Y=
=1yvb
-----END PGP SIGNATURE-----


From tseaver at palladion.com  Mon Jul 20 21:16:23 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 20 Jul 2009 15:16:23 -0400
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
Message-ID: <h42fq9$irq$1@ger.gmane.org>

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

Tarek Ziad? wrote:

> When Python 2.7/3.2 are out, I am planning to release a standalone
> version of Distutils that will work starting at 2.5.
> Which means that the 0.7 series of Distribute will be able to work with it.

I still haven't heard a clear story about how you think people will be
able to install that standalone version without manually hacking up
their /usr/lib/python2.x/ directories.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKZMKH+gerLs4ltQ4RAq+dAKDM+5ZOTrsv9X89+1ERmOxAI/OTKgCeJWbr
0ldMtMmeJcJVIzeAgY6P5T8=
=7S7x
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Mon Jul 20 21:28:46 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 20 Jul 2009 15:28:46 -0400
Subject: [Distutils] Fork mess
In-Reply-To: <319e029f0907200436h59355405p887c868845598d72@mail.gmail.co
 m>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
	<4A63F79A.8060301@gmail.com> <4A63FC79.6090402@zopyx.com>
	<1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
	<319e029f0907200436h59355405p887c868845598d72@mail.gmail.com>
Message-ID: <20090720192541.E48083A40D9@sparrow.telecommunity.com>

At 01:36 PM 7/20/2009 +0200, Lennart Regebro wrote:
>I feel that packaging discussions have a tendency to be severely lacking in
>both mutual respect and ability to listen to others. This is not
>limited to this list, and it seems to affect people who are normally
>the friendliest ever.

NOONE expects the Package Inquisition!  Our chief weapon is 
surprise...  surprise and fear...  and a fanatical devotion to the Linux HFS...

Too bad we don't get the nice red uniforms.  ;-)


From regebro at gmail.com  Mon Jul 20 21:27:22 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 20 Jul 2009 21:27:22 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <h42fq9$irq$1@ger.gmane.org>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
	<h42fq9$irq$1@ger.gmane.org>
Message-ID: <319e029f0907201227q632c27e8i23c46e7321612b27@mail.gmail.com>

2009/7/20 Tres Seaver <tseaver at palladion.com>:
> I still haven't heard a clear story about how you think people will be
> able to install that standalone version without manually hacking up
> their /usr/lib/python2.x/ directories.

Me neither. But then again, I figured that if this actually becomes a
problem, renaming this is relatively trivial. And if it becomes a
problem (and I don't see how it would not) it's easier to argue for a
rename from practical problems than hypothetical ones.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Mon Jul 20 21:28:35 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 20 Jul 2009 21:28:35 +0200
Subject: [Distutils] Fork mess
In-Reply-To: <20090720192541.E48083A40D9@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
	<4A63F79A.8060301@gmail.com> <4A63FC79.6090402@zopyx.com>
	<1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
	<319e029f0907200436h59355405p887c868845598d72@mail.gmail.com>
	<20090720192541.E48083A40D9@sparrow.telecommunity.com>
Message-ID: <319e029f0907201228p50490730nb144a1f2eaa15603@mail.gmail.com>

2009/7/20 P.J. Eby <pje at telecommunity.com>:
> At 01:36 PM 7/20/2009 +0200, Lennart Regebro wrote:
>>
>> I feel that packaging discussions have a tendency to be severely lacking
>> in
>> both mutual respect and ability to listen to others. This is not
>> limited to this list, and it seems to affect people who are normally
>> the friendliest ever.
>
> NOONE expects the Package Inquisition! ?Our chief weapon is surprise...
> ?surprise and fear... ?and a fanatical devotion to the Linux HFS...
>
> Too bad we don't get the nice red uniforms. ?;-)

Maybe they can be charged as business expenses? :-)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From barry at python.org  Mon Jul 20 21:52:21 2009
From: barry at python.org (Barry Warsaw)
Date: Mon, 20 Jul 2009 15:52:21 -0400
Subject: [Distutils] Fork mess
In-Reply-To: <20090720192541.E48083A40D9@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>
	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>
	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>
	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
	<4A63F79A.8060301@gmail.com> <4A63FC79.6090402@zopyx.com>
	<1099b90b0907200348m117602e1k7e4dbd9545f93b19@mail.gmail.com>
	<319e029f0907200436h59355405p887c868845598d72@mail.gmail.com>
	<20090720192541.E48083A40D9@sparrow.telecommunity.com>
Message-ID: <97702E4D-7008-4900-A246-92F52BB8E70A@python.org>

On Jul 20, 2009, at 3:28 PM, P.J. Eby wrote:

> NOONE expects the Package Inquisition!  Our chief weapon is  
> surprise...  surprise and fear...  and a fanatical devotion to the  
> Linux HFS...

PJE, you definitely win the award for Best Quote EVAR. :)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090720/8527f2e4/attachment.pgp>

From sridharr at activestate.com  Mon Jul 20 22:26:44 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 20 Jul 2009 13:26:44 -0700
Subject: [Distutils] extending PKG-INFO .. or having a standard/library for
 reading setuptools' metadata
In-Reply-To: <20090719022831.959983A403A@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
Message-ID: <op.uxdu2umu1q4jlt@whymac.activestate.com>

On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> discovery.resources -- basically pkg_resources under a different name

It may also be worth adding support for parsing the files under .egg-info  
- for instance, those 'extras' in requires.txt. Currently, even pip  
hardcodes the parsing of requires.txt and I believe there isn't code in  
setuptools to parse this file (so easy_install uses setup.py' setup()  
arguments?).

Or even better .. extend PKG-INFO with setuptools' style requires list and  
entry points.

Please don't suggest to parse setup.py or its output (which is messy with  
all those warning messages in stdout, for instance).

-srid

From exarkun at divmod.com  Mon Jul 20 23:55:49 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Mon, 20 Jul 2009 17:55:49 -0400
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: 0
Message-ID: <20090720215549.2543.2032939927.divmod.quotient.3791@henry.divmod.com>

Hello all,

I'm trying to figure out how to include some extra DLLs which are required
by an extension module I'm trying to package (pyOpenSSL).

>From what I can tell, the DLLs need to be in the same directory as the
extension modules themselves (the .pyd files).  Does anyone know if this
is the best place for them?

Based on my current understanding, I've used the data_files feature of
distutils to put the DLLs into site-packages/OpenSSL/.  This works fine for
bdist_msi (and I hope bdist_exe, though I haven't checked that yet).  However,
bdist_egg has tripped me up.  The path given in data_files is interpreted
relative to the egg itself.  This differs from the interpretation of those
values by the other bdist_ commands.

Here are the actual values I'm using:

  data_files = [('Lib\\site-packages\\OpenSSL',
                 ['C:\\OpenSSL\\ssleay32.dll',
                  'C:\\OpenSSL\\libeay32.dll'])]

How can I get these files into the right place for bdist_egg?

Jean-Paul

From ziade.tarek at gmail.com  Tue Jul 21 00:23:12 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 21 Jul 2009 00:23:12 +0200
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <h42fq9$irq$1@ger.gmane.org>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>
	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>
	<h42fq9$irq$1@ger.gmane.org>
Message-ID: <94bdd2610907201523g1b977d4cwa81eb535a7c8e5a2@mail.gmail.com>

On Mon, Jul 20, 2009 at 9:16 PM, Tres Seaver<tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>
>> When Python 2.7/3.2 are out, I am planning to release a standalone
>> version of Distutils that will work starting at 2.5.
>> Which means that the 0.7 series of Distribute will be able to work with it.
>
> I still haven't heard a clear story about how you think people will be
> able to install that standalone version without manually hacking up
> their /usr/lib/python2.x/ directories.

With a special .pth file that superseds the stdlib distutils path in sys.path
you can try it out by installing the nighlty build

http://nightly.ziade.org/

From tseaver at palladion.com  Tue Jul 21 00:29:42 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 20 Jul 2009 18:29:42 -0400
Subject: [Distutils] [Distribute] What versions should we support?
In-Reply-To: <94bdd2610907201523g1b977d4cwa81eb535a7c8e5a2@mail.gmail.com>
References: <319e029f0907161357y4f40c3a7l2ddbb48a4de4bc3d@mail.gmail.com>	<94bdd2610907170240h2a6b168cp28f2e6ddc7067749@mail.gmail.com>	<h42fq9$irq$1@ger.gmane.org>
	<94bdd2610907201523g1b977d4cwa81eb535a7c8e5a2@mail.gmail.com>
Message-ID: <4A64EFD6.3030409@palladion.com>

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

Tarek Ziad? wrote:
> On Mon, Jul 20, 2009 at 9:16 PM, Tres Seaver<tseaver at palladion.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Tarek Ziad? wrote:
>>
>>> When Python 2.7/3.2 are out, I am planning to release a standalone
>>> version of Distutils that will work starting at 2.5.
>>> Which means that the 0.7 series of Distribute will be able to work with it.
>> I still haven't heard a clear story about how you think people will be
>> able to install that standalone version without manually hacking up
>> their /usr/lib/python2.x/ directories.
> 
> With a special .pth file that superseds the stdlib distutils path in sys.path
> you can try it out by installing the nighlty build
> 
> http://nightly.ziade.org/

The README.txt in that package says::

 Installation
 ============

 To install it, just run::

     $ python setup.py install

 Then remove or rename the Distutils version located in your Python
 library directory.

That is *exactly* the kind of thing I was referring to as "manually
hacking up their /usr/lib/python2.x/ directories":  nobody will use the
standalone version without a better story than that (and I wouldn't
blame them).

If you have another plan in mind that allows tweaking things via a .pth
file, then you need to document it clearly:  I don't have enough brain
cells to rub together figuring that out myself (if it is even possible).


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFKZO/W+gerLs4ltQ4RAmD8AKDCP7O+mguF+E1mJ5t+ZXU5V3NKWwCSAizp
RW1HYZDP7xDQFTrNkvguXg==
=rAef
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Tue Jul 21 02:20:44 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 20 Jul 2009 20:20:44 -0400
Subject: [Distutils] extending PKG-INFO .. or having a standard/library
 for reading setuptools' metadata
In-Reply-To: <op.uxdu2umu1q4jlt@whymac.activestate.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
Message-ID: <20090721001739.4B0923A40D9@sparrow.telecommunity.com>

At 01:26 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
>On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje at telecommunity.com> wrote:
>
>>discovery.resources -- basically pkg_resources under a different name
>
>It may also be worth adding support for parsing the files under .egg-info
>- for instance, those 'extras' in requires.txt.

See the 'requires()' method of Distribution objects:

http://peak.telecommunity.com/DevCenter/PkgResources#distribution-methods


From pje at telecommunity.com  Tue Jul 21 02:22:41 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 20 Jul 2009 20:22:41 -0400
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: <20090720215549.2543.2032939927.divmod.quotient.3791@henry.
	divmod.com>
References: <20090720215549.2543.2032939927.divmod.quotient.3791@henry.divmod.com>
Message-ID: <20090721001936.683A93A40D9@sparrow.telecommunity.com>

At 05:55 PM 7/20/2009 -0400, Jean-Paul Calderone wrote:
>Hello all,
>
>I'm trying to figure out how to include some extra DLLs which are required
>by an extension module I'm trying to package (pyOpenSSL).
>
> From what I can tell, the DLLs need to be in the same directory as the
>extension modules themselves (the .pyd files).  Does anyone know if this
>is the best place for them?
>
>Based on my current understanding, I've used the data_files feature of
>distutils to put the DLLs into site-packages/OpenSSL/.

Use package_data instead; it should do the right thing with both 
distutils and setuptools.  (It is available in the distutils as of 
Python 2.4; for 2.3 you'd have to use setuptools.)


From sridharr at activestate.com  Tue Jul 21 02:39:26 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 20 Jul 2009 17:39:26 -0700
Subject: [Distutils] extending PKG-INFO .. or having a standard/library
 for reading setuptools' metadata
In-Reply-To: <20090721001739.4B0923A40D9@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
Message-ID: <op.uxd6r0ss1q4jlt@whymac.activestate.com>

On Mon, 20 Jul 2009 17:20:44 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> At 01:26 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
> On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje at telecommunity.com>  
> wrote:
>  discovery.resources -- basically pkg_resources under a different name
>  It may also be worth adding support for parsing the files under  
> .egg-info
> - for instance, those 'extras' in requires.txt.
>  See the 'requires()' method of Distribution objects:
>   
> http://peak.telecommunity.com/DevCenter/PkgResources#distribution-methods

I've already looked into that before (in pkg_resources.py) -  
unfortunately, this does not return all of requires.txt (as Python dict,  
that is), but only *what* you specify in the 'extras' argument (how am I  
supposed to know the /possible/ extras sections beforehand?).

The closest I've come to is using `split_sections` and `_get_metadata` to  
construct the dict myself. But that is not the ideal way to provide/use an  
API.

-srid

From pje at telecommunity.com  Tue Jul 21 04:46:49 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 20 Jul 2009 22:46:49 -0400
Subject: [Distutils] extending PKG-INFO .. or having a standard/library
 for reading setuptools' metadata
In-Reply-To: <op.uxd6r0ss1q4jlt@whymac.activestate.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
Message-ID: <20090721024344.309983A40D9@sparrow.telecommunity.com>

At 05:39 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
>I've already looked into that before (in pkg_resources.py) -
>unfortunately, this does not return all of requires.txt (as Python dict,
>that is), but only *what* you specify in the 'extras' argument (how am I
>supposed to know the /possible/ extras sections beforehand?).

Ah, you didn't say that, you just said "parse".  If you'll file a 
feature request, I'll replace _dep_map with a public attribute for 
accessing that information in a future release.  In the meantime, 
you're quite safe using ._dep_map, since obviously I'm not going to 
change it out from under you.  ;-)


From chris at simplistix.co.uk  Tue Jul 21 12:53:19 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 21 Jul 2009 11:53:19 +0100
Subject: [Distutils] Colour this bikeshed: Name for setuptools fork
In-Reply-To: <20090719185342.6A09C3A40D9@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<ca816810907160855u40265057wd4b5520d9986dc78@mail.gmail.com>	<4A5FDE57.4060207@canterbury.ac.nz>	<878winhcny.fsf_-_@benfinney.id.au>	<319e029f0907170257q610a295dvc0356c3fb66c6588@mail.gmail.com>	<87r5wffsdz.fsf@benfinney.id.au>	<319e029f0907170523x15033bcdt87ced517f7346e99@mail.gmail.com>	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>	<4A607BF3.8060908@gulfsat.mg>	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>	<87my72d8wt.fsf@benfinney.id.au>
	<4A61355E.50706@plope.com>	<87eised550.fsf@benfinney.id.au>
	<4A6154B0.6000707@plope.com>	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>	<E84A7B8E-6F2B-41C2-BF29-209F3D913E95@leidel.info>
	<20090719185342.6A09C3A40D9@sparrow.telecommunity.com>
Message-ID: <4A659E1F.6060909@simplistix.co.uk>

P.J. Eby wrote:
> Hm.  Maybe I should just let you guys take over the thing entirely and 
> do the releases however you like.  More free time for me.  ;-)

Phil,

That's all any of us have ever actually asked...

If you could relinquish your cold iron grip on setuptools, we could get 
on with the work there, under one package, leaving one obvious way to do 
things (as it should be in the python world) without having all this 
wasteful discussion...

Seriously, I suspect all you'd need to do is give access to the 
distribution named "setuptools" on PyPI and the various volunteers could 
make the rest work...

Chris

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

From jannis at leidel.info  Tue Jul 21 13:08:20 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Tue, 21 Jul 2009 13:08:20 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <h42fga$cna$1@ger.gmane.org>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>	<5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
	<94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
	<h42fga$cna$1@ger.gmane.org>
Message-ID: <6B4C7792-C648-4721-AE93-390E2F1ADCD1@leidel.info>


Am 20.07.2009 um 21:11 schrieb Tres Seaver:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>> On Fri, Jul 17, 2009 at 11:50 AM, Hanno  
>> Schlichting<hanno at hannosch.eu> wrote:
>>> Hi.
>>>
>>> On Fri, Jul 17, 2009 at 2:07 AM, David Lyon<david.lyon at preisshare.net 
>>> > wrote:
>>>> If I find anymore issues I can post them to there instead of the
>>>> mailing list.
>>> Our bug tracker is open for submission by anyone. It's not a magical
>>> thing though. So the same rules about good bug reports, repeatable
>>> steps, preferably patches with tests and so on apply. Meta questions
>>> and general observations about controversial issues are as likely to
>>> get a non-optimal treatment as everywhere else ;)
>>>
>>>> Somebody should update the easy_install web site to direct users
>>>> to post to the tracker and not to the mailing list.
>>> We'll update the documentation soon. We will need to find a new  
>>> place
>>> to put the documentation for this fork, though.
>>
>> Let's create a Sphinx-based website. I can host it on my server. As
>> soon as the name is chosen, we can set a domain
>> name too.
>>
>> We can start to build the sphinx-based doc in the docs/ directory.
>
> Why not put it in the "standard" package docs location, e.g.:
>
> http://packages.python.org/distribute

+1

PS: http://pypi.python.org/pypi/Sphinx-PyPI-upload/

From ziade.tarek at gmail.com  Tue Jul 21 13:42:22 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 21 Jul 2009 13:42:22 +0200
Subject: [Distutils] Progress on the first distribute release
In-Reply-To: <6B4C7792-C648-4721-AE93-390E2F1ADCD1@leidel.info>
References: <5cae42b20907161028s599b6160m9553abaf3778520b@mail.gmail.com>
	<117decf0c01f1ffc05f5aca3fac6117c@preisshare.net>
	<5cae42b20907170250o19b8b246s518270749b5d9a1d@mail.gmail.com>
	<94bdd2610907170254l31a6a45el767acf947d8bfc2f@mail.gmail.com>
	<h42fga$cna$1@ger.gmane.org>
	<6B4C7792-C648-4721-AE93-390E2F1ADCD1@leidel.info>
Message-ID: <94bdd2610907210442i2836946ewda2e76e8d8eed6c4@mail.gmail.com>

On Tue, Jul 21, 2009 at 1:08 PM, Jannis Leidel<jannis at leidel.info> wrote:
>
> Am 20.07.2009 um 21:11 schrieb Tres Seaver:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Tarek Ziad? wrote:
>>>
>>> On Fri, Jul 17, 2009 at 11:50 AM, Hanno Schlichting<hanno at hannosch.eu>
>>> wrote:
>>>>
>>>> Hi.
>>>>
>>>> On Fri, Jul 17, 2009 at 2:07 AM, David Lyon<david.lyon at preisshare.net>
>>>> wrote:
>>>>>
>>>>> If I find anymore issues I can post them to there instead of the
>>>>> mailing list.
>>>>
>>>> Our bug tracker is open for submission by anyone. It's not a magical
>>>> thing though. So the same rules about good bug reports, repeatable
>>>> steps, preferably patches with tests and so on apply. Meta questions
>>>> and general observations about controversial issues are as likely to
>>>> get a non-optimal treatment as everywhere else ;)
>>>>
>>>>> Somebody should update the easy_install web site to direct users
>>>>> to post to the tracker and not to the mailing list.
>>>>
>>>> We'll update the documentation soon. We will need to find a new place
>>>> to put the documentation for this fork, though.
>>>
>>> Let's create a Sphinx-based website. I can host it on my server. As
>>> soon as the name is chosen, we can set a domain
>>> name too.
>>>
>>> We can start to build the sphinx-based doc in the docs/ directory.
>>
>> Why not put it in the "standard" package docs location, e.g.:
>>
>> http://packages.python.org/distribute
>
> +1
>
> PS: http://pypi.python.org/pypi/Sphinx-PyPI-upload/

Sure let's do this !

From exarkun at divmod.com  Tue Jul 21 15:02:16 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Tue, 21 Jul 2009 09:02:16 -0400
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: <20090721001936.683A93A40D9@sparrow.telecommunity.com>
Message-ID: <20090721130216.2543.1190632938.divmod.quotient.3948@henry.divmod.com>

On Mon, 20 Jul 2009 20:22:41 -0400, "P.J. Eby" <pje at telecommunity.com> wrote:
>At 05:55 PM 7/20/2009 -0400, Jean-Paul Calderone wrote:
>>Hello all,
>>
>>I'm trying to figure out how to include some extra DLLs which are required
>>by an extension module I'm trying to package (pyOpenSSL).
>>
>> From what I can tell, the DLLs need to be in the same directory as the
>>extension modules themselves (the .pyd files).  Does anyone know if this
>>is the best place for them?
>>
>>Based on my current understanding, I've used the data_files feature of
>>distutils to put the DLLs into site-packages/OpenSSL/.
>
>Use package_data instead; it should do the right thing with both distutils 
>and setuptools.  (It is available in the distutils as of Python 2.4; for 2.3 
>you'd have to use setuptools.)
>

Can package_data include files which aren't in the source tree?  I naively
tried 

    package_data = {
        'OpenSSL': ['C:/OpenSSL/ssleay32.dll',
                    'C:/OpenSSL/libeay32.dll']}

And got an egg which included neither ssleay32.dll nor libeay32.dll.  Should
I just copy these files into the source tree at the beginning of setup.py?
The Python distutils documentation for package_data says the paths are
relative to the package they're for, so it sounds like the absolute paths
above aren't expected to work.  (I also tried with \s, though the setuptools
docs say to use / regardless of platform, with the same outcome).

Thanks,

Jean-Paul

From exarkun at divmod.com  Tue Jul 21 15:47:46 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Tue, 21 Jul 2009 09:47:46 -0400
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: <20090721130216.2543.1190632938.divmod.quotient.3948@henry.divmod.com>
Message-ID: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>

On Tue, 21 Jul 2009 09:02:16 -0400, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>On Mon, 20 Jul 2009 20:22:41 -0400, "P.J. Eby" <pje at telecommunity.com> 
> [snip]
>>
>>Use package_data instead; it should do the right thing with both distutils 
>>and setuptools.  (It is available in the distutils as of Python 2.4; for 
>>2.3 you'd have to use setuptools.)
>
>Can package_data include files which aren't in the source tree?  I naively
>tried
>    package_data = {
>        'OpenSSL': ['C:/OpenSSL/ssleay32.dll',
>                    'C:/OpenSSL/libeay32.dll']}
>

Hmm.  Actually, I then tried various other spellings, using only relative
paths, and was unable to get these DLLs into the egg using any of them.  I
wonder if I am missing something fundamental about how package_data is
interpreted.

A couple other values I tried:

  package_data = {'': ['ssleay32.dll', 'libeay32.dll']}

  package_data = {'OpenSSL': ['ssleay32.dll', 'libeay32.dll']}

Any tips?

Thanks,

Jean-Paul

From ziade.tarek at gmail.com  Tue Jul 21 17:06:03 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 21 Jul 2009 17:06:03 +0200
Subject: [Distutils] [Distribute] Distribute release preview - testers needed
Message-ID: <94bdd2610907210806u51593d06k223725c088c55b46@mail.gmail.com>

Hello

I've uploaded a "preview" of the distribution in the repository
website. That's not the official release but I've added there so
people can help me debug it
before it gets out for real ;)

There's a script called "new_ez_setup.py" you can download and use to
install Distribute :
http://bitbucket.org/tarek/distribute/downloads/new_ez_setup.py
It's not called ez_setup.py because there's a bug in bickbucket not
allowing me to override the old ez_setup.py file we've uploaded a
while ago (the old content
keeps showing up if the new file is called ez_setup.py, looks like a
cache issue)

Anyways, the process is :

$ wget http://bitbucket.org/tarek/distribute/downloads/new_ez_setup.py
$ python new_ez_setup.py

What happens is :

- if the setuptools distribution is detected, it's replaced with a
fake 0.6c9 egg
- Distribute then installs its own egg containing its setuptools
package + pkg_resources.py module.

In theory all programs that use setuptools will continue to work
without any problem at this point,

In practice I need to do a lot of tests to see how it works when
there's other setuptools versions installed
with -m. There's some work to do too on zc.buildout side to see how it behaves.

I have started to write functional tests for this script but it's not
easy to test it under all environements.
but at this stage any help is already welcome !

my updated list of tasks :

- more tests
- working on zc.buildout side
- documenting the install process, what is does, and how to remove it,

In any case, there are good chances at this stage that some bugs will occur;
if you do find a bug, please add an issue in the tracker, with
"ez_setup" in the title
with all the details about your environment.

Thanks!

Cheers
Tarek

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

From exarkun at divmod.com  Tue Jul 21 17:09:50 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Tue, 21 Jul 2009 11:09:50 -0400
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>
Message-ID: <20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>

On Tue, 21 Jul 2009 09:47:46 -0400, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>On Tue, 21 Jul 2009 09:02:16 -0400, Jean-Paul Calderone <exarkun at divmod.com> 
>wrote:
>>On Mon, 20 Jul 2009 20:22:41 -0400, "P.J. Eby" <pje at telecommunity.com> 
>>[snip]
>>>
>>>Use package_data instead; it should do the right thing with both distutils 
>>>and setuptools.  (It is available in the distutils as of Python 2.4; for 
>>>2.3 you'd have to use setuptools.)
>>
>>Can package_data include files which aren't in the source tree?  I naively
>>tried
>>    package_data = {
>>        'OpenSSL': ['C:/OpenSSL/ssleay32.dll',
>>                    'C:/OpenSSL/libeay32.dll']}
>
>Hmm.  Actually, I then tried various other spellings, using only relative
>paths, and was unable to get these DLLs into the egg using any of them.  I
>wonder if I am missing something fundamental about how package_data is
>interpreted.
>
>A couple other values I tried:
>
>  package_data = {'': ['ssleay32.dll', 'libeay32.dll']}
>
>  package_data = {'OpenSSL': ['ssleay32.dll', 'libeay32.dll']}
>
>Any tips?
>

I tracked down the problem to a requirement I wasn't aware of.  If no
value is passed for the "packages" argument to setup, it seems that the
package_data value is ignored.  Once I added `packages = ["OpenSSL"]?,
the former of the above package_data definitions worked.

I'm still curious about whether it's possible to specify absolute paths
rather than relative paths.  For the moment, I have my setup.py copying
the files to a location where they'll be picked up, but it'd be great if
I could drop that.

Thanks,

Jean-Paul

From ziade.tarek at gmail.com  Tue Jul 21 17:34:07 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 21 Jul 2009 17:34:07 +0200
Subject: [Distutils] [Distribute] Distribute release preview - testers
	needed
In-Reply-To: <94bdd2610907210806u51593d06k223725c088c55b46@mail.gmail.com>
References: <94bdd2610907210806u51593d06k223725c088c55b46@mail.gmail.com>
Message-ID: <94bdd2610907210834u64f5c740m8ea8b21296d29f99@mail.gmail.com>

Just a quick note, if you are scared to try :), and since I didn't
document this yet

The original setuptools egg is renamed in an .OLD.TIMESTAMP file
in your sys.prefix/site-packages directory, so to get back to a normal state,
all you have to do is to replace the fake egg with the original one.


Tarek


On Tue, Jul 21, 2009 at 5:06 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> Hello
>
> I've uploaded a "preview" of the distribution in the repository
> website. That's not the official release but I've added there so
> people can help me debug it
> before it gets out for real ;)
>
> There's a script called "new_ez_setup.py" you can download and use to
> install Distribute :
> http://bitbucket.org/tarek/distribute/downloads/new_ez_setup.py
> It's not called ez_setup.py because there's a bug in bickbucket not
> allowing me to override the old ez_setup.py file we've uploaded a
> while ago (the old content
> keeps showing up if the new file is called ez_setup.py, looks like a
> cache issue)
>
> Anyways, the process is :
>
> $ wget http://bitbucket.org/tarek/distribute/downloads/new_ez_setup.py
> $ python new_ez_setup.py
>
> What happens is :
>
> - if the setuptools distribution is detected, it's replaced with a
> fake 0.6c9 egg
> - Distribute then installs its own egg containing its setuptools
> package + pkg_resources.py module.
>
> In theory all programs that use setuptools will continue to work
> without any problem at this point,
>
> In practice I need to do a lot of tests to see how it works when
> there's other setuptools versions installed
> with -m. There's some work to do too on zc.buildout side to see how it behaves.
>
> I have started to write functional tests for this script but it's not
> easy to test it under all environements.
> but at this stage any help is already welcome !
>
> my updated list of tasks :
>
> - more tests
> - working on zc.buildout side
> - documenting the install process, what is does, and how to remove it,
>
> In any case, there are good chances at this stage that some bugs will occur;
> if you do find a bug, please add an issue in the tracker, with
> "ez_setup" in the title
> with all the details about your environment.
>
> Thanks!
>
> Cheers
> Tarek
>
> --
> Tarek Ziad? | http://ziade.org
>



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

From david.lyon at preisshare.net  Tue Jul 21 17:44:54 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 21 Jul 2009 11:44:54 -0400
Subject: [Distutils] [Distribute] Distribute release preview - testers
	needed
In-Reply-To: <94bdd2610907210806u51593d06k223725c088c55b46@mail.gmail.com>
References: <94bdd2610907210806u51593d06k223725c088c55b46@mail.gmail.com>
Message-ID: <fd9559b70d0820485c378df237d090e7@preisshare.net>


Haha....

lucky I'm using a powerful tool like a GUI package manager...

 - I'll just click on setuptools - click remove

 - click install .egg

 - see what happens.... :-)

If I find anything I'll report it back to your tracker..

:-)

David

On Tue, 21 Jul 2009 17:06:03 +0200, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> Hello
> 
> I've uploaded a "preview" of the distribution in the repository
> website. That's not the official release but I've added there so
> people can help me debug it
> before it gets out for real ;)
> 
> There's a script called "new_ez_setup.py" you can download and use to
> install Distribute :
> http://bitbucket.org/tarek/distribute/downloads/new_ez_setup.py
> It's not called ez_setup.py because there's a bug in bickbucket not
> allowing me to override the old ez_setup.py file we've uploaded a
> while ago (the old content
> keeps showing up if the new file is called ez_setup.py, looks like a
> cache issue)
> 
> Anyways, the process is :
> 
> $ wget http://bitbucket.org/tarek/distribute/downloads/new_ez_setup.py
> $ python new_ez_setup.py
> 
> What happens is :
> 
> - if the setuptools distribution is detected, it's replaced with a
> fake 0.6c9 egg
> - Distribute then installs its own egg containing its setuptools
> package + pkg_resources.py module.
> 
> In theory all programs that use setuptools will continue to work
> without any problem at this point,
> 
> In practice I need to do a lot of tests to see how it works when
> there's other setuptools versions installed
> with -m. There's some work to do too on zc.buildout side to see how it
> behaves.
> 
> I have started to write functional tests for this script but it's not
> easy to test it under all environements.
> but at this stage any help is already welcome !
> 
> my updated list of tasks :
> 
> - more tests
> - working on zc.buildout side
> - documenting the install process, what is does, and how to remove it,
> 
> In any case, there are good chances at this stage that some bugs will
> occur;
> if you do find a bug, please add an issue in the tracker, with
> "ez_setup" in the title
> with all the details about your environment.
> 
> Thanks!
> 
> Cheers
> Tarek

From pje at telecommunity.com  Tue Jul 21 20:12:48 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 21 Jul 2009 14:12:48 -0400
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: <20090721150950.2543.358577142.divmod.quotient.3966@henry.d
	ivmod.com>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>
	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>
Message-ID: <20090721180943.3A4E53A4099@sparrow.telecommunity.com>

At 11:09 AM 7/21/2009 -0400, Jean-Paul Calderone wrote:
>On Tue, 21 Jul 2009 09:47:46 -0400, Jean-Paul Calderone 
><exarkun at divmod.com> wrote:
>>On Tue, 21 Jul 2009 09:02:16 -0400, Jean-Paul Calderone 
>><exarkun at divmod.com> wrote:
>>>On Mon, 20 Jul 2009 20:22:41 -0400, "P.J. Eby" 
>>><pje at telecommunity.com> [snip]
>>>>
>>>>Use package_data instead; it should do the right thing with both 
>>>>distutils and setuptools.  (It is available in the distutils as 
>>>>of Python 2.4; for 2.3 you'd have to use setuptools.)
>>>
>>>Can package_data include files which aren't in the source tree?  I naively
>>>tried
>>>    package_data = {
>>>        'OpenSSL': ['C:/OpenSSL/ssleay32.dll',
>>>                    'C:/OpenSSL/libeay32.dll']}
>>
>>Hmm.  Actually, I then tried various other spellings, using only relative
>>paths, and was unable to get these DLLs into the egg using any of them.  I
>>wonder if I am missing something fundamental about how package_data is
>>interpreted.
>>
>>A couple other values I tried:
>>
>>  package_data = {'': ['ssleay32.dll', 'libeay32.dll']}
>>
>>  package_data = {'OpenSSL': ['ssleay32.dll', 'libeay32.dll']}
>>
>>Any tips?
>
>I tracked down the problem to a requirement I wasn't aware of.  If no
>value is passed for the "packages" argument to setup, it seems that the
>package_data value is ignored.  Once I added `packages = ["OpenSSL"]??,
>the former of the above package_data definitions worked.
>
>I'm still curious about whether it's possible to specify absolute paths
>rather than relative paths.

No, it's not supported by the distutils or by setuptools.  The 
concept of "package data" is data in the same directory as the 
package's Python code.  Using it to install libraries is a bit of a 
hack in the first place.


From dpeterson at enthought.com  Wed Jul 22 02:02:02 2009
From: dpeterson at enthought.com (Dave Peterson)
Date: Tue, 21 Jul 2009 19:02:02 -0500
Subject: [Distutils] Possible to import from a zipfile retrieved from within
 an .egg using pkg_resource's ResourceManager API?
Message-ID: <4A6656FA.4050902@enthought.com>

Background:
The Mayavi project generates wrapper code around VTK during it's build 
process.  This gets bundled into a zip file called tvtk_classes.zip and 
included in a binary distribution.   Currently, we mark built eggs as 
non-zip-safe so that they get unpacked during installation, which makes 
it possible to find the zip file and add it directly to sys.path.  
However, this mechanism won't work when someone tries to distribute an 
app containing Mayavi by using py2app, py2exe, etc. because all of 
site-packages usually gets bundled in a single zip.

Problem:
I'm wondering if there is some way to use pkg_resources to retrieve a 
reference to the embedded zip file within py2app's generated 
site-packages.zip (or within an unpacked egg install) and somehow add 
that to sys.path?   The only obvious thing I see in pkg_resource's 
ResourceManager API docs is to extract the embedded zipfile via 
"resource_filename".  However, it isn't clear to me whether calling that 
will extract *everything* within the containing zip, or just unpack the 
requested resource itself.   The former could be a rather large 
performance hit in the case of py2app.  Does anyone have any feedback on 
the performance of using this resource_filename API?

Or is there a better way to do this?  Perhaps there is a way to force 
py2app/py2exe to avoid putting Mayavi within the site-packages zipfile?  
(Right now, I'm more concerned about the py2app usecase than I am the 
zip-within-an-egg usecase.)


Thanks in advance for any advice!


-- Dave



From setuptools at bugs.python.org  Wed Jul 22 02:06:35 2009
From: setuptools at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 22 Jul 2009 00:06:35 +0000
Subject: [Distutils] [issue82] API for exposing the contents of requires.txt
	(and perhaps	other metadata in .egg-info/)
In-Reply-To: <1248221195.67.0.716920644413.issue82@psf.upfronthosting.co.za>
Message-ID: <1248221195.67.0.716920644413.issue82@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

On Mon, 20 Jul 2009 17:20:44 -0700, P.J. Eby <pje at telecommunity.com> wrote:
 
At 01:26 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
On Sat, 18 Jul 2009 19:31:36 -0700, P.J. Eby <pje at telecommunity.com> wrote:
 discovery.resources -- basically pkg_resources under a different name
 It may also be worth adding support for parsing the files under .egg-info
- for instance, those 'extras' in requires.txt.
 See the 'requires()' method of Distribution objects:
 http://peak.telecommunity.com/DevCenter/PkgResources#distribution-methods
 
I've already looked into that before (in pkg_resources.py) - unfortunately, 
this does not return all of requires.txt (as Python dict, that is), but only 
*what* you specify in the 'extras' argument (how am I supposed to know the /
possible/ extras sections beforehand?).
 
The closest I've come to is using `split_sections` and `_get_metadata` to 
construct the dict myself. But that is not the ideal way to provide/use an API.
 

PJE: Ah, you didn't say that, you just said "parse".  If you'll file a feature 
request, I'll replace _dep_map with a public attribute for accessing that 
information in a future release.  In the meantime, you're quite safe 
using ._dep_map, since obviously I'm not going to change it out from under 
you.

----------
assignedto: pje
messages: 330
nosy: pje, srid
priority: wish
status: chatting
title: API for exposing the contents of requires.txt (and perhaps other metadata in .egg-info/)

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue82>
_______________________________________________

From sridharr at activestate.com  Wed Jul 22 02:07:45 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Tue, 21 Jul 2009 17:07:45 -0700
Subject: [Distutils] extending PKG-INFO .. or having a standard/library
 for reading setuptools' metadata
In-Reply-To: <20090721024344.309983A40D9@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
Message-ID: <op.uxfzy7aa1q4jlt@whymac>

On Mon, 20 Jul 2009 19:46:49 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> At 05:39 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
> I've already looked into that before (in pkg_resources.py) -
> unfortunately, this does not return all of requires.txt (as Python dict,
> that is), but only *what* you specify in the 'extras' argument (how am I
> supposed to know the /possible/ extras sections beforehand?).
>  Ah, you didn't say that, you just said "parse".  If you'll file a  
> feature request, I'll replace _dep_map with a public attribute for  
> accessing that information in a future release.  In the meantime, you're  
> quite safe using ._dep_map, since obviously I'm not going to change it  
> out from under you.

Done - http://bugs.python.org/setuptools/issue82

And it is `_Distribution__depmap`, not '_dep_map'.

-srid

From pje at telecommunity.com  Wed Jul 22 02:24:44 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 21 Jul 2009 20:24:44 -0400
Subject: [Distutils] Possible to import from a zipfile retrieved from
 within an .egg using pkg_resource's ResourceManager API?
In-Reply-To: <4A6656FA.4050902@enthought.com>
References: <4A6656FA.4050902@enthought.com>
Message-ID: <20090722002139.73C9C3A4099@sparrow.telecommunity.com>

At 07:02 PM 7/21/2009 -0500, Dave Peterson wrote:
>Background:
>The Mayavi project generates wrapper code around VTK during it's 
>build process.  This gets bundled into a zip file called 
>tvtk_classes.zip and included in a binary distribution.   Currently, 
>we mark built eggs as non-zip-safe so that they get unpacked during 
>installation, which makes it possible to find the zip file and add 
>it directly to sys.path.
>However, this mechanism won't work when someone tries to distribute 
>an app containing Mayavi by using py2app, py2exe, etc. because all 
>of site-packages usually gets bundled in a single zip.
>
>Problem:
>I'm wondering if there is some way to use pkg_resources to retrieve 
>a reference to the embedded zip file within py2app's generated 
>site-packages.zip (or within an unpacked egg install) and somehow 
>add that to sys.path?   The only obvious thing I see in 
>pkg_resource's ResourceManager API docs is to extract the embedded 
>zipfile via "resource_filename".  However, it isn't clear to me 
>whether calling that will extract *everything* within the containing 
>zip, or just unpack the requested resource itself.

It won't do either unless the name of the enclosing zipfile ends with 
.egg; in such a case all you can use is resource_string or resource_stream.


>    The former could be a rather large performance hit in the case 
> of py2app.  Does anyone have any feedback on the performance of 
> using this resource_filename API?
>
>Or is there a better way to do this?  Perhaps there is a way to 
>force py2app/py2exe to avoid putting Mayavi within the site-packages zipfile?

It would probably be better to extract tvtk_classes.zip to a 
directory of the same name, so that instead of having nested 
zipfiles, there's only one level of zipping, and you'll just be able 
to put the zipped subdirectory on sys.path.  (Note that you can put a 
subdirectory of a zipfile on sys.path, and it'll still work.  It's 
just that the subdirectory has to be a directory inside the zipfile, 
not another zipfile inside the zipfile.)


From sridharr at activestate.com  Wed Jul 22 02:27:16 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Tue, 21 Jul 2009 17:27:16 -0700
Subject: [Distutils] pkg_resources: parsing requires.txt without .egg-info/
	directory
In-Reply-To: <op.uxfzy7aa1q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac>
Message-ID: <op.uxf0vquv1q4jlt@whymac>

Ok, I give up.

To parse I need access to the .egg-info/ directory. Why? This is the code  
I currently use to access _dep_map.

>>> import pkg_resources as pr
>>> egg_info = '[...]/src/zope.component.egg-info'
>>> base_dir = os.path.dirname(egg_info)
>>> metadata = pr.PathMetadata(base_dir, egg_info)
>>> dist = pr.Distribution(base_dir,  
>>> project_name=os.path.splitext(os.path.basename(egg_info))[0],  
>>> metadata=metadata)
>>> dist._dep_map

Is there anyway to get access to this parsed _dep_map without having a  
reference to the .egg-info directory? After all, everything needed to  
parse requires.txt is that file alone.

Note: requires.txt is extracted and stored elsewhere, so I cannot rely in  
it being inside .egg-info/ directory in order to parse it.

-srid

On Tue, 21 Jul 2009 17:07:45 -0700, Sridhar Ratnakumar  
<sridharr at activestate.com> wrote:

> On Mon, 20 Jul 2009 19:46:49 -0700, P.J. Eby <pje at telecommunity.com>  
> wrote:
>
>> At 05:39 PM 7/20/2009 -0700, Sridhar Ratnakumar wrote:
>> I've already looked into that before (in pkg_resources.py) -
>> unfortunately, this does not return all of requires.txt (as Python dict,
>> that is), but only *what* you specify in the 'extras' argument (how am I
>> supposed to know the /possible/ extras sections beforehand?).
>>  Ah, you didn't say that, you just said "parse".  If you'll file a  
>> feature request, I'll replace _dep_map with a public attribute for  
>> accessing that information in a future release.  In the meantime,  
>> you're quite safe using ._dep_map, since obviously I'm not going to  
>> change it out from under you.
>
> Done - http://bugs.python.org/setuptools/issue82
>
> And it is `_Distribution__depmap`, not '_dep_map'.
>
> -srid
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig



From david.lyon at preisshare.net  Wed Jul 22 02:26:45 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 21 Jul 2009 20:26:45 -0400
Subject: [Distutils] Removing the hack from setup.py - Setup.py as a Class,
	not a Procedure
In-Reply-To: <20090721180943.3A4E53A4099@sparrow.telecommunity.com>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>
	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>
	<20090721180943.3A4E53A4099@sparrow.telecommunity.com>
Message-ID: <b9caad44d3afbd4eb122034e863cf188@preisshare.net>

On Tue, 21 Jul 2009 14:12:48 -0400, "P.J. Eby" <pje at telecommunity.com>
wrote:
> The concept of "package data" is data in the same directory as the 
> package's Python code.  Using it to install libraries is a bit of a 
> hack in the first place.

Too right it's a hack - haha. I'm glad that I'm not the only one who's 
noticed.

As a relative newcomer I can see how setup.py might have been "advanced"
in the good old days..

Now it's somewhat restrictive. And my guess + experience is that it
can take about 3+ days to get a "typical" setup.py to work properly
because of all the hacks. (For a newcomer)

My constructive suggestion for making setup.py more "friendly"
would be to update it Object Oriented technology. Along the 
following lines:

 1) Extend setup.cfg to hold more/all-of the metadata

 2) Turn 'setup' into a class (rather than a procedure)

 3) Provide a 'user' area/function like say 'pre-setup'
    "self.pre_setup()" that is a method that gets run 
    before the actual 'setup' method.

    This 'self.pre_setup()' method gets provided with a whole
    lot of information about where everything will go.

    ie.. the destination directory (self.destination?)
         operating system (self.os_name)
         window manager (self.window_manager)
         location of script directories (self.scripts)
         location of data directories (self.data_dir)
         location of docs directories (self.doc_dir)
         a pulldown menu object (for adding shortcuts)
         a desktop object (for adding shortcuts)
         list of python packages already installed (self.packages)
         information about the web environment (self.web_environment)

    When the "self."* properties are then all adjusted
    the code can proceed to the 'self.setup()' method
    where the actual install can be done.

 4) Provide a 'user' area/function like say post-setup
    "self.post_setup() that gets run after the 'self.setup()'.

    This then gives the application a chance to do post
    setup initialisation. Modifying attributes, registering
    libraries, generating documentation... whatever

This would preserve the "idea" of setup.py but give it more
real world information allowing its use to be less obscure.

We could modernise setup.py with this approach and allow
it to be a very good cross platform tool....

David





From david.lyon at preisshare.net  Wed Jul 22 02:41:45 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 21 Jul 2009 20:41:45 -0400
Subject: [Distutils]
 =?utf-8?q?pkg=5Fresources=3A_parsing_requires=2Etxt_w?=
 =?utf-8?q?ithout_=2Eegg-info/_directory?=
In-Reply-To: <op.uxf0vquv1q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
Message-ID: <cce0216e7fb8cb07ebab47ddb0005060@preisshare.net>

On Tue, 21 Jul 2009 17:27:16 -0700, "Sridhar Ratnakumar"
<sridharr at activestate.com> wrote:
> Ok, I give up.

Don't do that - if you go I will be all alone - haha

> Is there anyway to get access to this parsed _dep_map without having a  
> reference to the .egg-info directory? After all, everything needed to  
> parse requires.txt is that file alone.
> 
> Note: requires.txt is extracted and stored elsewhere, so I cannot rely in
 
> it being inside .egg-info/ directory in order to parse it.

Keep trying ... or advance to pythonpkgmgr....

Have a nice day

David


From pje at telecommunity.com  Wed Jul 22 03:04:00 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 21 Jul 2009 21:04:00 -0400
Subject: [Distutils] pkg_resources: parsing requires.txt without
 .egg-info/ directory
In-Reply-To: <op.uxf0vquv1q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
Message-ID: <20090722010054.9B7F33A4099@sparrow.telecommunity.com>

At 05:27 PM 7/21/2009 -0700, Sridhar Ratnakumar wrote:
>Ok, I give up.
>
>To parse I need access to the .egg-info/ directory. Why? This is the code
>I currently use to access _dep_map.
>
>>>>import pkg_resources as pr
>>>>egg_info = '[...]/src/zope.component.egg-info'
>>>>base_dir = os.path.dirname(egg_info)
>>>>metadata = pr.PathMetadata(base_dir, egg_info)
>>>>dist = pr.Distribution(base_dir,
>>>>project_name=os.path.splitext(os.path.basename(egg_info))[0],
>>>>metadata=metadata)
>>>>dist._dep_map
>
>Is there anyway to get access to this parsed _dep_map without having a
>reference to the .egg-info directory? After all, everything needed to
>parse requires.txt is that file alone.
>
>Note: requires.txt is extracted and stored elsewhere, so I cannot rely in
>it being inside .egg-info/ directory in order to parse it.

print require('zope.component')[0]._dep_map would be the normal way 
to get it, for a package that's already installed.

However, from some of the rest of what you're saying, it sounds like 
you're trying to parse this for an un-built package.  Is that the case?


From sridharr at activestate.com  Wed Jul 22 04:19:03 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Tue, 21 Jul 2009 19:19:03 -0700
Subject: [Distutils] pkg_resources: parsing requires.txt without
 .egg-info/ directory
In-Reply-To: <20090722010054.9B7F33A4099@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
	<20090722010054.9B7F33A4099@sparrow.telecommunity.com>
Message-ID: <op.uxf511ik1q4jlt@whymac>

On Tue, 21 Jul 2009 18:04:00 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> Is there anyway to get access to this parsed _dep_map without having a
> reference to the .egg-info directory? After all, everything needed to
> parse requires.txt is that file alone.
>  Note: requires.txt is extracted and stored elsewhere, so I cannot rely  
> in
> it being inside .egg-info/ directory in order to parse it.
>  print require('zope.component')[0]._dep_map would be the normal way to  
> get it, for a package that's already installed.
>  However, from some of the rest of what you're saying, it sounds like  
> you're trying to parse this for an un-built package.  Is that the case?

Yes. I am not bothered about installed packages. Long story short, I  
download packages from PyPI .. extract the PKG-INFO and requires.txt file  
for each of them. Then, I am trying to parse requires.txt (copied from the  
tarball).

-srid



From jeff at taupro.com  Wed Jul 22 05:20:15 2009
From: jeff at taupro.com (Jeff Rush)
Date: Tue, 21 Jul 2009 22:20:15 -0500
Subject: [Distutils] Removing the hack from setup.py - Setup.py as a
 Class, not a Procedure
In-Reply-To: <b9caad44d3afbd4eb122034e863cf188@preisshare.net>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>	<20090721180943.3A4E53A4099@sparrow.telecommunity.com>
	<b9caad44d3afbd4eb122034e863cf188@preisshare.net>
Message-ID: <4A66856F.9000907@taupro.com>

David Lyon wrote:
> On Tue, 21 Jul 2009 14:12:48 -0400, "P.J. Eby" <pje at telecommunity.com>
> wrote:
>> The concept of "package data" is data in the same directory as the 
>> package's Python code.  Using it to install libraries is a bit of a 
>> hack in the first place.
> 
> Too right it's a hack - haha. I'm glad that I'm not the only one who's 
> noticed.

You're misreading him - the hack is using an attribute of
"package_data", which is intended for describing "data files residing
within a package directory", in a way in which it was not intended to
describe data _outside_ a package directory.  That's a definition of a hack.

If an egg wants to splatter data files outside the Python package area,
other than scripts in /usr/local/bin/, I'd consider that very bad
behavior.   My reasons are that (1) such splattering is usually very
OS/platform-specific, (2) the files splattered may have overwritten
files under the control of a native system packaging system, with no way
to recover the originals and (3) there is no real metadata or directory
proximity linking the splattered files to a particular Python
distribution.  These properties have a destabilizing effect on a system
over time.


> Now it's somewhat restrictive. And my guess + experience is that it
> can take about 3+ days to get a "typical" setup.py to work properly
> because of all the hacks. (For a newcomer)

Setuptools is not the hack (by the definition of 'hack') -- using
setuptools in unusual ways is the hack.  Most often the problems I see
people have are they do not grok the problem that setuptools is solving
and want it to solve some other problem.  When used for the purpose
intended, setuptools is quite good.

-Jeff

From pje at telecommunity.com  Wed Jul 22 06:23:00 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 22 Jul 2009 00:23:00 -0400
Subject: [Distutils] pkg_resources: parsing requires.txt without
 .egg-info/ directory
In-Reply-To: <op.uxf511ik1q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170548v3086b676vacde31ab038a6d78@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
	<20090722010054.9B7F33A4099@sparrow.telecommunity.com>
	<op.uxf511ik1q4jlt@whymac>
Message-ID: <20090722041959.689A33A4099@sparrow.telecommunity.com>

At 07:19 PM 7/21/2009 -0700, Sridhar Ratnakumar wrote:
>On Tue, 21 Jul 2009 18:04:00 -0700, P.J. Eby <pje at telecommunity.com> wrote:
>
>>Is there anyway to get access to this parsed _dep_map without having a
>>reference to the .egg-info directory? After all, everything needed to
>>parse requires.txt is that file alone.
>>  Note: requires.txt is extracted and stored elsewhere, so I cannot rely
>>in
>>it being inside .egg-info/ directory in order to parse it.
>>  print require('zope.component')[0]._dep_map would be the normal way to
>>get it, for a package that's already installed.
>>  However, from some of the rest of what you're saying, it sounds like
>>you're trying to parse this for an un-built package.  Is that the case?
>
>Yes. I am not bothered about installed packages. Long story short, I
>download packages from PyPI .. extract the PKG-INFO and requires.txt file
>for each of them. Then, I am trying to parse requires.txt (copied from the
>tarball).

If I were trying to do what you're doing, I'd just run a bdist_egg on 
the package and inspect it via the API.  Or, alternately, I'd run the 
egg_info command with an explicit target directory, then load it via 
the regular API.  (By "regular API" I mean such things as a 
find_distributions() call aimed at the parent of the .egg-info directory.)

And I'd do it that way because then I wouldn't need to care whether 
the distribution was created with setuptools or not.

Actually, I'd probably just use "easy_install -zmaxNd sometmpdir 
Projectname", followed by looping over 
find_distributions('sometmpdir') and returning the _dep_map of the 
first yielded Distribution.  (The "zmaxNd" means "install as a 
zipfile, don't munge .pth files or sys.path, ensure that you copy the 
needed file to the target directory, exclude scripts, no 
dependencies, and here's the directory to put it in".)

This recipe will handle source, eggs, or win32 .exe files without 
complaint, and work on distutils or setuptools-based projects, as 
long as they don't break sandboxing or do something silly in their setup.py.


From david.lyon at preisshare.net  Wed Jul 22 06:59:43 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 22 Jul 2009 00:59:43 -0400
Subject: [Distutils] Removing the hack from setup.py - Setup.py as a
 Class, not a Procedure
In-Reply-To: <4A66856F.9000907@taupro.com>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>	<20090721180943.3A4E53A4099@sparrow.telecommunity.com>
	<b9caad44d3afbd4eb122034e863cf188@preisshare.net>
	<4A66856F.9000907@taupro.com>
Message-ID: <7e4d49df1eb244728c3c3afbd6359037@preisshare.net>

On Tue, 21 Jul 2009 22:20:15 -0500, Jeff Rush <jeff at taupro.com> wrote:
>> Too right it's a hack - haha. I'm glad that I'm not the only one who's 
>> noticed.
> 
> You're misreading him - the hack is using an attribute of
> "package_data", ......

No I'm not...

I realise that was was being said related to a "tiny hack". But
there are many more in addition to that.

> If an egg wants to splatter data files outside the Python package area,
> other than scripts in /usr/local/bin/, I'd consider that very bad
> behavior.   

But eggs aren't the only types of installs that are required.

Applications need to install shortcuts - that's a type of link.

All these other things that need to be done should have an orderly
way to cater for them.

> Setuptools is not the hack (by the definition of 'hack') -- using
> setuptools in unusual ways is the hack.  

Oh please, wanting to do pre-setup and post-setup initialisation
shouldn't be so unusual.

> Most often the problems I see
> people have are they do not grok the problem that setuptools is solving
> and want it to solve some other problem.  When used for the purpose
> intended, setuptools is quite good.

My point isn't about whether setuptools is good or not. Everyone can
see that it's been rather good over the years. That's self evident.

But installing .dll files on windows is 100% neccessary in many
"normal-use" cases. It's just not out of the ordinary.

I'm making a stab in the dark to say that you're probably not on
windows and therefore perphaps you don't understand how frustrating
it is to work with these problems.

As windows developers we're in a situation of having to hack everything
and what I'm suggesting is a more clean way of doing things that is
more object oriented. 

More modern.. and more flexible..

Having setup as a class and not a procedure makes good design sense.

I'm sticking with that view - haha - until somebody tells me we
shouldn't use classes... everything else in python is Object Oriented
why shouldn't doing a setup be...

David




From pje at telecommunity.com  Wed Jul 22 07:32:25 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 22 Jul 2009 01:32:25 -0400
Subject: [Distutils] Removing the hack from setup.py - Setup.py as a
 Class, not a Procedure
In-Reply-To: <7e4d49df1eb244728c3c3afbd6359037@preisshare.net>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>
	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>
	<20090721180943.3A4E53A4099@sparrow.telecommunity.com>
	<b9caad44d3afbd4eb122034e863cf188@preisshare.net>
	<4A66856F.9000907@taupro.com>
	<7e4d49df1eb244728c3c3afbd6359037@preisshare.net>
Message-ID: <20090722052920.292623A4099@sparrow.telecommunity.com>

At 12:59 AM 7/22/2009 -0400, David Lyon wrote:
>But installing .dll files on windows is 100% neccessary in many
>"normal-use" cases. It's just not out of the ordinary.

You can get setuptools to build *and* install them for you, 
actually.  It's just not documented, since the feature is not 
well-supported on all platforms.  (Windows is actually about the only 
platform it works properly on out of the box!)

If you look at the tests/shlib_test directory in the setuptools 
source, there's an example setup script that builds and installs a 
.pyd and .dll when run on Windows.


From david.lyon at preisshare.net  Wed Jul 22 08:43:43 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 22 Jul 2009 02:43:43 -0400
Subject: [Distutils] Removing the hack from setup.py - Setup.py as a
 Class, not a Procedure
In-Reply-To: <20090722052920.292623A4099@sparrow.telecommunity.com>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>
	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>
	<20090721180943.3A4E53A4099@sparrow.telecommunity.com>
	<b9caad44d3afbd4eb122034e863cf188@preisshare.net>
	<4A66856F.9000907@taupro.com>
	<7e4d49df1eb244728c3c3afbd6359037@preisshare.net>
	<20090722052920.292623A4099@sparrow.telecommunity.com>
Message-ID: <3a0c0e37388126757dbb4e160adc405a@preisshare.net>

On Wed, 22 Jul 2009 01:32:25 -0400, "P.J. Eby" <pje at telecommunity.com>
wrote:
> 
> You can get setuptools to build *and* install them for you, 
> actually.  It's just not documented, since the feature is not 
> well-supported on all platforms.  (Windows is actually about the only 
> platform it works properly on out of the box!)

Well it's never a good idea for programmers to rely on undocumented 
features.

Maybe somebody can think about adding it to the appropriate tracker
but as far as I'm concerned if it isn't documented then it doesn't
exist and therefore shouldn't be used.

Surely we can't expect users to follow and know about undocumented
features..  because in that case then we are explicitly instructing
them that the use of any undocumented feature or bug is wholy
acceptable. That flies against most existing software paradigms.

David

btw - I appreciate the information - and hope you update the
documentation or at least make a note to do so.




From david at ar.media.kyoto-u.ac.jp  Wed Jul 22 09:52:55 2009
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 22 Jul 2009 16:52:55 +0900
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: <20090721180943.3A4E53A4099@sparrow.telecommunity.com>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>
	<20090721180943.3A4E53A4099@sparrow.telecommunity.com>
Message-ID: <4A66C557.40609@ar.media.kyoto-u.ac.jp>

P.J. Eby wrote:
> At 11:09 AM 7/21/2009 -0400, Jean-Paul Calderone wrote:
>> On Tue, 21 Jul 2009 09:47:46 -0400, Jean-Paul Calderone
>> <exarkun at divmod.com> wrote:
>>> On Tue, 21 Jul 2009 09:02:16 -0400, Jean-Paul Calderone
>>> <exarkun at divmod.com> wrote:
>>>> On Mon, 20 Jul 2009 20:22:41 -0400, "P.J. Eby"
>>>> <pje at telecommunity.com> [snip]
>>>>>
>>>>> Use package_data instead; it should do the right thing with both
>>>>> distutils and setuptools.  (It is available in the distutils as of
>>>>> Python 2.4; for 2.3 you'd have to use setuptools.)
>>>>
>>>> Can package_data include files which aren't in the source tree?  I
>>>> naively
>>>> tried
>>>>    package_data = {
>>>>        'OpenSSL': ['C:/OpenSSL/ssleay32.dll',
>>>>                    'C:/OpenSSL/libeay32.dll']}
>>>
>>> Hmm.  Actually, I then tried various other spellings, using only
>>> relative
>>> paths, and was unable to get these DLLs into the egg using any of
>>> them.  I
>>> wonder if I am missing something fundamental about how package_data is
>>> interpreted.
>>>
>>> A couple other values I tried:
>>>
>>>  package_data = {'': ['ssleay32.dll', 'libeay32.dll']}
>>>
>>>  package_data = {'OpenSSL': ['ssleay32.dll', 'libeay32.dll']}
>>>
>>> Any tips?
>>
>> I tracked down the problem to a requirement I wasn't aware of.  If no
>> value is passed for the "packages" argument to setup, it seems that the
>> package_data value is ignored.  Once I added `packages = ["OpenSSL"]??,
>> the former of the above package_data definitions worked.
>>
>> I'm still curious about whether it's possible to specify absolute paths
>> rather than relative paths.
>
> No, it's not supported by the distutils or by setuptools.  The concept
> of "package data" is data in the same directory as the package's
> Python code.  Using it to install libraries is a bit of a hack in the
> first place.

Installing libraries which are not python extensions is indeed quite
difficult ATM, I faced the same problem in numpy recently. Since in
numpy, we have our own distutils extensions, I hacked something to make
it work. A lot of code is related to our needs to be able to reuse to
libraries (with link options and all), and otherwise:
    - I patched the Distribution class to add one member which keeps
track of the installed libraries (dll in your case)
    - I added an install_clib command: this takes care of adding the
files to the record file, etc...
    - I added the in-place option for build_clib command: this is
necessary to make sure develop command works

Feel free to reuse this if you want (and can! It is butt-ugly, but not
worse than average distutils code :) ).

http://github.com/cournape/numpy/tree/install_clib

cheers,

David

From techtonik at gmail.com  Wed Jul 22 10:17:42 2009
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 22 Jul 2009 04:17:42 -0400
Subject: [Distutils] Distutils History
Message-ID: <d34314100907220117t2173f846wf1ef24afc60a3d1c@mail.gmail.com>

Hello,

I've added a chapter on Distutils history to
http://wiki.python.org/moin/Distutils to provide an overview why
current Distutils in not sufficient anymore and needs refactoring. I
would like to ask for review to see if that information is more
appropriate for Distutils/Critics

--anatoly t.

From ziade.tarek at gmail.com  Wed Jul 22 10:28:06 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 22 Jul 2009 10:28:06 +0200
Subject: [Distutils] Distutils History
In-Reply-To: <d34314100907220117t2173f846wf1ef24afc60a3d1c@mail.gmail.com>
References: <d34314100907220117t2173f846wf1ef24afc60a3d1c@mail.gmail.com>
Message-ID: <94bdd2610907220128u3525246cnc85f0e9f6715b23d@mail.gmail.com>

On Wed, Jul 22, 2009 at 10:17 AM, anatoly techtonik<techtonik at gmail.com> wrote:
> Hello,
>
> I've added a chapter on Distutils history to
> http://wiki.python.org/moin/Distutils to provide an overview why
> current Distutils in not sufficient anymore and needs refactoring. I
> would like to ask for review to see if that information is more
> appropriate for Distutils/Critics
>

That's great !

I'd rather see it at the top of the page since the next sections are
trying to fix the problems,

Tarek

> --anatoly t.
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From a.cavallo at cavallinux.eu  Wed Jul 22 14:30:52 2009
From: a.cavallo at cavallinux.eu (a.cavallo at cavallinux.eu)
Date: Wed, 22 Jul 2009 14:30:52 +0200
Subject: [Distutils] Distutils History
Message-ID: <42142.1248265852@cavallinux.eu>

On the "http://wiki.python.org/moin/Distutils/Friends", I've done something it might be interesting on the 
Distutils side already.

It is my little pet project called pyvm (http://pyvm.sourcefoorge.net): it builds python (the trunk version) 
plus the related modules (in particular the distutils Tarek package).

In theory there's no need to have a single stack (I do for my personal "pleasure") and modules can be build 
against any interpreters provided separately.

Regards,
Antonio

On Wed 22/07/09 10:28, "Tarek Ziad?" ziade.tarek at gmail.com wrote:
> On Wed, Jul 22, 2009 at 10:17 AM, anatoly techtonik<techtonik
> @gmail.com> wrote:
> Hello,
> >
> > I've added a chapter on Distutils history
> to
> http://wiki.python.org/moin/Distutils to
> provide an overview why
> current Distutils in not sufficient anymore and
> needs refactoring. I
> would like to ask for review to see if that
> information is more
> appropriate for Distutils/Critics
> >
> 
> That's great !
> 
> I'd rather see it at the top of the page since the next sections are
> trying to fix the problems,
> 
> Tarek
> 
> > --anatoly t.
> >
> _______________________________________________
> Distutils-SIG maillist ?-
> ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>>
> 
> 
> 
> -- 
> Tarek Ziad? | http://ziade.org
_______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 



From exarkun at divmod.com  Wed Jul 22 15:29:29 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Wed, 22 Jul 2009 09:29:29 -0400
Subject: [Distutils] Removing the hack from setup.py - Setup.py as a
 Class, not a Procedure
In-Reply-To: <4A66856F.9000907@taupro.com>
Message-ID: <20090722132929.2543.1951411336.divmod.quotient.4193@henry.divmod.com>

On Tue, 21 Jul 2009 22:20:15 -0500, Jeff Rush <jeff at taupro.com> wrote:
>David Lyon wrote:
>> On Tue, 21 Jul 2009 14:12:48 -0400, "P.J. Eby" <pje at telecommunity.com>
>> wrote:
>>> The concept of "package data" is data in the same directory as the
>>> package's Python code.  Using it to install libraries is a bit of a
>>> hack in the first place.
>>
>> Too right it's a hack - haha. I'm glad that I'm not the only one who's
>> noticed.
>
>You're misreading him - the hack is using an attribute of
>"package_data", which is intended for describing "data files residing
>within a package directory", in a way in which it was not intended to
>describe data _outside_ a package directory.  That's a definition of a hack.
>
>If an egg wants to splatter data files outside the Python package area,
>other than scripts in /usr/local/bin/, I'd consider that very bad
>behavior.

To clarify, I want to collect data files from outside of the Python package
area in the build environment, and place them *into* the Python package
area in the egg.  I don't want to "splatter" them outside that area when
the package is installed.

Jean-Paul

From exarkun at divmod.com  Wed Jul 22 15:31:47 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Wed, 22 Jul 2009 09:31:47 -0400
Subject: [Distutils] Including DLLs in binary distributions
In-Reply-To: <4A66C557.40609@ar.media.kyoto-u.ac.jp>
Message-ID: <20090722133147.2543.1577961024.divmod.quotient.4194@henry.divmod.com>

On Wed, 22 Jul 2009 16:52:55 +0900, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
>
> [snip]
>
>Installing libraries which are not python extensions is indeed quite
>difficult ATM, I faced the same problem in numpy recently. Since in
>numpy, we have our own distutils extensions, I hacked something to make
>it work. A lot of code is related to our needs to be able to reuse to
>libraries (with link options and all), and otherwise:
>    - I patched the Distribution class to add one member which keeps
>track of the installed libraries (dll in your case)
>    - I added an install_clib command: this takes care of adding the
>files to the record file, etc...
>    - I added the in-place option for build_clib command: this is
>necessary to make sure develop command works
>
>Feel free to reuse this if you want (and can! It is butt-ugly, but not
>worse than average distutils code :) ).
>
>http://github.com/cournape/numpy/tree/install_clib
>

Cool, thanks!  I'll take a look at this.

Jean-Paul

From zooko at zooko.com  Wed Jul 22 16:41:38 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Wed, 22 Jul 2009 08:41:38 -0600
Subject: [Distutils] Low Level API for translating distutils/setuptools
	metatdata to	Debian metadata
In-Reply-To: <20090529091202.GB22620@Boo.lan>
References: <20090529091202.GB22620@Boo.lan>
Message-ID: <38B432CD-A600-4FB9-AF88-9D18DB648045@zooko.com>

>     * Provides a mapping between python project names and Debian
>       binary/source package names
>     * Converts setuptools versions to Debian versions while  
> maintaining
>       sort order
>     * Can introspect an .egg-info directory to figure out the Debian
>       dependencies for use in the debian/control file. It can also
>       handle/understand extras (I Hope!)

I looked briefly at this code, and it appears that it is doing purely  
syntactic mapping between Debian package names and Python  
distribution names, for example:

def py_to_bin(setuptools_project):
     """Convert a setuptools project name to a debian binary package  
name"""
     return _PY_TO_BIN.get(setuptools_project, 'python-%s' %  
setuptools_project.lower())

This works most of the time, but it isn't reliable.  For example, the  
module name is "OpenSSL", the distribution name is "pyOpenSSL", and  
the Debian package name is "python-openssl":

http://packages.debian.org/sid/amd64/python-openssl/filelist

That's why I contributed a patch to stdeb which uses the Debian  
database of which files are included in which packages (the same  
database that generates the web page linked above):

http://github.com/astraw/stdeb/blob/ 
647dd441a1712f8df37b5f7f5ba22ab6aeb2c3e7/stdeb/util.py#L135

The way stdeb does it looks in the database for files named  
"$DISTRIBUTION-$VERSION-py$PYTHONVERSION.egg-info".  The Debian  
package that includes such a file is the Debian package that you need  
to install in order to satisfy a dependency on $DISTRIBUTION,  
$VERSION.  This works regardless of whether the Python package is  
built with distutils or setuptools, and indeed it works for all  
packages that I know of.  (There is actually one exception: the  
Debian package for setuptools itself doesn't include a version number  
in its .egg-info filename:

http://packages.debian.org/sid/amd64/python-setuptools/filelist

It has a file named:

/usr/share/pyshared/setuptools.egg-info/

I guess we should add a fall-back-with-warning behavior to stdeb that  
if it can't find "$DISTRIBUTION-$VERSION.egg-info", but it can find  
"$DISTRIBUTION.egg-info", then it should (optionally) assume that the  
Debian package that has that file will satisfy the requirement,  
regardless of the version number in the requirement.   That, or  
someone should open a ticket asking Debian to add a version number to  
that filename.

The exact regexp is currently:

egginfore=("(/(%s)(?:-[^/]+)?(?:-py[0-9]\.[0-9.]+)?\.egg-info)"
                % '|'.join(req.project_name for req in requirements))

If you would be interested in including this mechanism to query the  
database in van.pydeb, I would be happy to advise you.

Regards,

Zooko

From brian at vanguardistas.net  Wed Jul 22 17:52:33 2009
From: brian at vanguardistas.net (Brian Sutherland)
Date: Wed, 22 Jul 2009 17:52:33 +0200
Subject: [Distutils] Low Level API for translating
	distutils/setuptools	metatdata to Debian metadata
In-Reply-To: <38B432CD-A600-4FB9-AF88-9D18DB648045@zooko.com>
References: <20090529091202.GB22620@Boo.lan>
	<38B432CD-A600-4FB9-AF88-9D18DB648045@zooko.com>
Message-ID: <20090722155233.GA43860@Boo.lan>

On Wed, Jul 22, 2009 at 08:41:38AM -0600, Zooko Wilcox-O'Hearn wrote:
>>     * Provides a mapping between python project names and Debian
>>       binary/source package names
>>     * Converts setuptools versions to Debian versions while  
>> maintaining
>>       sort order
>>     * Can introspect an .egg-info directory to figure out the Debian
>>       dependencies for use in the debian/control file. It can also
>>       handle/understand extras (I Hope!)
>
> I looked briefly at this code, and it appears that it is doing purely  
> syntactic mapping between Debian package names and Python distribution 
> names, for example:
>
> def py_to_bin(setuptools_project):
>     """Convert a setuptools project name to a debian binary package  
> name"""
>     return _PY_TO_BIN.get(setuptools_project, 'python-%s' %  
> setuptools_project.lower())
>
> This works most of the time, but it isn't reliable.  For example, the  
> module name is "OpenSSL", the distribution name is "pyOpenSSL", and the 
> Debian package name is "python-openssl":
>
> http://packages.debian.org/sid/amd64/python-openssl/filelist
>
> That's why I contributed a patch to stdeb which uses the Debian database 
> of which files are included in which packages (the same database that 
> generates the web page linked above):
>
> http://github.com/astraw/stdeb/blob/647dd441a1712f8df37b5f7f5ba22ab6aeb2c3e7/stdeb/util.py#L135
>
> The way stdeb does it looks in the database for files named  
> "$DISTRIBUTION-$VERSION-py$PYTHONVERSION.egg-info".  The Debian package 
> that includes such a file is the Debian package that you need to install 
> in order to satisfy a dependency on $DISTRIBUTION, $VERSION.  This works 
> regardless of whether the Python package is built with distutils or 
> setuptools, and indeed it works for all packages that I know of.  (There 
> is actually one exception: the Debian package for setuptools itself 
> doesn't include a version number in its .egg-info filename:
>
> http://packages.debian.org/sid/amd64/python-setuptools/filelist
>
> It has a file named:
>
> /usr/share/pyshared/setuptools.egg-info/
>
> I guess we should add a fall-back-with-warning behavior to stdeb that if 
> it can't find "$DISTRIBUTION-$VERSION.egg-info", but it can find  
> "$DISTRIBUTION.egg-info", then it should (optionally) assume that the  
> Debian package that has that file will satisfy the requirement,  
> regardless of the version number in the requirement.   That, or someone 
> should open a ticket asking Debian to add a version number to that 
> filename.
>
> The exact regexp is currently:
>
> egginfore=("(/(%s)(?:-[^/]+)?(?:-py[0-9]\.[0-9.]+)?\.egg-info)"
>                % '|'.join(req.project_name for req in requirements))
>
> If you would be interested in including this mechanism to query the  
> database in van.pydeb, I would be happy to advise you.

Hi Zooko,

van.pydeb is designed to be run at package build time, rather than at
the time you create the source package. I assume that's when stdeb's
code runs? Using apt-file during package build time on one of the Debian
project's auto-builders will not be acceptable (I assume).

Also, "isn't reliable" has very different meanings :) van.pydeb is
reliable in that it produces the same answer independently of the
machine it's run on. But it's not reliable in that often the answer is
just plain wrong;)

The results of stdeb's mechanism depend on the configuration of the
machine where you run it (or even if you havn't run apt-file update
recently).

So, I don't think van.pydeb can use stdeb's mechanism as-is, but I'd
love to see a patch (with tests!) for a variation of it. I was thinking
of writing a script/function that could use apt-file to generate a list
of python->debian package mappings that don't fit the heuristic.

So py_to_bin could be re-written as:

    def py_to_bin(setuptools_project):
        """Convert a setuptools project name to a debian binary package name"""
        result = _HANDWRITTEN_PY_TO_BIN.get(setuptools_project)
        if result is None:
            result = _APT_FILE_GENERATED_PY_TO_BIN.get(setuptools_project)
        if result is None:
            result = 'python-%s' % setuptools_project.lower())
        return result

The _APT_FILE_GENERATED_PY_TO_BIN could be re-generated periodically.
I'm hoping that'll be enough given that:

    * packages don't change names that frequently
    * there should be few that don't fit the heuristic (*cough* policy *cough*)

> Regards,
>
> Zooko

-- 
Brian Sutherland

From ziade.tarek at gmail.com  Wed Jul 22 18:08:42 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 22 Jul 2009 18:08:42 +0200
Subject: [Distutils] [Distribute] Distribute release preview - testers
	needed
In-Reply-To: <94bdd2610907210806u51593d06k223725c088c55b46@mail.gmail.com>
References: <94bdd2610907210806u51593d06k223725c088c55b46@mail.gmail.com>
Message-ID: <94bdd2610907220908y60458e7q12fc4a844d8c2a01@mail.gmail.com>

On Tue, Jul 21, 2009 at 5:06 PM, Tarek Ziad?<ziade.tarek at gmail.com> wrote:
> Hello
>
> I've uploaded a "preview" of the distribution in the repository
> website. That's not the official release but I've added there so
> people can help me debug it
> before it gets out for real ;)

Another follow-up.

I've made it easier to try out :

1. download http://nightly.ziade.org/install_test.py
2. run it with the Python interpreter of your choice (possibly a
virtualenv-ed one)

To uninstall, follow the Uninstallation instructions here :
http://bitbucket.org/tarek/distribute/src/tip/README.txt

*Disclaimer: it might break your installation*

If the test end up with this line:

**** Test is OK

it worked. Otherwise, please let me know !

Cheers
Tarek

From sridharr at activestate.com  Wed Jul 22 21:08:04 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 22 Jul 2009 12:08:04 -0700
Subject: [Distutils] pkg_resources: parsing requires.txt without
 .egg-info/ directory
In-Reply-To: <20090722041959.689A33A4099@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
	<20090722010054.9B7F33A4099@sparrow.telecommunity.com>
	<op.uxf511ik1q4jlt@whymac>
	<20090722041959.689A33A4099@sparrow.telecommunity.com>
Message-ID: <op.uxhgrq0n1q4jlt@whymac>

On Tue, 21 Jul 2009 21:23:00 -0700, P.J. Eby <pje at telecommunity.com> wrote:


> If I were trying to do what you're doing, I'd just run a bdist_egg on  
> the package and inspect it via the API.  Or, alternately, I'd run the  
> egg_info command with an explicit target directory, then load it via the  
> regular API.  (By "regular API" I mean such things as a  
> find_distributions() call aimed at the parent of the .egg-info  
> directory.)
>
> And I'd do it that way because then I wouldn't need to care whether the  
> distribution was created with setuptools or not.

How can you run egg_info ('python setup.py egg_info') on a distribution  
that does not use setuptools?

>
> Actually, I'd probably just use "easy_install -zmaxNd sometmpdir  
> Projectname", followed by looping over find_distributions('sometmpdir')  
> and returning the _dep_map of the first yielded Distribution.  (The  
> "zmaxNd" means "install as a zipfile, don't munge .pth files or  
> sys.path, ensure that you copy the needed file to the target directory,  
> exclude scripts, no dependencies, and here's the directory to put it  
> in".)

But bdist_egg and -zmaxNd will also *build* the distribution .. which I  
don't want to do just for extracting the metadata.

> This recipe will handle source, eggs, or win32 .exe files without  
> complaint, and work on distutils or setuptools-based projects, as long  
> as they don't break sandboxing or do something silly in their setup.py.

Actually .. I am only downloading source dists.

-srid

PS: what I am actually doing is this: download the source tarballs for  
*all* packages registered in PyPI; and extract (cache) their metadata  
(PKG-INFO and requires.txt) outside the tarball.





From pje at telecommunity.com  Wed Jul 22 21:14:11 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 22 Jul 2009 15:14:11 -0400
Subject: [Distutils] pkg_resources: parsing requires.txt without
 .egg-info/ directory
In-Reply-To: <op.uxhgrq0n1q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<e5fff6640907170607r82380f4x79cc3a6ce60cf2a2@mail.gmail.com>
	<4A607BF3.8060908@gulfsat.mg>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
	<20090722010054.9B7F33A4099@sparrow.telecommunity.com>
	<op.uxf511ik1q4jlt@whymac>
	<20090722041959.689A33A4099@sparrow.telecommunity.com>
	<op.uxhgrq0n1q4jlt@whymac>
Message-ID: <20090722191106.2E9843A4099@sparrow.telecommunity.com>

At 12:08 PM 7/22/2009 -0700, Sridhar Ratnakumar wrote:
>On Tue, 21 Jul 2009 21:23:00 -0700, P.J. Eby <pje at telecommunity.com> wrote:
>>If I were trying to do what you're doing, I'd just run a bdist_egg on
>>the package and inspect it via the API.  Or, alternately, I'd run the
>>egg_info command with an explicit target directory, then load it via the
>>regular API.  (By "regular API" I mean such things as a
>>find_distributions() call aimed at the parent of the .egg-info
>>directory.)
>>
>>And I'd do it that way because then I wouldn't need to care whether the
>>distribution was created with setuptools or not.
>
>How can you run egg_info ('python setup.py egg_info') on a distribution
>that does not use setuptools?

By calling setuptools.sandbox.run_setup() with the appropriate 
arguments.  (When setuptools is imported, it monkeypatches the 
distutils, such that distutils is really setuptools.  That's how 
easy_install is able to build eggs from packages that don't use setuptools.)


From dpeterson at enthought.com  Wed Jul 22 22:05:15 2009
From: dpeterson at enthought.com (Dave Peterson)
Date: Wed, 22 Jul 2009 15:05:15 -0500
Subject: [Distutils] Possible to import from a zipfile retrieved from
 within an .egg using pkg_resource's ResourceManager API?
In-Reply-To: <20090722002139.73C9C3A4099@sparrow.telecommunity.com>
References: <4A6656FA.4050902@enthought.com>
	<20090722002139.73C9C3A4099@sparrow.telecommunity.com>
Message-ID: <4A6770FB.6010709@enthought.com>

P.J. Eby wrote:
> At 07:02 PM 7/21/2009 -0500, Dave Peterson wrote:
>
>> Or is there a better way to do this? Perhaps there is a way to force 
>> py2app/py2exe to avoid putting Mayavi within the site-packages zipfile?
>
> It would probably be better to extract tvtk_classes.zip to a directory 
> of the same name, so that instead of having nested zipfiles, there's 
> only one level of zipping, and you'll just be able to put the zipped 
> subdirectory on sys.path. (Note that you can put a subdirectory of a 
> zipfile on sys.path, and it'll still work. It's just that the 
> subdirectory has to be a directory inside the zipfile, not another 
> zipfile inside the zipfile.)

Thanks for the hint on a better direction! This appears to be an easy 
way to solve the py2app problem, though it requires a little 
modification to Mayavi itself since it attempts to dynamically add its 
tvtk_classes.zip to the sys.path. Just comment that out.

-- Dave


From pje at telecommunity.com  Wed Jul 22 23:11:48 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 22 Jul 2009 17:11:48 -0400
Subject: [Distutils] Possible to import from a zipfile retrieved from
 within an .egg using pkg_resource's ResourceManager API?
In-Reply-To: <4A6770FB.6010709@enthought.com>
References: <4A6656FA.4050902@enthought.com>
	<20090722002139.73C9C3A4099@sparrow.telecommunity.com>
	<4A6770FB.6010709@enthought.com>
Message-ID: <20090722210843.3FCF53A4099@sparrow.telecommunity.com>

At 03:05 PM 7/22/2009 -0500, Dave Peterson wrote:
>P.J. Eby wrote:
>>At 07:02 PM 7/21/2009 -0500, Dave Peterson wrote:
>>
>>>Or is there a better way to do this? Perhaps there is a way to 
>>>force py2app/py2exe to avoid putting Mayavi within the site-packages zipfile?
>>
>>It would probably be better to extract tvtk_classes.zip to a 
>>directory of the same name, so that instead of having nested 
>>zipfiles, there's only one level of zipping, and you'll just be 
>>able to put the zipped subdirectory on sys.path. (Note that you can 
>>put a subdirectory of a zipfile on sys.path, and it'll still work. 
>>It's just that the subdirectory has to be a directory inside the 
>>zipfile, not another zipfile inside the zipfile.)
>
>Thanks for the hint on a better direction! This appears to be an 
>easy way to solve the py2app problem, though it requires a little 
>modification to Mayavi itself since it attempts to dynamically add 
>its tvtk_classes.zip to the sys.path. Just comment that out.

I suspect you needn't even do that if the directory in the zipfile is 
*named* tvtk_classes.zip.  It'll end up just adding that zipfile 
subdirectory to sys.path, and all will be well.  (YMMV, of course.)


From sridharr at activestate.com  Thu Jul 23 03:04:08 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 22 Jul 2009 18:04:08 -0700
Subject: [Distutils] pkg_resources: parsing requires.txt without
 .egg-info/ directory
In-Reply-To: <20090722191106.2E9843A4099@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
	<20090722010054.9B7F33A4099@sparrow.telecommunity.com>
	<op.uxf511ik1q4jlt@whymac>
	<20090722041959.689A33A4099@sparrow.telecommunity.com>
	<op.uxhgrq0n1q4jlt@whymac>
	<20090722191106.2E9843A4099@sparrow.telecommunity.com>
Message-ID: <op.uxhw86cz1q4jlt@whymac>

On Wed, 22 Jul 2009 12:14:11 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> t 12:08 PM 7/22/2009 -0700, Sridhar Ratnakumar wrote:
> On Tue, 21 Jul 2009 21:23:00 -0700, P.J. Eby <pje at telecommunity.com>  
> wrote:
> If I were trying to do what you're doing, I'd just run a bdist_egg on
> the package and inspect it via the API.  Or, alternately, I'd run the
> egg_info command with an explicit target directory, then load it via the
> regular API.  (By "regular API" I mean such things as a
> find_distributions() call aimed at the parent of the .egg-info
> directory.)
>  And I'd do it that way because then I wouldn't need to care whether the
> distribution was created with setuptools or not.
>  How can you run egg_info ('python setup.py egg_info') on a distribution
> that does not use setuptools?
>  By calling setuptools.sandbox.run_setup() with the appropriate  
> arguments.  (When setuptools is imported, it monkeypatches the  
> distutils, such that distutils is really setuptools.  That's how  
> easy_install is able to build eggs from packages that don't use  
> setuptools.)

Ok, anyways .. running setup.py can be a pain (eg: running egg_info on  
numpy, using the sandbox, actually tries to build the extensions!).

For now, I'll go with a custom parser (like pip) .. and wait for either  
you or Tarek to split setuptools into reusable modules.

Thanks.

-srid

From pje at telecommunity.com  Thu Jul 23 03:49:42 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 22 Jul 2009 21:49:42 -0400
Subject: [Distutils] pkg_resources: parsing requires.txt without
 .egg-info/ directory
In-Reply-To: <op.uxhw86cz1q4jlt@whymac>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>
	<94bdd2610907170637g28e3a079t47e2ab88208a2c6b@mail.gmail.com>
	<87my72d8wt.fsf@benfinney.id.au> <4A61355E.50706@plope.com>
	<87eised550.fsf@benfinney.id.au> <4A6154B0.6000707@plope.com>
	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>
	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>
	<20090719022831.959983A403A@sparrow.telecommunity.com>
	<op.uxdu2umu1q4jlt@whymac.activestate.com>
	<20090721001739.4B0923A40D9@sparrow.telecommunity.com>
	<op.uxd6r0ss1q4jlt@whymac.activestate.com>
	<20090721024344.309983A40D9@sparrow.telecommunity.com>
	<op.uxfzy7aa1q4jlt@whymac> <op.uxf0vquv1q4jlt@whymac>
	<20090722010054.9B7F33A4099@sparrow.telecommunity.com>
	<op.uxf511ik1q4jlt@whymac>
	<20090722041959.689A33A4099@sparrow.telecommunity.com>
	<op.uxhgrq0n1q4jlt@whymac>
	<20090722191106.2E9843A4099@sparrow.telecommunity.com>
	<op.uxhw86cz1q4jlt@whymac>
Message-ID: <20090723014636.B08263A4099@sparrow.telecommunity.com>

At 06:04 PM 7/22/2009 -0700, Sridhar Ratnakumar wrote:
>On Wed, 22 Jul 2009 12:14:11 -0700, P.J. Eby <pje at telecommunity.com> wrote:
>
>>t 12:08 PM 7/22/2009 -0700, Sridhar Ratnakumar wrote:
>>On Tue, 21 Jul 2009 21:23:00 -0700, P.J. Eby <pje at telecommunity.com>
>>wrote:
>>If I were trying to do what you're doing, I'd just run a bdist_egg on
>>the package and inspect it via the API.  Or, alternately, I'd run the
>>egg_info command with an explicit target directory, then load it via the
>>regular API.  (By "regular API" I mean such things as a
>>find_distributions() call aimed at the parent of the .egg-info
>>directory.)
>>  And I'd do it that way because then I wouldn't need to care whether the
>>distribution was created with setuptools or not.
>>  How can you run egg_info ('python setup.py egg_info') on a distribution
>>that does not use setuptools?
>>  By calling setuptools.sandbox.run_setup() with the appropriate
>>arguments.  (When setuptools is imported, it monkeypatches the
>>distutils, such that distutils is really setuptools.  That's how
>>easy_install is able to build eggs from packages that don't use
>>setuptools.)
>
>Ok, anyways .. running setup.py can be a pain (eg: running egg_info on
>numpy, using the sandbox, actually tries to build the extensions!).
>
>For now, I'll go with a custom parser (like pip) .. and wait for either
>you or Tarek to split setuptools into reusable modules.

Well, all the lower-level tools you need to do the parsing are in 
pkg_resources also; the code actually used is just:

             dm = self.__dep_map = {None: []}
             for name in 'requires.txt', 'depends.txt':
                 for extra,reqs in split_sections(self._get_metadata(name)):
                     if extra: extra = safe_extra(extra)
                     dm.setdefault(extra,[]).extend(parse_requirements(reqs))
             return dm

Both split_sections() and parse_requirements() are public functions, 
and you can replace the _get_metadata call with a text-mode open() of 
the relevant file, if it exists.


From ziade.tarek at gmail.com  Thu Jul 23 16:07:28 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 16:07:28 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans proposal
	for 0.7/0.8
Message-ID: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>

Hello,

(Following Ronald's mail about porting setuptools to Py3k
(http://mail.python.org/pipermail/distutils-sig/2009-June/012108.html)
and Lennart's effort for that too)

Since setuptools doesn't exist yet under Python 3, I think we can
simplify the "porting to Py 3k" problem by starting a python 3
only version for the Distribute project and flip our porting problems
into the other way.

Here's my proposal, after 0.6 is released :

- Let's start a "0.8" branch right now, by removing all the
bootstraping code and by splitting and renaming all elements right
away.

  The setuptools package will be renamed in something else, the
pkg_resources.py module and easy_install script too.
  Those will be three distinct distributions. To use them, people will
have to change their import lines, and install_requires lines.

- Let's then backport the 0.8 version into a 0.7 version, compatbile
with Python 2.x and with the required bootstraping
  so it works in 2.x environments

We might end up with a very ugly 0.7, but who cares this would boosts
Python 3 adoption imho

Opinions ?

Cheers
Tarek

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

From regebro at gmail.com  Thu Jul 23 16:17:15 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 07:17:15 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
Message-ID: <319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> - Let's then backport the 0.8 version into a 0.7 version, compatbile
> with Python 2.x and with the required bootstraping
> ?so it works in 2.x environments

There is no reason to have different version numbers for that. In
fact, I think that would only be confusing. The Python 3 version
should work for Python 2 as well.

Otherwise +1 for everything.
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Thu Jul 23 16:29:36 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 16:29:36 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
Message-ID: <94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>

On Thu, Jul 23, 2009 at 4:17 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
>> - Let's then backport the 0.8 version into a 0.7 version, compatbile
>> with Python 2.x and with the required bootstraping
>> ?so it works in 2.x environments
>
> There is no reason to have different version numbers for that. In
> fact, I think that would only be confusing. The Python 3 version
> should work for Python 2 as well.

I think you don't see my point : making a pure Python 3 version, without
any backward compatibility issues / bootstraping , fight against setuptools
distribution. Then backporting it in 0.7

But 0.8 would not be 2.x compatible.


>
> Otherwise +1 for everything.
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
>



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

From regebro at gmail.com  Thu Jul 23 16:37:10 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 07:37:10 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
Message-ID: <319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> I think you don't see my point : making a pure Python 3 version, without
> any backward compatibility issues / bootstraping , fight against setuptools
> distribution. Then backporting it in 0.7
>
> But 0.8 would not be 2.x compatible.

That would mean we would have two branches of the same code that need
to be kept compatible. I don't see why that would be a better idea
than having one branch and one version.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Thu Jul 23 16:48:53 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 16:48:53 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
Message-ID: <94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>

On Thu, Jul 23, 2009 at 4:37 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
>> I think you don't see my point : making a pure Python 3 version, without
>> any backward compatibility issues / bootstraping , fight against setuptools
>> distribution. Then backporting it in 0.7
>>
>> But 0.8 would not be 2.x compatible.
>
> That would mean we would have two branches of the same code that need
> to be kept compatible.

That's exactly how Python 2.X / 3.x are developed. And we expect 0.6
then 0.7 to become
maintenance branches at some point.

> I don't see why that would be a better idea
> than having one branch and one version.
>

Like I said the python 3 branch will be pure python 3 code so we won't
have to worry
about keeping it compatible with both python 2.x and python 3

That makes the code simpler and cleaner. The maintenance effort between
the two branches is not hard as long as there's a maintainer that makes sure
every commit in the 0.8 branch is backported, like in Python-dev.
I am willing to do this maintenance work.

And since Python 3 is a setuptools-free land, we won't have to worry
in the 0.8 version
about a possible setuptools cohabitation.

And people that are using setuptools under 2.x will have less pain to
switch to different
package names and drop their "import setuptools" infavor of something else,
for their 3.x versions.

In fact, the sooner such a version is out, the better it could be for
Py3 adoption.

I don't see any benefit in having a mixed code for 2.x/3.x, but troubles ahead;

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

From regebro at gmail.com  Thu Jul 23 17:06:36 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 08:06:36 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
Message-ID: <319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> That's exactly how Python 2.X / 3.x are developed.

Python 2.x and 3.x are two different, incompatible versions of one
software. Of course you have different branches.  We are to create one
compatible version for both Python 2 and Python 3. There is no reason
to have two different branches for what is for all intents and
purposes the same version and software.

> Like I said the python 3 branch will be pure python 3 code so we won't
> have to worry about keeping it compatible with both python 2.x and python 3

Well, you still need to do that, except that you need to write the
code twice, and keep it compatible.

> That makes the code simpler and cleaner.

But it more than doubles the effort, as you need to re-implement
everything, and also keep everything compatible.

> And since Python 3 is a setuptools-free land, we won't have to worry
> in the 0.8 version about a possible setuptools cohabitation.

No, but we need to do that in 0.7 anyway, so that doesn't actually
remove the work.

> And people that are using setuptools under 2.x will have less pain to
> switch to different
> package names and drop their "import setuptools" infavor of something else,
> for their 3.x versions.

I don't think we should switch the name for the 3.x version. People
need to be able to write code that works under both 2.x and 3.x, and
we want to make that as painless as possible. And having different
names for the same module under 2.x and 3.x doesn't help with that.
What the name is doesn't matter, but it needs to be the same under 2.x
and 3.x.

> I don't see any benefit in having a mixed code for 2.x/3.x, but troubles ahead;

There are no troubles ahead. You don't have to worry.

> The maintenance effort between
> the two branches is not hard as long as there's a maintainer that makes sure
> every commit in the 0.8 branch is backported, like in Python-dev.
> I am willing to do this maintenance work.

This has no significant benefits, creates more work and more
confusion. There is simply no reason to do this.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64



-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Thu Jul 23 17:27:16 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 17:27:16 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
Message-ID: <94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>

On Thu, Jul 23, 2009 at 5:06 PM, Lennart Regebro<regebro at gmail.com> wrote:
> We are to create one
> compatible version for both Python 2 and Python 3.
[..]
> This has no significant benefits, creates more work and more
> confusion. There is simply no reason to do this.

Sorry, we are not making any progress in this thread :)

you don't seem to understand what backporting changes from a pure 3.x branch
to a 2.x compatible branch means. That's just a backport maintenance
work once the Py3K branch
has started + forwardport of part of the work done in 0.6. So there's
no "duplicate work".

As a developer, I am ok to have a mixed-code branch for a 0.7 version
that will not last,
but I don't want to work in a 2.x/3.x code soup for the future 0.8 branch.

I gave you the list of benefits and I don't see any benefits in what
you are describing.

I'd be curious to see how "clean" your 2.x/3.x code could be. How do
you intend for instance
to have a module with named exceptions that works in both versions,
without duplicating
the code. This work can be done afterwards, once we have a working
system under 3k.

Cheers
Tarek

From regebro at gmail.com  Thu Jul 23 17:51:33 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 08:51:33 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
Message-ID: <319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> you don't seem to understand what backporting changes from a pure 3.x branch
> to a 2.x compatible branch means. That's just a backport maintenance
> work once the Py3K branch
> has started + forwardport of part of the work done in 0.6. So there's
> no "duplicate work".

You want to reimplement each feature in 0.8 for Python3 in 0.7 for
Python 2. That *is* duplicate work.

> As a developer, I am ok to have a mixed-code branch for a 0.7 version
> that will not last,
> but I don't want to work in a 2.x/3.x code soup for the future 0.8 branch.

There is no 2.x/3.x code soup.

> I gave you the list of benefits and I don't see any benefits in what
> you are describing.

I explained why your benefits do not exist. If you can't see the
benefit of having one code set for one version of one software instead
of two, then I'm stumped.

> I'd be curious to see how "clean" your 2.x/3.x code could be.

You can look at it now. It exists.
http://code.google.com/p/python-incompatibility/source/browse/#svn/ports/setuptools/trunk

> How do you intend for instance to have a module with named exceptions that works in both versions,
> without duplicating the code.

Perhaps if you explained why you think it would be necessary to
duplicate the code, I could answer.


But OK, fine. I don't want to have stupid fights over stupid things.
The code exists on the link above. Do whatever you want with it.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Thu Jul 23 19:41:06 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 19:41:06 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
Message-ID: <94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>

On Thu, Jul 23, 2009 at 5:51 PM, Lennart Regebro<regebro at gmail.com> wrote:
>
> You want to reimplement each feature in 0.8 for Python3 in 0.7 for
> Python 2. That *is* duplicate work.

No, I want to backport it in 2.x syntax. Not reimplement it. That's
not code duplication.
For example if you make a change in 0.8, I'll backport it but make
sure its syntax is correct under 2.x,
because 0.7 would be Python 2.x

That's all.

>> I'd be curious to see how "clean" your 2.x/3.x code could be.
>
> You can look at it now. It exists.
> http://code.google.com/p/python-incompatibility/source/browse/#svn/ports/setuptools/trunk

I am not sure what to look at in there, do you have a place in there
that is based on setuptools trunk ?
Does it work with 2.x and 3.x at the same time ?

>
>> How do you intend for instance to have a module with named exceptions that works in both versions,
>> without duplicating the code.
>
> Perhaps if you explained why you think it would be necessary to
> duplicate the code, I could answer.

For all the backwards incompatibility Python 3 introduced.
Here's a small and incomplete list of points :

1/ import statements like this :

try:
  import something # python 2
except ImportError:
   import somethingelse # python 3

2/ named exceptions (I don't think setuptools have some, but we might
need them at some point)

except Something, e:

vs

except Something as e:


3/ bytes vs string issues

If we use for instance subprocess.Popen, it return bytes, no strings,
which has side effects on the consumers.
If we use regular expressions we have to make a difference between
string matching and byte matching
etc..


4/ etc...

So I am not sure : do you want to share the same code base for 2.x and
3.x and have in the code things like:
(in pseudo code)

if python 2:
   python 2. code
if python 3:
   python 3 code

I don't want that. What I am calling a "clean" code is a code base that doesn't
deal with two incompatible versions of Python

eg having a branch for 2.x and one for 3.x instead.
And when something is done on 3.x, it's backported wrt the 2.X syntax.

So I think the best strategy is to run 2to3 and finish the work on the
code to make it pure Python3,
then to split the code in several distributions and release it for
Python 3 usage.

>
> But OK, fine. I don't want to have stupid fights over stupid things.
> The code exists on the link above. Do whatever you want with it.
>

That's not stupid things, and that's not a fight. I don't understand
why you are over-reacting like that.
I won't do anything with this existing code if you're not helping ;)

But It's quite important imho to have the best strategy for next
releases, and I can't picture
the same branch with bits of 2.x and 3.x syntax in it.

I've been backporting and forwardporting distutils between python 2
and 3 for 6+ months
now, and I can tell it's not a lot of work, and both sides are clean
and concise because they don't try to work for
2.x and 3.x at the same time.


Regards
Tarek

From regebro at gmail.com  Thu Jul 23 20:56:08 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 11:56:08 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
Message-ID: <319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> I am not sure what to look at in there, do you have a place in there
> that is based on setuptools trunk ?
> Does it work with 2.x and 3.x at the same time ?

Yes, via 2to3 which for good reasons are the official way of
supporting both Python 2.x and 3.x at the same time.

> For all the backwards incompatibility Python 3 introduced.

OK, then I understand the question. The answer is: 2to3.

Having two branches is still a terrible idea, which just gives the
developers more work, and creates lots of code duplication. I
understand that this is not how it's done with Python itself, as
mentioned, but this is not Python itself. I understand you arguments
that it's not "much work". But it's still work that is not necessary.

> But It's quite important imho to have the best strategy for next
> releases, and I can't picture the same branch with bits of 2.x and 3.x syntax in it.

You don't have that. You write for Python 2, and convert it with 2to3.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From hanno at hannosch.eu  Thu Jul 23 22:03:43 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Thu, 23 Jul 2009 22:03:43 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
Message-ID: <5cae42b20907231303l1c010f10ta370ce5c4b9bed4f@mail.gmail.com>

On Thu, Jul 23, 2009 at 8:56 PM, Lennart Regebro<regebro at gmail.com> wrote:
>> But It's quite important imho to have the best strategy for next
>> releases, and I can't picture the same branch with bits of 2.x and 3.x syntax in it.
>
> You don't have that. You write for Python 2, and convert it with 2to3.

+1, that's the official way and we should stick to that.

And at some point we hopefully get the 3to2 tool and can switch the
process around with the 3.x code being the canonical one.

Hanno

From zooko at zooko.com  Thu Jul 23 22:22:38 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Thu, 23 Jul 2009 14:22:38 -0600
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
Message-ID: <5C83D5AE-94CD-4760-98B6-FCFD1CF53F00@zooko.com>

On Thursday,2009-07-23, at 12:56 , Lennart Regebro wrote:
>
> You don't have that. You write for Python 2, and convert it with 2to3.

+1

I will hopefully contribute some patches/testing/etc. for Distribute,  
but I have no plans to start using Python 3 in the forseeable  
future.  I will of course learn what I need to know in order to make  
sure my patches don't cause problems for Python 3 users, but  
supporting Python 2 is a chief requirement for me, and so I prefer to  
develop with Python 2.

Regards,

Zooko

From ziade.tarek at gmail.com  Thu Jul 23 22:30:25 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 22:30:25 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230717g71b37ebv1c1a4d1de42a86e5@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
Message-ID: <94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>

On Thu, Jul 23, 2009 at 8:56 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
>> I am not sure what to look at in there, do you have a place in there
>> that is based on setuptools trunk ?
>> Does it work with 2.x and 3.x at the same time ?
>
> Yes, via 2to3 which for good reasons are the official way of
> supporting both Python 2.x and 3.x at the same time.

Sorry I  am not sure to understand, you want to run 2to3 live ?
If not there will be two branches nevertheless, even if the second
one was generated via 2to3.

Or are you thinking about generated the 3k code at release time for
the 3.x version ?

What would be the precise process ?

From regebro at gmail.com  Thu Jul 23 22:37:32 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 13:37:32 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907230729n102d026cle47b4a5b79d1be72@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
Message-ID: <319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> Or are you thinking about generated the 3k code at release time for
> the 3.x version ?

Either release time or install time (although install time is tricky,
as setuptools currently depends on itself, so release time is the way
to go at least before a refactoring).

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Thu Jul 23 22:51:21 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 22:51:21 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230737s1e4d139cx9b9a08a331c1e5e7@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
Message-ID: <94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>

On Thu, Jul 23, 2009 at 10:37 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
>> Or are you thinking about generated the 3k code at release time for
>> the 3.x version ?
>
> Either release time or install time (although install time is tricky,
> as setuptools currently depends on itself, so release time is the way
> to go at least before a refactoring).

Ok I'm convinced now :)

Having this for Distribute 0.6 could make Py3k developer switch on it
very soon but on the other hand, it wuld force them to change their imports
by the time 0.7 is out.

OTOH, if they know it, they would probably be grateful to have something
working today under 3.x

So what is the work left to be done so it works fully for our code base ?

From regebro at gmail.com  Thu Jul 23 22:53:46 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 13:53:46 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907230748q363183afqe45f8e10c432def9@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
Message-ID: <319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> So what is the work left to be done so it works fully for our code base ?

Making a diff of the work done of the google code repo, and getting it
into the hg repository.
It's not that much work, but as noted I failed (in several ways) last time. :-/

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Thu Jul 23 23:08:29 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 23 Jul 2009 23:08:29 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230806y74957313v2e3f6e26d15317e0@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
Message-ID: <94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>

On Thu, Jul 23, 2009 at 10:53 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
>> So what is the work left to be done so it works fully for our code base ?
>
> Making a diff of the work done of the google code repo, and getting it
> into the hg repository.
> It's not that much work, but as noted I failed (in several ways) last time. :-/

I can help for the hg part,

So how this will look at the end ? a conversion function that can be
called when releasing
for instance ?

>
> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
>



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

From regebro at gmail.com  Thu Jul 23 23:59:28 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 23 Jul 2009 14:59:28 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907230827n7f55b56csfad24ce3430f2be8@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
Message-ID: <319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>

2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
> So how this will look at the end ? a conversion function that can be
> called when releasing
> for instance ?

Something like that. There is a port.sh script that will make a port
(from a copy in /tmp/) and I used that to do the Python 3 tgz's before
if I remember correctly. There are other options.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From david.lyon at preisshare.net  Fri Jul 24 03:49:06 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 23 Jul 2009 21:49:06 -0400
Subject: [Distutils] Distutils History
In-Reply-To: <d34314100907220117t2173f846wf1ef24afc60a3d1c@mail.gmail.com>
References: <d34314100907220117t2173f846wf1ef24afc60a3d1c@mail.gmail.com>
Message-ID: <5ddf4c40078507f394768372a76eac7b@preisshare.net>

On Wed, 22 Jul 2009 04:17:42 -0400, anatoly techtonik <techtonik at gmail.com>
wrote:
> I've added a chapter on Distutils history to
> http://wiki.python.org/moin/Distutils to provide an overview why
> current Distutils in not sufficient anymore and needs refactoring. I
> would like to ask for review to see if that information is more
> appropriate for Distutils/Critics

I've updated 

  http://wiki.python.org/moin/Distutils/Proposals

and put some ideas down on updating setup.py and showing a preview on
how it could benefit from being a class rather than a procedure.

I feel that regular developers will find it easier to understand than
the traditional procedural setup.py. It will give them information
on the platform, and allow them to make conditional installs based
on the underlying environment.

This will in turn lead to more flexibility and reduce the
necessity for developers to resort to hacks and undocumented features.

(I wasn't sure on how to make it a subpage - I couldn't find the
button.)

Regards

David


From brian at vanguardistas.net  Fri Jul 24 12:24:09 2009
From: brian at vanguardistas.net (Brian Sutherland)
Date: Fri, 24 Jul 2009 12:24:09 +0200
Subject: [Distutils] Low Level API for translating
	distutils/setuptools	metatdata to Debian metadata
In-Reply-To: <20090722155233.GA43860@Boo.lan>
References: <20090529091202.GB22620@Boo.lan>
	<38B432CD-A600-4FB9-AF88-9D18DB648045@zooko.com>
	<20090722155233.GA43860@Boo.lan>
Message-ID: <20090724102409.GB10205@Boo.local>

Hi Zooko,

I just implemented what I was talking about below on the van.pydeb
trunk. Running the script against unstable I get a list of 565 packages
that don't match the default mapping, I've added them to van.pydeb's
database.

The checkin is here:
    http://mail.zope.org/pipermail/checkins/2009-July/036397.html

If you have the time, please have a look over the list to see that it
contains the packages you need correctly. At least pyOpenSSL you mention
below is handled correctly.

I probably will make a new release of van.pydeb in a week or so.

On Wed, Jul 22, 2009 at 05:52:33PM +0200, Brian Sutherland wrote:
> On Wed, Jul 22, 2009 at 08:41:38AM -0600, Zooko Wilcox-O'Hearn wrote:
> >>     * Provides a mapping between python project names and Debian
> >>       binary/source package names
> >>     * Converts setuptools versions to Debian versions while  
> >> maintaining
> >>       sort order
> >>     * Can introspect an .egg-info directory to figure out the Debian
> >>       dependencies for use in the debian/control file. It can also
> >>       handle/understand extras (I Hope!)
> >
> > I looked briefly at this code, and it appears that it is doing purely  
> > syntactic mapping between Debian package names and Python distribution 
> > names, for example:
> >
> > def py_to_bin(setuptools_project):
> >     """Convert a setuptools project name to a debian binary package  
> > name"""
> >     return _PY_TO_BIN.get(setuptools_project, 'python-%s' %  
> > setuptools_project.lower())
> >
> > This works most of the time, but it isn't reliable.  For example, the  
> > module name is "OpenSSL", the distribution name is "pyOpenSSL", and the 
> > Debian package name is "python-openssl":
> >
> > http://packages.debian.org/sid/amd64/python-openssl/filelist
> >
> > That's why I contributed a patch to stdeb which uses the Debian database 
> > of which files are included in which packages (the same database that 
> > generates the web page linked above):
> >
> > http://github.com/astraw/stdeb/blob/647dd441a1712f8df37b5f7f5ba22ab6aeb2c3e7/stdeb/util.py#L135
> >
> > The way stdeb does it looks in the database for files named  
> > "$DISTRIBUTION-$VERSION-py$PYTHONVERSION.egg-info".  The Debian package 
> > that includes such a file is the Debian package that you need to install 
> > in order to satisfy a dependency on $DISTRIBUTION, $VERSION.  This works 
> > regardless of whether the Python package is built with distutils or 
> > setuptools, and indeed it works for all packages that I know of.  (There 
> > is actually one exception: the Debian package for setuptools itself 
> > doesn't include a version number in its .egg-info filename:
> >
> > http://packages.debian.org/sid/amd64/python-setuptools/filelist
> >
> > It has a file named:
> >
> > /usr/share/pyshared/setuptools.egg-info/
> >
> > I guess we should add a fall-back-with-warning behavior to stdeb that if 
> > it can't find "$DISTRIBUTION-$VERSION.egg-info", but it can find  
> > "$DISTRIBUTION.egg-info", then it should (optionally) assume that the  
> > Debian package that has that file will satisfy the requirement,  
> > regardless of the version number in the requirement.   That, or someone 
> > should open a ticket asking Debian to add a version number to that 
> > filename.
> >
> > The exact regexp is currently:
> >
> > egginfore=("(/(%s)(?:-[^/]+)?(?:-py[0-9]\.[0-9.]+)?\.egg-info)"
> >                % '|'.join(req.project_name for req in requirements))
> >
> > If you would be interested in including this mechanism to query the  
> > database in van.pydeb, I would be happy to advise you.
> 
> Hi Zooko,
> 
> van.pydeb is designed to be run at package build time, rather than at
> the time you create the source package. I assume that's when stdeb's
> code runs? Using apt-file during package build time on one of the Debian
> project's auto-builders will not be acceptable (I assume).
> 
> Also, "isn't reliable" has very different meanings :) van.pydeb is
> reliable in that it produces the same answer independently of the
> machine it's run on. But it's not reliable in that often the answer is
> just plain wrong;)
> 
> The results of stdeb's mechanism depend on the configuration of the
> machine where you run it (or even if you havn't run apt-file update
> recently).
> 
> So, I don't think van.pydeb can use stdeb's mechanism as-is, but I'd
> love to see a patch (with tests!) for a variation of it. I was thinking
> of writing a script/function that could use apt-file to generate a list
> of python->debian package mappings that don't fit the heuristic.
> 
> So py_to_bin could be re-written as:
> 
>     def py_to_bin(setuptools_project):
>         """Convert a setuptools project name to a debian binary package name"""
>         result = _HANDWRITTEN_PY_TO_BIN.get(setuptools_project)
>         if result is None:
>             result = _APT_FILE_GENERATED_PY_TO_BIN.get(setuptools_project)
>         if result is None:
>             result = 'python-%s' % setuptools_project.lower())
>         return result
> 
> The _APT_FILE_GENERATED_PY_TO_BIN could be re-generated periodically.
> I'm hoping that'll be enough given that:
> 
>     * packages don't change names that frequently
>     * there should be few that don't fit the heuristic (*cough* policy *cough*)
> 
> > Regards,
> >
> > Zooko
> 
> -- 
> Brian Sutherland

-- 
Brian Sutherland

From ziade.tarek at gmail.com  Fri Jul 24 15:18:08 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Jul 2009 15:18:08 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907230851m46c5e056jdab3c7010b4df117@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
Message-ID: <94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>

On Thu, Jul 23, 2009 at 11:59 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/23 Tarek Ziad? <ziade.tarek at gmail.com>:
>> So how this will look at the end ? a conversion function that can be
>> called when releasing
>> for instance ?
>
> Something like that. There is a port.sh script that will make a port
> (from a copy in /tmp/) and I used that to do the Python 3 tgz's before
> if I remember correctly. There are other options.
>

Ok then , what about working on that script within the default branch,
I don't think it interfers at all with the rest,

I have a release.sh script that creates all .egg and the .tar.gz,
You could add your things in a separate directory in the repo and hook
it in release.sh and possibly in setup.py, so it builds for python 3,

If everyone agrees and if you have time to do this,

I can postpone the 0.6 release for a week or so, until this is ready, so we can
have 0.6 for Python 3.

In any case I am going for a week of vacation starting tomorrow, so the
0.6 will not be released before august the 3rd,

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

From regebro at gmail.com  Fri Jul 24 15:29:47 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 24 Jul 2009 06:29:47 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
Message-ID: <319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>

2009/7/24 Tarek Ziad? <ziade.tarek at gmail.com>:
> I can postpone the 0.6 release for a week or so, until this is ready, so we can
> have 0.6 for Python 3.

I think we should make a 2.x only release first. The changes to
support Python 3 are small but numerous and since the test-coverage
isn't that great I'm worried it will insert subtle bugs. I would be
less worried if we can have a longer test-period after these changes.

On the other hand, if we do merge these changes before the 0.6 release
they will quickly get tested. ;)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Jul 24 15:43:43 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Jul 2009 15:43:43 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
Message-ID: <94bdd2610907240643w15f3f68dxc7175dde203be9a6@mail.gmail.com>

On Fri, Jul 24, 2009 at 3:29 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/24 Tarek Ziad? <ziade.tarek at gmail.com>:
>> I can postpone the 0.6 release for a week or so, until this is ready, so we can
>> have 0.6 for Python 3.
>
> I think we should make a 2.x only release first. The changes to
> support Python 3 are small but numerous and since the test-coverage
> isn't that great I'm worried it will insert subtle bugs. I would be
> less worried if we can have a longer test-period after these changes.
>
> On the other hand, if we do merge these changes before the 0.6 release
> they will quickly get tested. ;)

Right, I am +1 for adding it in 0.6, and having a 0.6.1 for thoses fixes,

From santagada at gmail.com  Fri Jul 24 15:59:34 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Fri, 24 Jul 2009 10:59:34 -0300
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
Message-ID: <AD896FB3-7D9F-45DA-B3BE-5651B2FFE4E5@gmail.com>


On Jul 24, 2009, at 10:29 AM, Lennart Regebro wrote:

> 2009/7/24 Tarek Ziad? <ziade.tarek at gmail.com>:
>> I can postpone the 0.6 release for a week or so, until this is  
>> ready, so we can
>> have 0.6 for Python 3.
>
> I think we should make a 2.x only release first. The changes to
> support Python 3 are small but numerous and since the test-coverage
> isn't that great I'm worried it will insert subtle bugs. I would be
> less worried if we can have a longer test-period after these changes.
>
> On the other hand, if we do merge these changes before the 0.6 release
> they will quickly get tested. ;)


People using python 3x don't have support for setuptools so they would  
understand if you release early a beta version. And I think you  
should, not having setutools is a problem for every package being  
converted to python 3.1

--
Leonardo Santagada
santagada at gmail.com




From ronaldoussoren at mac.com  Fri Jul 24 16:06:00 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 24 Jul 2009 16:06:00 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort -
 plans	proposal for 0.7/0.8
In-Reply-To: <AD896FB3-7D9F-45DA-B3BE-5651B2FFE4E5@gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>
	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
	<AD896FB3-7D9F-45DA-B3BE-5651B2FFE4E5@gmail.com>
Message-ID: <137114403591940950094038135487874473951-Webmail@me.com>

 
On Friday, 24 July, 2009, at 03:59PM, "Leonardo Santagada" <santagada at gmail.com> wrote:
>
>On Jul 24, 2009, at 10:29 AM, Lennart Regebro wrote:
>
>> 2009/7/24 Tarek Ziad? <ziade.tarek at gmail.com>:
>>> I can postpone the 0.6 release for a week or so, until this is  
>>> ready, so we can
>>> have 0.6 for Python 3.
>>
>> I think we should make a 2.x only release first. The changes to
>> support Python 3 are small but numerous and since the test-coverage
>> isn't that great I'm worried it will insert subtle bugs. I would be
>> less worried if we can have a longer test-period after these changes.
>>
>> On the other hand, if we do merge these changes before the 0.6 release
>> they will quickly get tested. ;)
>
>
>People using python 3x don't have support for setuptools so they would  
>understand if you release early a beta version. And I think you  
>should, not having setutools is a problem for every package being  
>converted to python 3.1

The issue with merging python3-related changes is not that the python3 port would have a beta-status, but that there is a risk that this will accidently break python2 support.

I agree with Lennart that a 2.x only release would be better, especially because it would be possible to do a 0.7 alpha/beta release short after the stable 0.6 release.

Ronald
>
>--
>Leonardo Santagada
>santagada at gmail.com
>
>
>
>_______________________________________________
>Distutils-SIG maillist  -  Distutils-SIG at python.org
>http://mail.python.org/mailman/listinfo/distutils-sig
>
>

From ziade.tarek at gmail.com  Fri Jul 24 16:24:33 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Jul 2009 16:24:33 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <137114403591940950094038135487874473951-Webmail@me.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
	<AD896FB3-7D9F-45DA-B3BE-5651B2FFE4E5@gmail.com>
	<137114403591940950094038135487874473951-Webmail@me.com>
Message-ID: <94bdd2610907240724w5091c221p8508dd7003086b3f@mail.gmail.com>

On Fri, Jul 24, 2009 at 4:06 PM, Ronald Oussoren<ronaldoussoren at mac.com> wrote:
>
> I agree with Lennart that a 2.x only release would be better, especially because it would be possible to do a 0.7 alpha/beta release short after the stable 0.6 release.

Notice that 0.7 will rename the setuptools package, the
pkg_resources.py module, and the easy_install script

Meaning that if we don't add py3 support in the 0.6.x series, people
will *have* to rename their imports if they want to
use it under Python 3.


Tarek

From regebro at gmail.com  Fri Jul 24 16:33:31 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 24 Jul 2009 07:33:31 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <94bdd2610907240724w5091c221p8508dd7003086b3f@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
	<AD896FB3-7D9F-45DA-B3BE-5651B2FFE4E5@gmail.com>
	<137114403591940950094038135487874473951-Webmail@me.com>
	<94bdd2610907240724w5091c221p8508dd7003086b3f@mail.gmail.com>
Message-ID: <319e029f0907240733g76f87035webb34e621263bf52@mail.gmail.com>

2009/7/24 Tarek Ziad? <ziade.tarek at gmail.com>:
> On Fri, Jul 24, 2009 at 4:06 PM, Ronald Oussoren<ronaldoussoren at mac.com> wrote:
>>
>> I agree with Lennart that a 2.x only release would be better, especially because it would be possible to do a 0.7 alpha/beta release short after the stable 0.6 release.
>
> Notice that 0.7 will rename the setuptools package, the
> pkg_resources.py module, and the easy_install script
>
> Meaning that if we don't add py3 support in the 0.6.x series, people
> will *have* to rename their imports if they want to
> use it under Python 3.

Yeah, but is that a problem, as the renamed version will exist for
Python 2 as well, I assume?


In any case, I have no strong opinion on whether 3.x support comes in
0.6 or 0.7.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Jul 24 16:40:32 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Jul 2009 16:40:32 +0200
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <319e029f0907240733g76f87035webb34e621263bf52@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
	<AD896FB3-7D9F-45DA-B3BE-5651B2FFE4E5@gmail.com>
	<137114403591940950094038135487874473951-Webmail@me.com>
	<94bdd2610907240724w5091c221p8508dd7003086b3f@mail.gmail.com>
	<319e029f0907240733g76f87035webb34e621263bf52@mail.gmail.com>
Message-ID: <94bdd2610907240740x10e9d707hd152f8dcbaa96b3b@mail.gmail.com>

On Fri, Jul 24, 2009 at 4:33 PM, Lennart Regebro<regebro at gmail.com> wrote:
> 2009/7/24 Tarek Ziad? <ziade.tarek at gmail.com>:
>> On Fri, Jul 24, 2009 at 4:06 PM, Ronald Oussoren<ronaldoussoren at mac.com> wrote:
>>>
>>> I agree with Lennart that a 2.x only release would be better, especially because it would be possible to do a 0.7 alpha/beta release short after the stable 0.6 release.
>>
>> Notice that 0.7 will rename the setuptools package, the
>> pkg_resources.py module, and the easy_install script
>>
>> Meaning that if we don't add py3 support in the 0.6.x series, people
>> will *have* to rename their imports if they want to
>> use it under Python 3.
>
> Yeah, but is that a problem, as the renamed version will exist for
> Python 2 as well, I assume?

no, it just changes the constraints :

0.6 : python 2 + no renaming
0.7 : python 2 or 3 + renaming

or

0.6 : python 2 or 3 + no renaming
0.7 : python 2 or 3 + renaming



>
>
> In any case, I have no strong opinion on whether 3.x support comes in
> 0.6 or 0.7.
>

me neither, so let's drop that for 0.6.

The work left for 0.6 is:

- writing the zc.buildout bootstrap with a patch
  (zc.buildout.buildout.boostrap needs to be patched :()

- finish the tests under various environments (I didn't test too much
under win32)

(help welcome :))

So the release should be pushed around the 5th or 6th,

From waterbug at pangalactic.us  Fri Jul 24 16:03:29 2009
From: waterbug at pangalactic.us (Stephen Waterbury)
Date: Fri, 24 Jul 2009 10:03:29 -0400
Subject: [Distutils] [Distribute] Python 3 porting effort -
 plans	proposal for 0.7/0.8
In-Reply-To: <319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>	<94bdd2610907231041i2d74002foef940e9a36721c26@mail.gmail.com>	<319e029f0907231156h6decc24cob24441de756a794a@mail.gmail.com>	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
Message-ID: <4A69BF31.6000302@pangalactic.us>

Lennart Regebro wrote:
> On the other hand, if we do merge these changes before the 0.6 release
> they will quickly get tested. ;)

Ah, yes:  the Microsoft Strategy.  ;)



From regebro at gmail.com  Fri Jul 24 16:49:08 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 24 Jul 2009 07:49:08 -0700
Subject: [Distutils] [Distribute] Python 3 porting effort - plans
	proposal for 0.7/0.8
In-Reply-To: <4A69BF31.6000302@pangalactic.us>
References: <94bdd2610907230707x603da465q7836a4690184a8c@mail.gmail.com>
	<94bdd2610907231330r575e80e7j8aa9632063dc6869@mail.gmail.com>
	<319e029f0907231337i165c6a2fja98b21140c69d8d4@mail.gmail.com>
	<94bdd2610907231351s6eec9612s65ee518b26bdc96b@mail.gmail.com>
	<319e029f0907231353j69b19782s82e83b77d4ef89e3@mail.gmail.com>
	<94bdd2610907231408h3e9df54aod34fc66f3c826919@mail.gmail.com>
	<319e029f0907231459j13e0e58fh2fa68127503f7c6d@mail.gmail.com>
	<94bdd2610907240618n6fad3678ic6557405b567470d@mail.gmail.com>
	<319e029f0907240629u264e64bfg531d700a1e00335c@mail.gmail.com>
	<4A69BF31.6000302@pangalactic.us>
Message-ID: <319e029f0907240749h6c12ab6dx777bd5d0e0fe6e99@mail.gmail.com>

2009/7/24 Stephen Waterbury <waterbug at pangalactic.us>:
> Lennart Regebro wrote:
>>
>> On the other hand, if we do merge these changes before the 0.6 release
>> they will quickly get tested. ;)
>
> Ah, yes: ?the Microsoft Strategy. ?;)

:-)

It's also a common OS strategy, for the simple reason that few people
seem bothered to test the betas...

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From david.lyon at preisshare.net  Sat Jul 25 02:42:29 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 24 Jul 2009 20:42:29 -0400
Subject: [Distutils] Setup.py as a Class, not a Procedure
In-Reply-To: <4A66856F.9000907@taupro.com>
References: <20090721134746.2543.1430938239.divmod.quotient.3955@henry.divmod.com>	<20090721150950.2543.358577142.divmod.quotient.3966@henry.divmod.com>	<20090721180943.3A4E53A4099@sparrow.telecommunity.com>
	<b9caad44d3afbd4eb122034e863cf188@preisshare.net>
	<4A66856F.9000907@taupro.com>
Message-ID: <b302c34241c685e5d9c66e420d55690b@preisshare.net>

Tarek,

Recently I suggested having setup.py implemented as
a class and not a procedure.

I posted some notes on http://wiki.python.org/moin/Distutils/Proposals

Do you have any comment?


David



From exarkun at divmod.com  Sat Jul 25 02:55:11 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Fri, 24 Jul 2009 20:55:11 -0400
Subject: [Distutils] Setup.py as a Class, not a Procedure
In-Reply-To: <b302c34241c685e5d9c66e420d55690b@preisshare.net>
Message-ID: <20090725005511.388.968890881.divmod.quotient.78@henry.divmod.com>

On Fri, 24 Jul 2009 20:42:29 -0400, David Lyon <david.lyon at preisshare.net> wrote:
>Tarek,
>
>Recently I suggested having setup.py implemented as
>a class and not a procedure.
>
>I posted some notes on http://wiki.python.org/moin/Distutils/Proposals
>
>Do you have any comment?
>

David,

I think you should flesh out your proposal a bit more:

  1) List the drawbacks of the current API.  I'm sure we can all think of a
     few, but collecting them in a persistent location will make it easier
     to think about the replacement.

  2) Write up how switching to an "Object Oriented" API will help things.
     This can probably mostly be responses to the list of stuff from #1, but
     it's also useful to talk about how this approach is better than fixing
     the problems without trying for such a major overhaul.

  3) Lose the stuff about setup.cfg - where configuration data goes can be
     the same regardless of what the Python API looks like.  This might be
     a good change, but it doesn't seem related to this proposal.

  4) pre_setup and post_setup don't seem to need to exist.  If the main
     setup entry-point is a class with some methods, then subclasses can
     override these methods to do things before and after them; special
     support isn't required.

Also, I think you were having trouble figuring out how to make a new sub-
page on the wiki.  If you just visit an URL like

  http://wiki.python.org/moin/Distutils/Proposals/ObjectOriented

Then you'll be presented with a link to create that page.  Then you can link
to it from the proposals page.

Jean-Paul

From david.lyon at preisshare.net  Sat Jul 25 03:35:58 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Fri, 24 Jul 2009 21:35:58 -0400
Subject: [Distutils] Setup.py as a Class, not a Procedure
In-Reply-To: <20090725005511.388.968890881.divmod.quotient.78@henry.divmod.com>
References: <20090725005511.388.968890881.divmod.quotient.78@henry.divmod.com>
Message-ID: <2e75b2190502475ef3b49df52026dfb5@preisshare.net>



On Fri, 24 Jul 2009 20:55:11 -0400, Jean-Paul Calderone
<exarkun at divmod.com>
> I think you should flesh out your proposal a bit more:

Thanks Jean-Paul, I can do that.

>   3) Lose the stuff about setup.cfg - where configuration data goes can
be
>      the same regardless of what the Python API looks like.

Very true. It simply becomes an issue of persistence.

>   4) pre_setup and post_setup don't seem to need to exist.  If the main
>      setup entry-point is a class with some methods, then subclasses can
>      override these methods to do things before and after them; special
>      support isn't required.

I can see your point. I'll investigate it further in my own time.

> Also, I think you were having trouble figuring out how to make a new sub-
> page on the wiki.  If you just visit an URL ..
> hen you can link to it from the proposals page.

Yes that seems to work.

Thanks Jean Paul

I'll go away and do that.

Take care

David

From adeel2 at umbc.edu  Sat Jul 25 19:20:22 2009
From: adeel2 at umbc.edu (Adeel Ahmad Khan)
Date: Sat, 25 Jul 2009 13:20:22 -0400
Subject: [Distutils] Data files with setuptools
Message-ID: <3b37a7af0907251020y5f6aab2t3f1e29f9fbfd9019@mail.gmail.com>

I am having some trouble including data files in the egg installed by
setuptools.  I've listed the data files in MANIFEST.in and set
include_package_data = True.

    % ls
    LICENSE		README		ez_setup.py	timed.py
    MANIFEST.in	cmdapp.py	setup.py

    % cat setup.py
    from ez_setup import use_setuptools
    use_setuptools()
    from setuptools import setup

    setup(
      # ...
      py_modules=['timed', 'cmdapp'],
      entry_points={'console_scripts': ['timed = timed:main']},
      include_package_data=True,
      install_requires=['PyYAML'],
      zip_safe=False,
    )

    % cat MANIFEST.in
    include *.py
    include README
    include LICENSE

    % sudo python setup.py install
    running install
    running bdist_egg
    running egg_info
    creating timed.egg-info
    writing requirements to timed.egg-info/requires.txt
    writing timed.egg-info/PKG-INFO
    writing top-level names to timed.egg-info/top_level.txt
    writing dependency_links to timed.egg-info/dependency_links.txt
    writing entry points to timed.egg-info/entry_points.txt
    writing manifest file 'timed.egg-info/SOURCES.txt'
    reading manifest file 'timed.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    writing manifest file 'timed.egg-info/SOURCES.txt'
    installing library code to build/bdist.macosx-10.3-i386/egg
    running install_lib
    running build_py
    creating build
    creating build/lib
    copying timed.py -> build/lib
    copying cmdapp.py -> build/lib
    creating build/bdist.macosx-10.3-i386
    creating build/bdist.macosx-10.3-i386/egg
    copying build/lib/cmdapp.py -> build/bdist.macosx-10.3-i386/egg
    copying build/lib/timed.py -> build/bdist.macosx-10.3-i386/egg
    byte-compiling build/bdist.macosx-10.3-i386/egg/cmdapp.py to cmdapp.pyc
    byte-compiling build/bdist.macosx-10.3-i386/egg/timed.py to timed.pyc
    creating build/bdist.macosx-10.3-i386/egg/EGG-INFO
    copying timed.egg-info/PKG-INFO -> build/bdist.macosx-10.3-i386/egg/EGG-INFO
    copying timed.egg-info/SOURCES.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
    copying timed.egg-info/dependency_links.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
    copying timed.egg-info/entry_points.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
    copying timed.egg-info/not-zip-safe ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
    copying timed.egg-info/requires.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
    copying timed.egg-info/top_level.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
    creating dist
    creating 'dist/timed-0.11-py2.6.egg' and adding
'build/bdist.macosx-10.3-i386/egg' to it
    removing 'build/bdist.macosx-10.3-i386/egg' (and everything under it)
    Processing timed-0.11-py2.6.egg
    removing '/usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg'
(and everything under it)
    creating /usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg
    Extracting timed-0.11-py2.6.egg to /usr/local/lib/python2.6/site-packages
    timed 0.11 is already the active version in easy-install.pth
    Installing timed script to /usr/local/bin

    Installed /usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg
    Processing dependencies for timed==0.11
    Searching for PyYAML==3.08
    Best match: PyYAML 3.08
    Processing PyYAML-3.08-py2.6-macosx-10.3-i386.egg
    PyYAML 3.08 is already the active version in easy-install.pth

    Using /usr/local/lib/python2.6/site-packages/PyYAML-3.08-py2.6-macosx-10.3-i386.egg
    Finished processing dependencies for timed==0.11

    % ls /usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg
    EGG-INFO	cmdapp.py	cmdapp.pyc	timed.py	timed.pyc

Why isn't README there?  What do I need to do to include it?

From eric at swenson.org  Fri Jul 24 06:44:42 2009
From: eric at swenson.org (Eric Swenson)
Date: Thu, 23 Jul 2009 21:44:42 -0700
Subject: [Distutils] setuptools for win32 py2.6
Message-ID: <e8ea99a20907232144k217f25a4pf13bf51f7536e0e7@mail.gmail.com>

Hello,
I notice that the download page doesn't include a win32 installer for
setuptools and python 2.6.  I built one from sources but wonder if we should
have one up on the download page.  Do you have one available or can I give
you one I built to include on the download page?  THanks. -- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090723/e762c134/attachment.htm>

From kadeel at gmail.com  Sat Jul 25 23:28:20 2009
From: kadeel at gmail.com (Adeel Ahmad Khan)
Date: Sat, 25 Jul 2009 17:28:20 -0400
Subject: [Distutils] Including data files with setuptools
Message-ID: <3b37a7af0907251428g34ea514fs3f3210addfceab9@mail.gmail.com>

I am having some trouble including data files in the egg installed by
setuptools.  I've listed the data files in MANIFEST.in and set
include_package_data = True.

   % ls
   LICENSE             README          ez_setup.py     timed.py
   MANIFEST.in cmdapp.py       setup.py

   % cat setup.py
   from ez_setup import use_setuptools
   use_setuptools()
   from setuptools import setup

   setup(
     # ...
     py_modules=['timed', 'cmdapp'],
     entry_points={'console_scripts': ['timed = timed:main']},
     include_package_data=True,
     install_requires=['PyYAML'],
     zip_safe=False,
   )

   % cat MANIFEST.in
   include *.py
   include README
   include LICENSE

   % sudo python setup.py install
   running install
   running bdist_egg
   running egg_info
   creating timed.egg-info
   writing requirements to timed.egg-info/requires.txt
   writing timed.egg-info/PKG-INFO
   writing top-level names to timed.egg-info/top_level.txt
   writing dependency_links to timed.egg-info/dependency_links.txt
   writing entry points to timed.egg-info/entry_points.txt
   writing manifest file 'timed.egg-info/SOURCES.txt'
   reading manifest file 'timed.egg-info/SOURCES.txt'
   reading manifest template 'MANIFEST.in'
   writing manifest file 'timed.egg-info/SOURCES.txt'
   installing library code to build/bdist.macosx-10.3-i386/egg
   running install_lib
   running build_py
   creating build
   creating build/lib
   copying timed.py -> build/lib
   copying cmdapp.py -> build/lib
   creating build/bdist.macosx-10.3-i386
   creating build/bdist.macosx-10.3-i386/egg
   copying build/lib/cmdapp.py -> build/bdist.macosx-10.3-i386/egg
   copying build/lib/timed.py -> build/bdist.macosx-10.3-i386/egg
   byte-compiling build/bdist.macosx-10.3-i386/egg/cmdapp.py to cmdapp.pyc
   byte-compiling build/bdist.macosx-10.3-i386/egg/timed.py to timed.pyc
   creating build/bdist.macosx-10.3-i386/egg/EGG-INFO
   copying timed.egg-info/PKG-INFO -> build/bdist.macosx-10.3-i386/egg/EGG-INFO
   copying timed.egg-info/SOURCES.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
   copying timed.egg-info/dependency_links.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
   copying timed.egg-info/entry_points.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
   copying timed.egg-info/not-zip-safe ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
   copying timed.egg-info/requires.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
   copying timed.egg-info/top_level.txt ->
build/bdist.macosx-10.3-i386/egg/EGG-INFO
   creating dist
   creating 'dist/timed-0.11-py2.6.egg' and adding
'build/bdist.macosx-10.3-i386/egg' to it
   removing 'build/bdist.macosx-10.3-i386/egg' (and everything under it)
   Processing timed-0.11-py2.6.egg
   removing '/usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg'
(and everything under it)
   creating /usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg
   Extracting timed-0.11-py2.6.egg to /usr/local/lib/python2.6/site-packages
   timed 0.11 is already the active version in easy-install.pth
   Installing timed script to /usr/local/bin

   Installed /usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg
   Processing dependencies for timed==0.11
   Searching for PyYAML==3.08
   Best match: PyYAML 3.08
   Processing PyYAML-3.08-py2.6-macosx-10.3-i386.egg
   PyYAML 3.08 is already the active version in easy-install.pth

   Using /usr/local/lib/python2.6/site-packages/PyYAML-3.08-py2.6-macosx-10.3-i386.egg
   Finished processing dependencies for timed==0.11

   % ls /usr/local/lib/python2.6/site-packages/timed-0.11-py2.6.egg
   EGG-INFO    cmdapp.py       cmdapp.pyc      timed.py        timed.pyc

Why isn't README there?  What do I need to do to include it?

From zopyxfilter at gmail.com  Mon Jul 20 06:50:34 2009
From: zopyxfilter at gmail.com (zopyxfilter at gmail.com)
Date: Mon, 20 Jul 2009 06:50:34 +0200
Subject: [Distutils] Fork mess
In-Reply-To: <20090719200456.9E9193A411C@sparrow.telecommunity.com>
References: <94bdd2610907151713t57336a5fi6a028736ced43bfe@mail.gmail.com>	<87my72d8wt.fsf@benfinney.id.au>
	<4A61355E.50706@plope.com>	<87eised550.fsf@benfinney.id.au>
	<4A6154B0.6000707@plope.com>	<20090718194729.D5B8D3A403A@sparrow.telecommunity.com>	<5cae42b20907181605g3ecb63d8rbd4e11ffb4b9432a@mail.gmail.com>	<20090719022831.959983A403A@sparrow.telecommunity.com>	<94bdd2610907190212g3c766254s1131a68d591014f@mail.gmail.com>	<20090719185220.C15EE3A40D9@sparrow.telecommunity.com>	<319e029f0907191213g240981d9v3b5493a489ec13db@mail.gmail.com>	<op.uxbyqkl71q4jlt@whymac>
	<20090719200456.9E9193A411C@sparrow.telecommunity.com>
Message-ID: <4A63F79A.8060301@gmail.com>

On 19.07.09 22:08, P.J. Eby wrote:
> At 12:50 PM 7/19/2009 -0700, Sridhar Ratnakumar wrote:
>> On Sun, 19 Jul 2009 12:13:25 -0700, Lennart Regebro <regebro at gmail.com>
>> wrote:
>>
>>> 2009/7/19 P.J. Eby <pje at telecommunity.com>:
>>>> I'm actually kind of hoping that if I make Discovery nice enough,
>>>> somebody
>>>> else will refactor setuptools to use it.  ;-)  (Or just replace
>>>> setuptools
>>>> with something better.)
>>> We hope that too. But we don't think Discovery will be nice enough if
>>> only you work on it. That is after all the greatness of open source:
>>> It enables people from all around the world cooperate to make
>>> something much greater than each one can create by himself. We can
>>> sure use your experience, insight and help. And you can use our work
>>> time. Discovery can become way greater if we work together instead of
>>> each by ourself.
>>
>> +1
>>
>> I'm already sensing some vague inconvenience .. distutils, setuptools,
>> Distribute, Discovery??? Too much for a language that boasts about
>> having
>> only one obvious way to do it.
>>
>> Is it not sensible to combine the efforts put into Distribute and
>> Discovery? Call Discovery 'Distribute 2.0' (future work) while we
>> work on
>> stabilizing setuptools as Distribute 1.0?
>>
>> If it was me - I'd certainly do it and that wouldn't jeopardize the
>> potential fun involved.
>
> Already, just this bit where strangers on the internet discuss how I
> should spend my spare time for their benefit is making the whole idea
> less fun.  If people want to tell me how I should spend my time, they
> can pay me.  (Otherwise, they can ask nicely, instead of lecturing.)
Nobody cares about how you spend your spare time. The point is that the
maintainer is sitting like a clucking hen on their eggs without
giving them any care and without letting other people care about them.
So we are at the point where the hen must go in order to save the eggs
or it must be shot in order proceed for the sake of the community. The
discussion about a qualified maintainer is just absurd. All people
involved in this issue for bring setuptools forward have a strong record
in managing packages and a deep understanding in the setuptools problem.
Please don't treat highly respected members of the Zope and Plone world
like idiots.

Andreas

From pje at telecommunity.com  Sun Jul 26 04:03:08 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 25 Jul 2009 22:03:08 -0400
Subject: [Distutils] Data files with setuptools
In-Reply-To: <3b37a7af0907251020y5f6aab2t3f1e29f9fbfd9019@mail.gmail.com
 >
References: <3b37a7af0907251020y5f6aab2t3f1e29f9fbfd9019@mail.gmail.com>
Message-ID: <20090726020003.5191F3A40D9@sparrow.telecommunity.com>

At 01:20 PM 7/25/2009 -0400, Adeel Ahmad Khan wrote:
>I am having some trouble including data files in the egg installed by
>setuptools.  I've listed the data files in MANIFEST.in and set
>include_package_data = True.
>
>     % ls
>     LICENSE             README          ez_setup.py     timed.py
>     MANIFEST.in cmdapp.py       setup.py
>
>     % cat setup.py
>     from ez_setup import use_setuptools
>     use_setuptools()
>     from setuptools import setup
>
>     setup(
>       # ...
>       py_modules=['timed', 'cmdapp'],
>       entry_points={'console_scripts': ['timed = timed:main']},
>       include_package_data=True,
>       install_requires=['PyYAML'],
>       zip_safe=False,
>     )
>
>     % cat MANIFEST.in
>     include *.py
>     include README
>     include LICENSE
>
>Why isn't README there?  What do I need to do to include it?

The README is not "package data" because it's not inside a 
package.  You can't install package data in a project that only 
includes modules.  In any case, there's no point in shipping 
documentation inside an egg, because only your project's *code* will 
be able to read it, not humans.  Human-readable documentation only 
belongs in a source distribution.

Note that, in general, you do not need to distribute eggs for your 
project.  The egg format is intended for plugins and other situations 
that require pre-built, ready-to-execute binaries.  pip, buildout, 
and easy_install can all build their own eggs on the target system in 
most cases, so the only benefit to distributing eggs is if you have, 
say, a C extension module and want to provide pre-compiled versions 
for Mac OS and Windows.  (And for Windows, you can build a 
bdist_wininst .exe instead; easy_install at least will still be able 
to use it, and you'll make Paul Moore happy. ;-)  (That's an inside 
joke, don't worry if you don't know who Paul is.))


From iwan at reahl.org  Mon Jul 27 12:09:30 2009
From: iwan at reahl.org (Iwan Vosloo)
Date: Mon, 27 Jul 2009 12:09:30 +0200
Subject: [Distutils] setup.py install: overriding sys.executable for scripts?
Message-ID: <1248689370.6032.110.camel@easymoney>

Hi there,

We are running:

python setup.py install  --single-version-externally-managed

in order to package an egg in a .deb.

However, we run this inside a virtualenv environment, which means that
all scripts generated by setuptools start with:

#!/path/to/python/in/virtualenv

I see that sys.executable is used for generating this line.  Is there
any way to override it, similarly to how you can override the
installation directory with --prefix?

Regards
- Iwan


From pje at telecommunity.com  Mon Jul 27 17:35:42 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 27 Jul 2009 11:35:42 -0400
Subject: [Distutils] setup.py install: overriding sys.executable for
 scripts?
In-Reply-To: <1248689370.6032.110.camel@easymoney>
References: <1248689370.6032.110.camel@easymoney>
Message-ID: <20090727153237.3AC943A4099@sparrow.telecommunity.com>

At 12:09 PM 7/27/2009 +0200, Iwan Vosloo wrote:
>Hi there,
>
>We are running:
>
>python setup.py install  --single-version-externally-managed
>
>in order to package an egg in a .deb.
>
>However, we run this inside a virtualenv environment, which means that
>all scripts generated by setuptools start with:
>
>#!/path/to/python/in/virtualenv
>
>I see that sys.executable is used for generating this line.  Is there
>any way to override it, similarly to how you can override the
>installation directory with --prefix?

Not at the moment.  Feel free to add a feature request to the 
tracker, perhaps with a patch.  This also seems like something the 
distutils could potentially use as well.


From adeel2 at umbc.edu  Mon Jul 27 18:29:59 2009
From: adeel2 at umbc.edu (Adeel Ahmad Khan)
Date: Mon, 27 Jul 2009 12:29:59 -0400
Subject: [Distutils] Data files with setuptools
In-Reply-To: <20090726020003.5191F3A40D9@sparrow.telecommunity.com>
References: <3b37a7af0907251020y5f6aab2t3f1e29f9fbfd9019@mail.gmail.com>
	<20090726020003.5191F3A40D9@sparrow.telecommunity.com>
Message-ID: <3b37a7af0907270929r2358ff3frdaed6e98abfaf79d@mail.gmail.com>

> The README is not "package data" because it's not inside a package. ?You
> can't install package data in a project that only includes modules. ?In any
> case, there's no point in shipping documentation inside an egg, because only
> your project's *code* will be able to read it, not humans. ?Human-readable
> documentation only belongs in a source distribution.

I'm writing a command-line program and I was using the README to print
help.  Should I just copy the README into my module then or is there a
better way?

> Note that, in general, you do not need to distribute eggs for your project.
> ?The egg format is intended for plugins and other situations that require
> pre-built, ready-to-execute binaries.

I'm not distributing eggs myself but they're generated by distutils /
setuptools when I do python setup.py install or easy_install.  I'm new
to packaging and pretty confused so I'm possibly doing it wrong.
Here's my project on github, if you'd be willing to take a look:
<http://github.com/adeel/timed/tree/master>.

Thanks.

From robert.kern at gmail.com  Mon Jul 27 18:36:39 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 27 Jul 2009 11:36:39 -0500
Subject: [Distutils] Data files with setuptools
In-Reply-To: <3b37a7af0907270929r2358ff3frdaed6e98abfaf79d@mail.gmail.com>
References: <3b37a7af0907251020y5f6aab2t3f1e29f9fbfd9019@mail.gmail.com>	<20090726020003.5191F3A40D9@sparrow.telecommunity.com>
	<3b37a7af0907270929r2358ff3frdaed6e98abfaf79d@mail.gmail.com>
Message-ID: <h4kl2p$t4o$1@ger.gmane.org>

On 2009-07-27 11:29, Adeel Ahmad Khan wrote:
>> The README is not "package data" because it's not inside a package.  You
>> can't install package data in a project that only includes modules.  In any
>> case, there's no point in shipping documentation inside an egg, because only
>> your project's *code* will be able to read it, not humans.  Human-readable
>> documentation only belongs in a source distribution.
>
> I'm writing a command-line program and I was using the README to print
> help.  Should I just copy the README into my module then or is there a
> better way?

Most likely, the README and the help text should be different. READMEs need 
information like how to install the program. Help text does not.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From pje at telecommunity.com  Mon Jul 27 20:17:12 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 27 Jul 2009 14:17:12 -0400
Subject: [Distutils] Data files with setuptools
In-Reply-To: <h4kl2p$t4o$1@ger.gmane.org>
References: <3b37a7af0907251020y5f6aab2t3f1e29f9fbfd9019@mail.gmail.com>
	<20090726020003.5191F3A40D9@sparrow.telecommunity.com>
	<3b37a7af0907270929r2358ff3frdaed6e98abfaf79d@mail.gmail.com>
	<h4kl2p$t4o$1@ger.gmane.org>
Message-ID: <20090727181404.E85043A4099@sparrow.telecommunity.com>

At 11:36 AM 7/27/2009 -0500, Robert Kern wrote:
>On 2009-07-27 11:29, Adeel Ahmad Khan wrote:
>>>The README is not "package data" because it's not inside a package.  You
>>>can't install package data in a project that only includes modules.  In any
>>>case, there's no point in shipping documentation inside an egg, because only
>>>your project's *code* will be able to read it, not humans.  Human-readable
>>>documentation only belongs in a source distribution.
>>
>>I'm writing a command-line program and I was using the README to print
>>help.  Should I just copy the README into my module then or is there a
>>better way?
>
>Most likely, the README and the help text should be different. 
>READMEs need information like how to install the program. Help text does not.

However, if you do need some sort of data files included with your 
code, it's simplest to use a package, i.e. a subdirectory with an 
__init__.py.  If you use 'include_package_data=True' with setuptools 
(and the data files are under revision control), they will be 
included at install time, and accessible using 
pkg_resources.resource_string() etc.

Alternately, you can use the package_data option to specify data 
files to be included from your package directories; this works 
without setuptools (on Python 2.4 and up) and does not require 
revision control.


From mhearne808 at gmail.com  Mon Jul 27 21:13:23 2009
From: mhearne808 at gmail.com (mhearne808)
Date: Mon, 27 Jul 2009 12:13:23 -0700 (PDT)
Subject: [Distutils] Using an egg like a Java jar file
Message-ID: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>

In Java, it is possible to create a .jar file with a main() method
embedded somewhere in one of the .class files.  It is then possible to
run the main() method from the command line something like this:

java -jar foo.jar

I believe this will work with only one main() defined - if there are
multiple ones, then you have to specify the path (internal to the jar
file).

I gather from previous googling that there isn't a python command line
option equivalent to -jar for eggs (although that might be kind of
handy)

but that you can add an egg to your path without installing it by
doing something like the following (in a bash shell):
export PYTHONPATH=foo.egg

This will then allow you to run a python script at the command line
without having to actually install the egg to the normal "site-
packages" directory.

My questions:
 - Is it possible to embed a script with a "main" entry point in an
egg, and run that from the command line?
 - If so, how do you pass command line arguments to that main?
 - Is this a massive abuse of the intended usage of setuptools?

Thanks,

Mike

From setuptools at bugs.python.org  Mon Jul 27 23:13:16 2009
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 27 Jul 2009 21:13:16 +0000
Subject: [Distutils] [issue83] I wish setuptools would prefer v1.4.1 in
	binary egg format	over v1.4.5 in sdist format when I'm
	requiring >= v1.1.0
In-Reply-To: <1248729196.35.0.867328539808.issue83@psf.upfronthosting.co.za>
Message-ID: <1248729196.35.0.867328539808.issue83@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

It is often the case that a binary .egg is usable and an sdist is not (when the
package requires compiling C or C++ code).  Here is an example where this is
currently happening:

http://allmydata.org/trac/tahoe/ticket/773#comment:7

Tahoe-LAFS requires zfec>=1.1.0.  There are two distributions found during build
a binary .egg of zfec v1.4.1 for the current platform and python version and an
sdist of zfec v1.4.5.  Setuptools is choosing the latter, which then fails to
build because the C/C++ compiler isn't set up on the target system.

If setuptools would prefer binaries over sdists when both satisfy the versioning
requirements, then this would be better.

----------
messages: 331
nosy: zooko
priority: wish
status: unread
title: I wish setuptools would prefer v1.4.1 in binary egg format over v1.4.5 in sdist format when I'm requiring >= v1.1.0

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue83>
_______________________________________________

From p.f.moore at gmail.com  Mon Jul 27 23:57:28 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 27 Jul 2009 22:57:28 +0100
Subject: [Distutils] Using an egg like a Java jar file
In-Reply-To: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>
References: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>
Message-ID: <79990c6b0907271457xde6adb0j3ad7d18127d73295@mail.gmail.com>

2009/7/27 mhearne808 <mhearne808 at gmail.com>:
> My questions:
> ?- Is it possible to embed a script with a "main" entry point in an
> egg, and run that from the command line?
> ?- If so, how do you pass command line arguments to that main?
> ?- Is this a massive abuse of the intended usage of setuptools?

In Python 2.6, you can definitely use a zip file like this. See
http://docs.python.org/using/cmdline.html#command-line

    python foo.zip arg1 arg2 ...

foo.zip should contain a __main__.py which is run. sys.argv holds the
arguments as usual.

This is not an abuse, it's a standard feature.

Whether this is possible with eggs is another matter. I don't know the
answer to this, beyond saying that eggs are zip format files, so you
can always do it as above, at a pinch (assuming you can force
setuptools to generate the correct layout).

Paul.

From pje at telecommunity.com  Tue Jul 28 06:19:23 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 00:19:23 -0400
Subject: [Distutils] Using an egg like a Java jar file
In-Reply-To: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegro
	ups.com>
References: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>
Message-ID: <20090728041615.1153C3A4099@sparrow.telecommunity.com>

At 12:13 PM 7/27/2009 -0700, mhearne808 wrote:
>In Java, it is possible to create a .jar file with a main() method
>embedded somewhere in one of the .class files.  It is then possible to
>run the main() method from the command line something like this:
>
>java -jar foo.jar
>
>I believe this will work with only one main() defined - if there are
>multiple ones, then you have to specify the path (internal to the jar
>file).
>
>I gather from previous googling that there isn't a python command line
>option equivalent to -jar for eggs (although that might be kind of
>handy)

As of Python 2.6, you can run "python someziporeggfile" and have it 
work - you just have to include a __main__.py module.


>but that you can add an egg to your path without installing it by
>doing something like the following (in a bash shell):
>export PYTHONPATH=foo.egg
>
>This will then allow you to run a python script at the command line
>without having to actually install the egg to the normal "site-
>packages" directory.
>
>My questions:
>  - Is it possible to embed a script with a "main" entry point in an
>egg, and run that from the command line?

As of Python 2.4, you can use 'python -m modulename' to load the 
named module as the main module.

>  - If so, how do you pass command line arguments to that main?

python -m modulename args...

>  - Is this a massive abuse of the intended usage of setuptools?

Nope.  There is also a way to make an egg an executable in its own 
right; you can declare an entry point 'eggsecutable' in the 
'setuptools.installation' entry point group, and when you bdist_egg 
it, the egg will include a simple #!/bin/sh script header to put the 
egg on sys.path and run the entry point function.  The main downside 
to this is that the egg cannot be renamed or run via a symlink with 
another name; you have to run it as foobar-1.2.3.egg.


From setuptools at bugs.python.org  Tue Jul 28 09:39:09 2009
From: setuptools at bugs.python.org (Iwan Vosloo)
Date: Tue, 28 Jul 2009 07:39:09 +0000
Subject: [Distutils] [issue84] setup.py install: make sys.executable
	overridable
In-Reply-To: <1248766748.69.0.427402499106.issue84@psf.upfronthosting.co.za>
Message-ID: <1248766748.69.0.427402499106.issue84@psf.upfronthosting.co.za>


New submission from Iwan Vosloo <iwan at reahl.org>:

When running setup.py install --single-version-externally-managed in order to
package an egg in, eg, a .deb, the scripts generated from entrypoints contain a
line:
#!/path/to/python

This path is taken from sys.executable.  

However, this command is often run from inside a virtualenv, in which case
sys.executable is not what you want.

It would be nice to either:
1) be able to specify a path for the python executable on the commandline,
similar to the --prefix option
or
2) strip off the contents of the $VIRTUAL_ENV variable out of sys.executable
when running with --single-version-externally-managed

----------
messages: 332
nosy: IwanVosloo
priority: wish
status: unread
title: setup.py install: make sys.executable overridable

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue84>
_______________________________________________

From floris.bruynooghe at gmail.com  Tue Jul 28 09:53:38 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 28 Jul 2009 08:53:38 +0100
Subject: [Distutils] Using an egg like a Java jar file
In-Reply-To: <79990c6b0907271457xde6adb0j3ad7d18127d73295@mail.gmail.com>
References: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>
	<79990c6b0907271457xde6adb0j3ad7d18127d73295@mail.gmail.com>
Message-ID: <20090728075338.GA6334@laurie.devork>

On Mon, Jul 27, 2009 at 10:57:28PM +0100, Paul Moore wrote:
> 2009/7/27 mhearne808 <mhearne808 at gmail.com>:
> > My questions:
> > ?- Is it possible to embed a script with a "main" entry point in an
> > egg, and run that from the command line?
> > ?- If so, how do you pass command line arguments to that main?
> > ?- Is this a massive abuse of the intended usage of setuptools?
> 
> In Python 2.6, you can definitely use a zip file like this. See
> http://docs.python.org/using/cmdline.html#command-line
> 
>     python foo.zip arg1 arg2 ...
> 
> foo.zip should contain a __main__.py which is run. sys.argv holds the
> arguments as usual.

On UNIX systems you can even do something like IIRC:

  $ echo '#!/usr/bin/python' > tmp
  $ cat tmp foo.zip > foo
  $ chmod +x foo
  $ ./foo arg1 arg2 ...


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From jannis at leidel.info  Tue Jul 28 09:56:47 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Tue, 28 Jul 2009 09:56:47 +0200
Subject: [Distutils] Data files with setuptools
In-Reply-To: <20090727181404.E85043A4099@sparrow.telecommunity.com>
References: <3b37a7af0907251020y5f6aab2t3f1e29f9fbfd9019@mail.gmail.com>
	<20090726020003.5191F3A40D9@sparrow.telecommunity.com>
	<3b37a7af0907270929r2358ff3frdaed6e98abfaf79d@mail.gmail.com>
	<h4kl2p$t4o$1@ger.gmane.org>
	<20090727181404.E85043A4099@sparrow.telecommunity.com>
Message-ID: <21403FA8-ED7E-4FCF-8C83-C3E71363A75B@leidel.info>

Am 27.07.2009 um 20:17 schrieb P.J. Eby:
> At 11:36 AM 7/27/2009 -0500, Robert Kern wrote:
>> On 2009-07-27 11:29, Adeel Ahmad Khan wrote:
>>>> The README is not "package data" because it's not inside a  
>>>> package.  You
>>>> can't install package data in a project that only includes  
>>>> modules.  In any
>>>> case, there's no point in shipping documentation inside an egg,  
>>>> because only
>>>> your project's *code* will be able to read it, not humans.  Human- 
>>>> readable
>>>> documentation only belongs in a source distribution.
>>>
>>> I'm writing a command-line program and I was using the README to  
>>> print
>>> help.  Should I just copy the README into my module then or is  
>>> there a
>>> better way?
>>
>> Most likely, the README and the help text should be different.  
>> READMEs need information like how to install the program. Help text  
>> does not.
>
> However, if you do need some sort of data files included with your  
> code, it's simplest to use a package, i.e. a subdirectory with an  
> __init__.py.  If you use 'include_package_data=True' with setuptools  
> (and the data files are under revision control), they will be  
> included at install time, and accessible using  
> pkg_resources.resource_string() etc.

Note, this only works with Subversion out of the box. But there are  
plugins for all major version control systems that enable setuptools  
to include package data under version control, e.g. setuptools-git.

Jannis

From zooko at zooko.com  Tue Jul 28 16:23:38 2009
From: zooko at zooko.com (Zooko Wilcox-O'Hearn)
Date: Tue, 28 Jul 2009 08:23:38 -0600
Subject: [Distutils] idea for Distribute: make unzipped eggs be the default
Message-ID: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>

Folks:

I have been keeping a running tally of people who have trouble with  
zipped eggs and the trouble goes away when they have unzipped eggs  
instead.  I just added the newest entry: someone was trying to build  
a package with py2exe, and configuring their distutils config file to  
always unzip eggs fixed the problem:

http://bugs.python.org/setuptools/issue33 # zipped eggs cause various  
problems -- perhaps set default setting to unzipped?

Perhaps the Distribute project should consider installing eggs  
unzipped by default.  It would avoid a slew of problems (see that  
ticket for a catalog of problems), would be fully backwards  
compatible (it is what many people already do, per the suggested  
workaround, and I've never heard a report of a problem due to an  
*unzipped* egg), and I think it might improve performance a bit.   
(Yes, that's right -- we haven't done a real measurement of  
performance, but the few times that people briefly glanced at  
performance it seemed like zipping the eggs made them slower to load,  
not faster.)

Regards,

Zooko


From hanno at hannosch.eu  Tue Jul 28 16:56:46 2009
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Tue, 28 Jul 2009 16:56:46 +0200
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
	default
In-Reply-To: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
Message-ID: <5cae42b20907280756g6b552424w155f3102fe6d724c@mail.gmail.com>

On Tue, Jul 28, 2009 at 4:23 PM, Zooko Wilcox-O'Hearn<zooko at zooko.com> wrote:
> http://bugs.python.org/setuptools/issue33 # zipped eggs cause various
> problems -- perhaps set default setting to unzipped?

+1

> Perhaps the Distribute project should consider installing eggs unzipped by
> default. ?It would avoid a slew of problems (see that ticket for a catalog
> of problems), would be fully backwards compatible (it is what many people
> already do, per the suggested workaround, and I've never heard a report of a
> problem due to an *unzipped* egg), and I think it might improve performance
> a bit. ?(Yes, that's right -- we haven't done a real measurement of
> performance, but the few times that people briefly glanced at performance it
> seemed like zipping the eggs made them slower to load, not faster.)

The measurements I know of suggest that having lots of zipped eggs for
each package doesn't provide any benefit whatsoever and is usually
worse than normal unzipped eggs.

Only if you combine a whole lot of packages and code into one giant
manually crafted egg, you sometimes get benefits from it. But that's a
specific deployment optimization that should be left to specific
situations.

Hanno

From regebro at gmail.com  Tue Jul 28 17:19:19 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 28 Jul 2009 17:19:19 +0200
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
	default
In-Reply-To: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
Message-ID: <319e029f0907280819l6e7a8ba1j68bb019929df40c1@mail.gmail.com>

2009/7/28 Zooko Wilcox-O'Hearn <zooko at zooko.com>:
> Perhaps the Distribute project should consider installing eggs unzipped by
> default.

+1. Zipped packages are apparently only useful on specialized systems
where the filesystem has limitations, maybe it's slow or can't handle
many files, like embedded systems or similar.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pje at telecommunity.com  Tue Jul 28 19:15:17 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 13:15:17 -0400
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
 default
In-Reply-To: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
Message-ID: <20090728171210.136823A4099@sparrow.telecommunity.com>

At 08:23 AM 7/28/2009 -0600, Zooko Wilcox-O'Hearn wrote:
>I think it might improve performance a bit.
>(Yes, that's right -- we haven't done a real measurement of
>performance, but the few times that people briefly glanced at
>performance it seemed like zipping the eggs made them slower to load,
>not faster.)

You're trading startup time for import time, actually.  Unzipped eggs 
force OS level stat calls during importing of every module, whereas 
zipped eggs force directory reads at startup.

In both cases, the time cost mostly occurs at startup; the difference 
is in whether you have more imports or more eggs.  Each zipped egg 
adds a one-time performance hit; each unzipped egg adds a smaller -- 
but *N-times* as often -- performance hit.

So the optimum performance tradeoff depends on how many imports you 
have *and* how many eggs you have on sys.path.  If you have lots of 
eggs and few imports, unzipped ones will probably be faster.  If you 
have lots of eggs and *lots* of imports, zipped ones will probably be faster.

To really know what the tradeoff is, some actual measurements are 
needed.  (And they need to measure both startup overhead and import overhead.)


From jim at zope.com  Tue Jul 28 19:38:01 2009
From: jim at zope.com (Jim Fulton)
Date: Tue, 28 Jul 2009 13:38:01 -0400
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
	default
In-Reply-To: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
Message-ID: <1099b90b0907281038g1aeb2da3mf9d4059388ad816c@mail.gmail.com>

On Tue, Jul 28, 2009 at 10:23 AM, Zooko Wilcox-O'Hearn<zooko at zooko.com> wrote:
> Folks:
>
> I have been keeping a running tally of people who have trouble with zipped
> eggs and the trouble goes away when they have unzipped eggs instead. ?I just
> added the newest entry: someone was trying to build a package with py2exe,
> and configuring their distutils config file to always unzip eggs fixed the
> problem:
>
> http://bugs.python.org/setuptools/issue33 # zipped eggs cause various
> problems -- perhaps set default setting to unzipped?
>
> Perhaps the Distribute project should consider installing eggs unzipped by
> default. ?It would avoid a slew of problems (see that ticket for a catalog
> of problems), would be fully backwards compatible (it is what many people
> already do, per the suggested workaround, and I've never heard a report of a
> problem due to an *unzipped* egg), and I think it might improve performance
> a bit. ?(Yes, that's right -- we haven't done a real measurement of
> performance, but the few times that people briefly glanced at performance it
> seemed like zipping the eggs made them slower to load, not faster.)

+1

Jim

-- 
Jim Fulton

From jrh at joshh.co.uk  Tue Jul 28 20:30:10 2009
From: jrh at joshh.co.uk (Josh Holland)
Date: Tue, 28 Jul 2009 19:30:10 +0100
Subject: [Distutils] Problems with setup.py
Message-ID: <20090728183010.GC3229@joshh.co.uk>

I am currently having difficulty with a setup.py script. The problem was
originally brought to my attention by someone packaging the project for
Fedora 11, but I can reproduce a similar problem on my Jaunty box.

When "python setup.py build" is run, the following output is produced
(running with -n switch):
running install
running build
running build_py
running build_ext
running build_scripts
changing mode of build/scripts-2.6/suvat
running install_lib
running install_scripts
changing mode of /usr/local/bin/suvat
running install_data
error: can't copy 'd': doesn't exist or not a regular file

This is for me; the Fedora issue is with 's' instead of 'd'. This is
with different versions of setup.py. My development version is attached,
and the Fedora one is available in the tarball at
http://joshh.co.uk/stuff/suvat-0.1.1.tar.gz.

-- 
Josh Holland <jrh at joshh.co.uk> (key F6067C12)
http://joshh.co.uk dutchie on irc.freenode.net
http://twitter.com/jshholland http://identi.ca/jshholland
'< KnMn> I am sick of people saying "loling"; surely it should be "lingol"'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python
Size: 1084 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090728/22649b16/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090728/22649b16/attachment.pgp>

From pje at telecommunity.com  Tue Jul 28 20:48:43 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 14:48:43 -0400
Subject: [Distutils] Problems with setup.py
In-Reply-To: <20090728183010.GC3229@joshh.co.uk>
References: <20090728183010.GC3229@joshh.co.uk>
Message-ID: <20090728184535.88B723A4099@sparrow.telecommunity.com>

At 07:30 PM 7/28/2009 +0100, Josh Holland wrote:
>I am currently having difficulty with a setup.py script. The problem was
>originally brought to my attention by someone packaging the project for
>Fedora 11, but I can reproduce a similar problem on my Jaunty box.
>
>When "python setup.py build" is run, the following output is produced
>(running with -n switch):
>running install
>running build
>running build_py
>running build_ext
>running build_scripts
>changing mode of build/scripts-2.6/suvat
>running install_lib
>running install_scripts
>changing mode of /usr/local/bin/suvat
>running install_data
>error: can't copy 'd': doesn't exist or not a regular file
>
>This is for me; the Fedora issue is with 's' instead of 'd'. This is
>with different versions of setup.py.

This line is wrong:

    data_files = [('/usr/share/man/man1', 'doc/suvat.1.gz')],

See 
http://www.python.org/doc/2.3.5/dist/setup-script.html#SECTION000350000000000000000 
for why/how.


From matt at tplus1.com  Tue Jul 28 21:04:34 2009
From: matt at tplus1.com (Matthew Wilson)
Date: Tue, 28 Jul 2009 15:04:34 -0400
Subject: [Distutils] setuptools: can I specify different install_requires
	for different python versions?
Message-ID: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com>

I have a package that depends on the multiprocessing package, which
got added to the standard library as of 2.6.

So, for only those people using python versions before 2.6, I want to
require they install multiprocessing.

Is this possible?

-- 
Matthew Wilson
matt at tplus1.com
http://tplus1.com

From pje at telecommunity.com  Tue Jul 28 21:26:52 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 15:26:52 -0400
Subject: [Distutils] setuptools: can I specify different
 install_requires for different python versions?
In-Reply-To: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.co
 m>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com>
Message-ID: <20090728192344.8904A3A4099@sparrow.telecommunity.com>

At 03:04 PM 7/28/2009 -0400, Matthew Wilson wrote:
>I have a package that depends on the multiprocessing package, which
>got added to the standard library as of 2.6.
>
>So, for only those people using python versions before 2.6, I want to
>require they install multiprocessing.
>
>Is this possible?

Yes.  Write your setup.py to check the Python version, and build up 
the requirements in a variable before calling setup().


From matt at tplus1.com  Tue Jul 28 21:36:01 2009
From: matt at tplus1.com (Matthew Wilson)
Date: Tue, 28 Jul 2009 15:36:01 -0400
Subject: [Distutils] setuptools: can I specify different
	install_requires for different python versions?
In-Reply-To: <20090728192344.8904A3A4099@sparrow.telecommunity.com>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com>
	<20090728192344.8904A3A4099@sparrow.telecommunity.com>
Message-ID: <f6f643a20907281236x1059caf6t8a6350d391d28dad@mail.gmail.com>

On Tue, Jul 28, 2009 at 3:26 PM, P.J. Eby<pje at telecommunity.com> wrote:

> Yes. ?Write your setup.py to check the Python version, and build up the
> requirements in a variable before calling setup().

Right -- it's a program, not a config file.  Now I see why that is so
useful.  Thanks!

Matt

-- 
Matthew Wilson
matt at tplus1.com
http://tplus1.com

From SridharR at activestate.com  Tue Jul 28 21:38:37 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 28 Jul 2009 12:38:37 -0700
Subject: [Distutils] setuptools: can I specify different
 install_requires for different python versions?
In-Reply-To: <20090728192344.8904A3A4099@sparrow.telecommunity.com>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com>
	<20090728192344.8904A3A4099@sparrow.telecommunity.com>
Message-ID: <op.uxsl6nnvbrrvlq@double>

On Tue, 28 Jul 2009 12:26:52 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> At 03:04 PM 7/28/2009 -0400, Matthew Wilson wrote:
> I have a package that depends on the multiprocessing package, which
> got added to the standard library as of 2.6.
>  So, for only those people using python versions before 2.6, I want to
> require they install multiprocessing.
>  Is this possible?
>  Yes.  Write your setup.py to check the Python version, and build up the  
> requirements in a variable before calling setup().

I'm -1 on this solution. I'd rather have multiprocessing installed as  
requirement - till [1] (or something equivalent) is implemented - and then  
simply do a "import multiprocessing" which would pick up the stdlib  
multiprocessing (if >2.6) or pickup the installed one. I noticed some  
packages doing this already.

To explain - if developers begin to specify metadata in a conditional way  
in their setup.py, then there is no point in keeping metadata (PKG-INFO,  
requires.txt) within the sdist. Besides - it encourages tools (eg:  
pkginfo/pypm) to parse those files in order to determine the package  
metadata.

This is just another reason why I favor a standardized metadata (with  
install_requires support) and a static setup.py metadata.

[1] One way to implement conditional requirements is to make use of  
Requirement.extras. If setuptools/distribute supports builtin extras -  
such as Py26, Py27, Py30 and so forth .. even Py3x to cover all 3.x  
versions - then one can have a [<Py26] section in their install_requires  
that would specify requirements specific to versions below 2.6.

-srid

PS: PyPM relies on these metadata files that are *already* part of the  
sdist. This email is another reason to find ways to generate PKG-INFO  
using setuptools' egg_info command .. which, however, means one has to run  
setup.py with all its silly hacks (raw_input() anyone?).

From pje at telecommunity.com  Tue Jul 28 22:00:44 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 16:00:44 -0400
Subject: [Distutils] setuptools: can I specify different
 install_requires for different python versions?
In-Reply-To: <op.uxsl6nnvbrrvlq@double>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com>
	<20090728192344.8904A3A4099@sparrow.telecommunity.com>
	<op.uxsl6nnvbrrvlq@double>
Message-ID: <20090728195736.264103A4099@sparrow.telecommunity.com>

At 12:38 PM 7/28/2009 -0700, Sridhar Ratnakumar wrote:
>On Tue, 28 Jul 2009 12:26:52 -0700, P.J. Eby <pje at telecommunity.com> wrote:
>
>>At 03:04 PM 7/28/2009 -0400, Matthew Wilson wrote:
>>I have a package that depends on the multiprocessing package, which
>>got added to the standard library as of 2.6.
>>  So, for only those people using python versions before 2.6, I want to
>>require they install multiprocessing.
>>  Is this possible?
>>  Yes.  Write your setup.py to check the Python version, and build up the
>>requirements in a variable before calling setup().
>
>I'm -1 on this solution.

Please note that *future* fixes won't help the person who asked what 
to do right now.


>[1] One way to implement conditional requirements is to make use of
>Requirement.extras. If setuptools/distribute supports builtin extras -
>such as Py26, Py27, Py30 and so forth .. even Py3x to cover all 3.x
>versions - then one can have a [<Py26] section in their install_requires
>that would specify requirements specific to versions below 2.6.

It would also need to support platform-specific requirements, and 
possibly other options as well.


>which, however, means one has to run
>setup.py with all its silly hacks (raw_input() anyone?).

Ew.  Somebody actually did that?  Please identify the culprit so they 
can be publicly shamed.


From pavpanchekha at gmail.com  Tue Jul 28 22:41:22 2009
From: pavpanchekha at gmail.com (Pavel Panchekha)
Date: Tue, 28 Jul 2009 16:41:22 -0400
Subject: [Distutils] data-files in folder
Message-ID: <51b824cd0907281341k422bdf6m910a4e80577ebb7e@mail.gmail.com>

I have a folder tree of data files. I can't seem to get distutils to
recognize "data/*" as data_files (even though it works for package_data). Is
there any nice way of specifying that I have a folder of data files?

- Pavel Panchekha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090728/7f12ccf3/attachment.htm>

From mhearne808 at gmail.com  Tue Jul 28 23:20:26 2009
From: mhearne808 at gmail.com (mhearne808)
Date: Tue, 28 Jul 2009 14:20:26 -0700 (PDT)
Subject: [Distutils] Using an egg like a Java jar file
In-Reply-To: <20090728041615.1153C3A4099@sparrow.telecommunity.com>
References: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>
	<20090728041615.1153C3A4099@sparrow.telecommunity.com>
Message-ID: <eec6e03c-038a-49fb-bbea-f2f8b15c8ec6@g6g2000vbr.googlegroups.com>

All:  Thanks for your suggestions.  Unfortunately, I can't use the
Python 2.6 functionality because I'll be running this on systems where
2.6 is not installed (Red Hat Enterprise).

I'm trying the 'eggsecutable' suggestion, but I can't figure out how
to pass command line arguments to my main() entry point.  I created
two python files, testme.py and setup.py, included below.  I've
determined through experimentation that my entry point is directly
into my main() function.  The code at the end ("if __name__" etc.) is
not being called at all.  When I build this with "python setup.py
bdist_egg", and then run it "sh testme-1.0.0-py2.5.egg 1 2", I get:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: main() takes exactly 1 argument (0 given)

How can I pass arguments from the command line in to my main()
function?

Thanks,

Mike


testme.py:
#!/usr/bin/env python
import sys

def main(input):
    print 'Command line arguments are ' % input

if __name__ == '__main__':
    main(sys.argv)

setup.py:
from setuptools import setup, find_packages

setup(name='testme',
      version='1.0.0',
      py_modules=['testme'],
      description = 'foo',
      author = 'Somebody',
      author_email = 'somebody at foo.com',
      url = 'www.foo.com',
      entry_points = {
        'setuptools.installation': ['eggsecutable = testme:main',]}
      )

On Jul 27, 10:19?pm, "P.J. Eby" <p... at telecommunity.com> wrote:
> At 12:13 PM 7/27/2009 -0700, mhearne808 wrote:
>
> >In Java, it is possible to create a .jar file with a main() method
> >embedded somewhere in one of the .class files. ?It is then possible to
> >run the main() method from the command line something like this:
>
> >java -jar foo.jar
>
> >I believe this will work with only one main() defined - if there are
> >multiple ones, then you have to specify the path (internal to the jar
> >file).
>
> >I gather from previous googling that there isn't a python command line
> >option equivalent to -jar for eggs (although that might be kind of
> >handy)
>
> As of Python 2.6, you can run "python someziporeggfile" and have it
> work - you just have to include a __main__.py module.
>
> >but that you can add an egg to your path without installing it by
> >doing something like the following (in a bash shell):
> >export PYTHONPATH=foo.egg
>
> >This will then allow you to run a python script at the command line
> >without having to actually install the egg to the normal "site-
> >packages" directory.
>
> >My questions:
> > ?- Is it possible to embed a script with a "main" entry point in an
> >egg, and run that from the command line?
>
> As of Python 2.4, you can use 'python -m modulename' to load the
> named module as the main module.
>
> > ?- If so, how do you pass command line arguments to that main?
>
> python -m modulename args...
>
> > ?- Is this a massive abuse of the intended usage of setuptools?
>
> Nope. ?There is also a way to make an egg an executable in its own
> right; you can declare an entry point 'eggsecutable' in the
> 'setuptools.installation' entry point group, and when you bdist_egg
> it, the egg will include a simple #!/bin/sh script header to put the
> egg on sys.path and run the entry point function. ?The main downside
> to this is that the egg cannot be renamed or run via a symlink with
> another name; you have to run it as foobar-1.2.3.egg.
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-... at python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

From mhearne808 at gmail.com  Tue Jul 28 23:43:03 2009
From: mhearne808 at gmail.com (mhearne808)
Date: Tue, 28 Jul 2009 14:43:03 -0700 (PDT)
Subject: [Distutils] Using an egg like a Java jar file - Part 2
Message-ID: <e1fa16f7-4056-475d-a134-80aed7609226@v2g2000vbb.googlegroups.com>

I apologize for posting out of my thread, but I tried to "reply" twice
to my original thread, and my message didn't seem to appear anywhere.
Maybe it's just delayed...  Anyway, here goes:

All: This may be a duplicate post - I can't see the post I just
submitted, so I'm trying again.

Thanks for the suggestions.  I can't use 2.6 because it isn't
installed on the systems where my script will be running.

I'm attempting to use the 'eggsecutable' suggestion.  How do I get
command line parameters passed into my entry point main() function?

Code is appended below.
setup.py:
from setuptools import setup, find_packages

setup(name='testme',
      version='1.0.0',
      py_modules=['testme'],
      description = 'foo',
      author = 'Somebody',
      author_email = 'somebody at foo.com',
      url = 'www.foo.com',
      entry_points = {
        'setuptools.installation': ['eggsecutable = testme:main',]}
      )

testme.py:
#!/usr/bin/env python
import sys

def main(input):
    print 'Command line arguments are ' % input

if __name__ == '__main__':
    main(sys.argv)

From mhearne808 at gmail.com  Tue Jul 28 23:36:00 2009
From: mhearne808 at gmail.com (mhearne808)
Date: Tue, 28 Jul 2009 14:36:00 -0700 (PDT)
Subject: [Distutils] Using an egg like a Java jar file
In-Reply-To: <20090728075338.GA6334@laurie.devork>
References: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>
	<79990c6b0907271457xde6adb0j3ad7d18127d73295@mail.gmail.com> 
	<20090728075338.GA6334@laurie.devork>
Message-ID: <c395c03c-888f-40fb-8a19-f1b51a3fc150@f33g2000vbm.googlegroups.com>

All: This may be a duplicate post - I can't see the post I just
submitted, so I'm trying again.

Thanks for the suggestions.  I can't use 2.6 because it isn't
installed on the systems where my script will be running.

I'm attempting to use the 'eggsecutable' suggestion.  How do I get
command line parameters passed into my entry point main() function?

Code is appended below.
setup.py:
from setuptools import setup, find_packages

setup(name='testme',
      version='1.0.0',
      py_modules=['testme'],
      description = 'foo',
      author = 'Somebody',
      author_email = 'somebody at foo.com',
      url = 'www.foo.com',
      entry_points = {
        'setuptools.installation': ['eggsecutable = testme:main',]}
      )

testme.py:
#!/usr/bin/env python
import sys

def main(input):
    print 'Command line arguments are ' % input

if __name__ == '__main__':
    main(sys.argv)

On Jul 28, 1:53?am, Floris Bruynooghe <floris.bruynoo... at gmail.com>
wrote:
> On Mon, Jul 27, 2009 at 10:57:28PM +0100, Paul Moore wrote:
> > 2009/7/27 mhearne808 <mhearne... at gmail.com>:
> > > My questions:
> > > ?- Is it possible to embed a script with a "main" entry point in an
> > > egg, and run that from the command line?
> > > ?- If so, how do you pass command line arguments to that main?
> > > ?- Is this a massive abuse of the intended usage of setuptools?
>
> > In Python 2.6, you can definitely use a zip file like this. See
> >http://docs.python.org/using/cmdline.html#command-line
>
> > ? ? python foo.zip arg1 arg2 ...
>
> > foo.zip should contain a __main__.py which is run. sys.argv holds the
> > arguments as usual.
>
> On UNIX systems you can even do something like IIRC:
>
> ? $ echo '#!/usr/bin/python' > tmp
> ? $ cat tmp foo.zip > foo
> ? $ chmod +x foo
> ? $ ./foo arg1 arg2 ...
>
> Regards
> Floris
>
> --
> Debian GNU/Linux -- The Power of Freedomwww.debian.org|www.gnu.org|www.kernel.org
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-... at python.orghttp://mail.python.org/mailman/listinfo/distutils-sig

From SridharR at activestate.com  Wed Jul 29 00:31:48 2009
From: SridharR at activestate.com (Sridhar Ratnakumar)
Date: Tue, 28 Jul 2009 15:31:48 -0700
Subject: [Distutils] setuptools: can I specify different
 install_requires for different python versions?
In-Reply-To: <20090728195736.264103A4099@sparrow.telecommunity.com>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com>
	<20090728192344.8904A3A4099@sparrow.telecommunity.com>
	<op.uxsl6nnvbrrvlq@double>
	<20090728195736.264103A4099@sparrow.telecommunity.com>
Message-ID: <op.uxst7aknbrrvlq@double>

On Tue, 28 Jul 2009 13:00:44 -0700, P.J. Eby <pje at telecommunity.com> wrote:

> [1] One way to implement conditional requirements is to make use of
> Requirement.extras. If setuptools/distribute supports builtin extras -
> such as Py26, Py27, Py30 and so forth .. even Py3x to cover all 3.x
> versions - then one can have a [<Py26] section in their install_requires
> that would specify requirements specific to versions below 2.6.
>  It would also need to support platform-specific requirements, and  
> possibly other options as well.

Yes. Perhaps this can be made extensible/special by requiring that such  
'special' sections start with a ':'. Example:

[:pyver<(2,6)]
multiprocessing<=2.2

[:platinfo.osname=windows]
wincurses

[:platinfo.osname=windows and platinfo.osarch=x64]
ssl64

where 'platinfo' is from http://code.google.com/p/platinfo/ (reason being:  
platform names has to be from a *standard* set of names .. lest people use  
whatever-comes-to-their-mind making it harder for some of us to,  
programmatically, read and understand their metadata).

>   which, however, means one has to run
> setup.py with all its silly hacks (raw_input() anyone?).
>  Ew.  Somebody actually did that?  Please identify the culprit so they  
> can be publicly shamed.

There are a handful .. and http://pypi.python.org/pypi/biopython is one of  
them.

-srid

From pje at telecommunity.com  Wed Jul 29 01:45:09 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 19:45:09 -0400
Subject: [Distutils] data-files in folder
In-Reply-To: <51b824cd0907281341k422bdf6m910a4e80577ebb7e@mail.gmail.com
 >
References: <51b824cd0907281341k422bdf6m910a4e80577ebb7e@mail.gmail.com>
Message-ID: <20090728234201.DA32E3A4099@sparrow.telecommunity.com>

At 04:41 PM 7/28/2009 -0400, Pavel Panchekha wrote:
>I have a folder tree of data files. I can't seem to get distutils to 
>recognize "data/*" as data_files (even though it works for 
>package_data). Is there any nice way of specifying that I have a 
>folder of data files?

glob.glob("folder/*").replace(os.sep, '/') or something like it might 
work.  See the glob module docs.


From pje at telecommunity.com  Wed Jul 29 01:47:11 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 19:47:11 -0400
Subject: [Distutils] Using an egg like a Java jar file
In-Reply-To: <c395c03c-888f-40fb-8a19-f1b51a3fc150@f33g2000vbm.googlegro
	ups.com>
References: <271a64c7-db15-4fb6-8afc-d5792cec3b13@s15g2000yqs.googlegroups.com>
	<79990c6b0907271457xde6adb0j3ad7d18127d73295@mail.gmail.com>
	<20090728075338.GA6334@laurie.devork>
	<c395c03c-888f-40fb-8a19-f1b51a3fc150@f33g2000vbm.googlegroups.com>
Message-ID: <20090728234403.5FE0E3A4099@sparrow.telecommunity.com>

At 02:36 PM 7/28/2009 -0700, mhearne808 wrote:
>All: This may be a duplicate post - I can't see the post I just
>submitted, so I'm trying again.
>
>Thanks for the suggestions.  I can't use 2.6 because it isn't
>installed on the systems where my script will be running.
>
>I'm attempting to use the 'eggsecutable' suggestion.  How do I get
>command line parameters passed into my entry point main() function?

Use sys.argv; the eggsecutable entry point function is not passed any 
arguments.


From david.lyon at preisshare.net  Wed Jul 29 02:38:08 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 28 Jul 2009 20:38:08 -0400
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
	default
In-Reply-To: <1099b90b0907281038g1aeb2da3mf9d4059388ad816c@mail.gmail.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<1099b90b0907281038g1aeb2da3mf9d4059388ad816c@mail.gmail.com>
Message-ID: <73626eec1144ff7907636d73538896db@preisshare.net>

>> I think it might improve
>> performance
>> a bit. ?(Yes, that's right -- we haven't done a real measurement of
>> performance, but the few times that people briefly glanced at
performance
>> it
>> seemed like zipping the eggs made them slower to load, not faster.)

It's totally true. unzipped is faster because decompression adds 
another processing layer which consumes more time than doing the
dma transfer of the extra bytes.

For those still using Z-80s or other 8-bit processors along with
C or assembler this isn't the case, but it will be true for any 32-
bit and above architecture running an elephant interpretor like
python.

+1 from me

David 

From greg.ewing at canterbury.ac.nz  Wed Jul 29 03:02:12 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 29 Jul 2009 13:02:12 +1200
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
	default)
In-Reply-To: <20090728171210.136823A4099@sparrow.telecommunity.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
Message-ID: <4A6F9F94.9000507@canterbury.ac.nz>

P.J. Eby wrote:

> So the optimum performance tradeoff depends on how many imports you have 
> *and* how many eggs you have on sys.path.  If you have lots of eggs and 
> few imports, unzipped ones will probably be faster.  If you have lots of 
> eggs and *lots* of imports, zipped ones will probably be faster.

I'm wondering whether something could be gained by
cacheing the results of sys.path lookups somehow
between interpreter invocations.

Most of the time the contents of the directories
on one's PYTHONPATH don't change, so doing all this
statting and directory reading every time an
interpreter starts up seems rather suboptimal.

-- 
Greg

From santagada at gmail.com  Wed Jul 29 03:41:47 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Tue, 28 Jul 2009 22:41:47 -0300
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
	default
In-Reply-To: <73626eec1144ff7907636d73538896db@preisshare.net>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<1099b90b0907281038g1aeb2da3mf9d4059388ad816c@mail.gmail.com>
	<73626eec1144ff7907636d73538896db@preisshare.net>
Message-ID: <A71FE44A-AD37-4621-8D64-54D80110F32A@gmail.com>


On Jul 28, 2009, at 9:38 PM, David Lyon wrote:

>>> I think it might improve
>>> performance
>>> a bit.  (Yes, that's right -- we haven't done a real measurement of
>>> performance, but the few times that people briefly glanced at
> performance
>>> it
>>> seemed like zipping the eggs made them slower to load, not faster.)
>
> It's totally true. unzipped is faster because decompression adds
> another processing layer which consumes more time than doing the
> dma transfer of the extra bytes.
>
> For those still using Z-80s or other 8-bit processors along with
> C or assembler this isn't the case, but it will be true for any 32-
> bit and above architecture running an elephant interpretor like
> python.


I think P.J. Eby is right, we need to test it before analising the  
results we don't have. Anyway even with a minor decrease in  
performance using unzipped eggs makes things easier.

--
Leonardo Santagada
santagada at gmail.com




From santagada at gmail.com  Wed Jul 29 03:46:20 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Tue, 28 Jul 2009 22:46:20 -0300
Subject: [Distutils] [issue83] I wish setuptools would prefer v1.4.1 in
	binary egg format	over v1.4.5 in sdist format when I'm
	requiring >= v1.1.0
In-Reply-To: <1248729196.35.0.867328539808.issue83@psf.upfronthosting.co.za>
References: <1248729196.35.0.867328539808.issue83@psf.upfronthosting.co.za>
Message-ID: <0C930279-AE27-419A-B932-712B4BC18253@gmail.com>


On Jul 27, 2009, at 6:13 PM, Zooko O'Whielacronx wrote:

>
> New submission from Zooko O'Whielacronx <zooko at zooko.com>:
>
> It is often the case that a binary .egg is usable and an sdist is  
> not (when the
> package requires compiling C or C++ code).  Here is an example where  
> this is
> currently happening:
>
> http://allmydata.org/trac/tahoe/ticket/773#comment:7
>
> Tahoe-LAFS requires zfec>=1.1.0.  There are two distributions found  
> during build
> a binary .egg of zfec v1.4.1 for the current platform and python  
> version and an
> sdist of zfec v1.4.5.  Setuptools is choosing the latter, which then  
> fails to
> build because the C/C++ compiler isn't set up on the target system.
>
> If setuptools would prefer binaries over sdists when both satisfy  
> the versioning
> requirements, then this would be better.

Why not try to compile a package and if it fails (because disutils  
can't find a compiler) it just try to find a pre-compiled egg? This  
would made everyone happy I think?

--
Leonardo Santagada
santagada at gmail.com




From pje at telecommunity.com  Wed Jul 29 04:21:47 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 22:21:47 -0400
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
 default)
In-Reply-To: <4A6F9F94.9000507@canterbury.ac.nz>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
Message-ID: <20090729021839.D97983A4099@sparrow.telecommunity.com>

At 01:02 PM 7/29/2009 +1200, Greg Ewing wrote:
>P.J. Eby wrote:
>
>>So the optimum performance tradeoff depends on how many imports you 
>>have *and* how many eggs you have on sys.path.  If you have lots of 
>>eggs and few imports, unzipped ones will probably be faster.  If 
>>you have lots of eggs and *lots* of imports, zipped ones will 
>>probably be faster.
>
>I'm wondering whether something could be gained by
>cacheing the results of sys.path lookups somehow
>between interpreter invocations.
>
>Most of the time the contents of the directories
>on one's PYTHONPATH don't change, so doing all this
>statting and directory reading every time an
>interpreter starts up seems rather suboptimal.

The catch is that then you need some way to know whether your cache 
information is wrong/out-of-date.  I suppose, though, that you could 
do something like make a file that contains stat times, such that 
modifying the contained directory would automatically invalidate the 
cache info.

However, you'd probably gain more by making the core import logic 
simply use the dircache module (or a C equivalent thereof) in place 
of stat() calls.  This would drop the per-import stat() count for 
each directory to 1 (in place of several for .py, .pyc, .pyd/.so, 
/__init__.py, etc.), at the cost of an initial listdir() call the 
first time a directory is used.  This would give normal imports most 
of the speedup benefit that e.g. putting the stdlib in a zipfile does.


From ianb at colorstudy.com  Wed Jul 29 04:22:02 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 28 Jul 2009 21:22:02 -0500
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
	default)
In-Reply-To: <4A6F9F94.9000507@canterbury.ac.nz>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com> 
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
Message-ID: <b654cd2e0907281922i4666016bs4fc45fa1acc7f4da@mail.gmail.com>

On Tue, Jul 28, 2009 at 8:02 PM, Greg Ewing<greg.ewing at canterbury.ac.nz> wrote:
> P.J. Eby wrote:
>
>> So the optimum performance tradeoff depends on how many imports you have
>> *and* how many eggs you have on sys.path. ?If you have lots of eggs and few
>> imports, unzipped ones will probably be faster. ?If you have lots of eggs
>> and *lots* of imports, zipped ones will probably be faster.
>
> I'm wondering whether something could be gained by
> cacheing the results of sys.path lookups somehow
> between interpreter invocations.
>
> Most of the time the contents of the directories
> on one's PYTHONPATH don't change, so doing all this
> statting and directory reading every time an
> interpreter starts up seems rather suboptimal.

I can see how this could go quite wrong, but maybe if installers touch
some file in the library directory anytime a package is
installed/reinstalled/removed/etc, then it would be fast to check if
the cache was correct.  Though the optimization seems like its working
around something that maybe shouldn't be a problem.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From pje at telecommunity.com  Wed Jul 29 04:40:33 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 28 Jul 2009 22:40:33 -0400
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
 default)
In-Reply-To: <b654cd2e0907281922i4666016bs4fc45fa1acc7f4da@mail.gmail.co
 m>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
	<b654cd2e0907281922i4666016bs4fc45fa1acc7f4da@mail.gmail.com>
Message-ID: <20090729023727.272FB3A4099@sparrow.telecommunity.com>

At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
>I can see how this could go quite wrong, but maybe if installers 
>touch some file in the library directory anytime a package is 
>installed/reinstalled/removed/etc,

You mean, like, the mtime of the directory itself?  ;-)

Really, there's no need for a file.  It seems really, really unlikely 
that there's any common filesystem where reading a file containing 
the (maybe out-of-date) contents of a directory is faster than just 
reading the directory itself.  And, courtesy of the time machine, 
there's even a 'dircache' module already in the stdlib.

i.e. if you use dircache.listdir() in place of regular listdir, 
you'll only have to read the directory once.

(Another way to do this, of course, would be to have importlib 
importer objects use the same logic to keep a cache of their target directory.)


From ianb at colorstudy.com  Wed Jul 29 05:35:17 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 28 Jul 2009 22:35:17 -0500
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
	default)
In-Reply-To: <20090729023727.272FB3A4099@sparrow.telecommunity.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com> 
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz> 
	<b654cd2e0907281922i4666016bs4fc45fa1acc7f4da@mail.gmail.com> 
	<20090729023727.272FB3A4099@sparrow.telecommunity.com>
Message-ID: <b654cd2e0907282035l336975f3udbca15c6233f929a@mail.gmail.com>

On Tue, Jul 28, 2009 at 9:40 PM, P.J. Eby<pje at telecommunity.com> wrote:
> At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
>>
>> I can see how this could go quite wrong, but maybe if installers touch
>> some file in the library directory anytime a package is
>> installed/reinstalled/removed/etc,
>
> You mean, like, the mtime of the directory itself? ?;-)

Do directory mtimes get recursively updated?  I don't think they do.
So if you have a layout:

site-packages/
  zope/
    interface/
      __init__.py

And you update the package and update __init__.py, the mtime of
site-packages doesn't change, does it?

I'm saying if there was a file in site-packages/last_updated that gets
touched everytime an installer does anything in site-packages, then
you could cache (between processes) the lookups.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From pje at telecommunity.com  Wed Jul 29 06:44:23 2009
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 29 Jul 2009 00:44:23 -0400
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
 default)
In-Reply-To: <b654cd2e0907282035l336975f3udbca15c6233f929a@mail.gmail.co
 m>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
	<b654cd2e0907281922i4666016bs4fc45fa1acc7f4da@mail.gmail.com>
	<20090729023727.272FB3A4099@sparrow.telecommunity.com>
	<b654cd2e0907282035l336975f3udbca15c6233f929a@mail.gmail.com>
Message-ID: <20090729044116.919B53A4099@sparrow.telecommunity.com>

At 10:35 PM 7/28/2009 -0500, Ian Bicking wrote:
>On Tue, Jul 28, 2009 at 9:40 PM, P.J. Eby<pje at telecommunity.com> wrote:
> > At 09:22 PM 7/28/2009 -0500, Ian Bicking wrote:
> >>
> >> I can see how this could go quite wrong, but maybe if installers touch
> >> some file in the library directory anytime a package is
> >> installed/reinstalled/removed/etc,
> >
> > You mean, like, the mtime of the directory itself? ? ;-)
>
>Do directory mtimes get recursively updated?  I don't think they do.

That's not necessary; if imports use a cached listdir, then the 
children will get handled recursively.

>So if you have a layout:
>
>site-packages/
>   zope/
>     interface/
>       __init__.py
>
>And you update the package and update __init__.py, the mtime of
>site-packages doesn't change, does it?

Nope, but at the top level, the fact that 'zope' is present is 
unchanged, as is the presence of an 'interface' subdirectory.


>I'm saying if there was a file in site-packages/last_updated that gets
>touched everytime an installer does anything in site-packages, then
>you could cache (between processes) the lookups.

Since each invocation of the interpreter can have a different 
PYTHONPATH, the cache has to be per-directory, not global.  If it's 
per-directory, then there's no real benefit over runtime caching, 
since you now have to open and read a file (instead of just reading 
the directory).  And as I said, it's not realistic to think that 
opening and reading a file is going to beat opening and reading a 
directory for speed.


From david.lyon at preisshare.net  Wed Jul 29 06:58:25 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 29 Jul 2009 00:58:25 -0400
Subject: [Distutils]
 =?utf-8?q?Cache_PYTHONPATH=3F_=28Re=3A_make_unzipped_?=
 =?utf-8?q?eggs_be_the_default=29?=
In-Reply-To: <20090729021839.D97983A4099@sparrow.telecommunity.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
	<20090729021839.D97983A4099@sparrow.telecommunity.com>
Message-ID: <3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>

>>P.J. Eby wrote:
>>>So the optimum performance tradeoff depends on how many imports you 
>>>have *and* how many eggs you have on sys.path.  

Spoken like a true master...

and it's imho a real design bludner (blunder)..

sys.path is meant to contain directories for which interpretor
can check for packages.

Adding eggs to sys.path just prioritizes eggs (higher) and means
that anytime a package is imported, virtually every egg must be
opened to check if it has the appropriate package.

imho it's an abuse of the sys.path to do things this way.

Eggs should sit in site-packages directories like any other
package and wait their turn.

.zip/.egg should just be a transport format. The site-package
directory should just hold packages of a like format.

Third party libraries are rarely so big that they need to
be compressed to save disk space.. on any of the systems
that i know about anyway..

</ranting>

David




From jeff at taupro.com  Wed Jul 29 08:34:11 2009
From: jeff at taupro.com (Jeff Rush)
Date: Wed, 29 Jul 2009 01:34:11 -0500
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
 default)
In-Reply-To: <3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>	<20090728171210.136823A4099@sparrow.telecommunity.com>	<4A6F9F94.9000507@canterbury.ac.nz>	<20090729021839.D97983A4099@sparrow.telecommunity.com>
	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>
Message-ID: <4A6FED63.4040207@taupro.com>

David Lyon wrote:
> 
> Third party libraries are rarely so big that they need to
> be compressed to save disk space.. on any of the systems
> that i know about anyway..

Hi David.  Not just your post but others here are making assumptions on
your own working environment.  Yes there are systems you need to save
disk space on, yes there are systems where you care about I/O
performance.  These are embedded systems.

Python has a strong and growing following on small devices such as
phones (OpenMoko), music players, settops, netbooks, OLPC/XO and such.
If you haven't been following it, the Python-on-a-Chip initiative formed
from several projects took place at PyCon 2009.  The language is in a
position to become the standard control language for devices, if we
don't hobble it by assuming Python is always run on a full-blown desktop.

This attitude of allowing Python to always grow larger is prevalent on
the core developers list as well, where they are removing the ability to
compile Python selectively to drop out those portions not needed on a
platform.  The attitude there was if the embedded folks want a stripped
down version they can create and maintain it themselves, redoing work
already done years ago.  But they won't -- they'll chose the path of
least resistance and choose a more lightweight language.

Pardon the rant.  I just get frustrated when people believe that the
path forward is faster and bigger systems on our desktops when actually
desktops are dying and will be rare in ten years.  Let's keep Python
lean and flexible so it takes up residence in the infrastructure instead.

And the benefit of defaulting to zipped eggs is that it enforces on the
developer the discipline of writing his packages to use pkg_resources
instead of file I/O, to retain the future option of alternate packaging
formats.  Developers know, especially those using
test-driven-development, that if you don't regularly test against an
environment, your code will gradually rot and no longer run in that
environment.

-Jeff

From regebro at gmail.com  Wed Jul 29 09:37:17 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 29 Jul 2009 09:37:17 +0200
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
	default)
In-Reply-To: <4A6FED63.4040207@taupro.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<20090728171210.136823A4099@sparrow.telecommunity.com>
	<4A6F9F94.9000507@canterbury.ac.nz>
	<20090729021839.D97983A4099@sparrow.telecommunity.com>
	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>
	<4A6FED63.4040207@taupro.com>
Message-ID: <319e029f0907290037m409f45a6of0372495a313be5d@mail.gmail.com>

2009/7/29 Jeff Rush <jeff at taupro.com>:
> Hi David. ?Not just your post but others here are making assumptions on
> your own working environment. ?Yes there are systems you need to save
> disk space on, yes there are systems where you care about I/O
> performance. ?These are embedded systems.

Exactly. But the fact still is that these systems are the specialized
case today, so lets stop optimizing the *default* settings for them.

> And the benefit of defaulting to zipped eggs is that it enforces on the
> developer the discipline of writing his packages to use pkg_resources
> instead of file I/O

No, it just forces the developer to set zip_safe to False.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Wed Jul 29 09:51:45 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 29 Jul 2009 09:51:45 +0200
Subject: [Distutils] idea for Distribute: make unzipped eggs be the
	default
In-Reply-To: <A71FE44A-AD37-4621-8D64-54D80110F32A@gmail.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>
	<1099b90b0907281038g1aeb2da3mf9d4059388ad816c@mail.gmail.com>
	<73626eec1144ff7907636d73538896db@preisshare.net>
	<A71FE44A-AD37-4621-8D64-54D80110F32A@gmail.com>
Message-ID: <319e029f0907290051v4b5b040fvfae307996cbe5234@mail.gmail.com>

2009/7/29 Leonardo Santagada <santagada at gmail.com>:
> I think P.J. Eby is right, we need to test it before analising the results
> we don't have.

No we don't, because zipped eggs are such a pain that speed is
irrelevant in comparison. Those who *do* care about minor improvements
in startup speed can test. And then they can set their settings to
install eggs zipped by default.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From david.lyon at preisshare.net  Wed Jul 29 23:47:46 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 29 Jul 2009 17:47:46 -0400
Subject: [Distutils]
 =?utf-8?q?Cache_PYTHONPATH=3F_=28Re=3A_make_unzipped_?=
 =?utf-8?q?eggs_be_the_default=29?=
In-Reply-To: <4A6FED63.4040207@taupro.com>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>	<20090728171210.136823A4099@sparrow.telecommunity.com>	<4A6F9F94.9000507@canterbury.ac.nz>	<20090729021839.D97983A4099@sparrow.telecommunity.com>
	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>
	<4A6FED63.4040207@taupro.com>
Message-ID: <068714c7e55c9b989319917b9ac8cc44@preisshare.net>

On Wed, 29 Jul 2009 01:34:11 -0500, Jeff Rush <jeff at taupro.com> wrote:
> Hi David.  Not just your post but others here are making assumptions on
> your own working environment.  Yes there are systems you need to save
> disk space on, yes there are systems where you care about I/O
> performance.  These are embedded systems.

Maybe you too are making the assumption that I've never worked on
such devices.. :-)

I have..

> This attitude of allowing Python to always grow larger is prevalent on
> the core developers list as well, where they are removing the ability to
> compile Python selectively to drop out those portions not needed on a
> platform.

ok. But people want to add their own code.. rarely do they want to
take away.. people resist if their code is taken away..

> Pardon the rant.  I just get frustrated when people believe that the
> path forward is faster and bigger systems on our desktops when actually
> desktops are dying and will be rare in ten years.

Only because motherboards will be embedded into the monitors more and
more often..

Anyway, you're kindof biting the hairs on the tail here.. because 3rd 
party packages don't impact the size of the whole python installation 
that much.

Still, it's an interesting point...

David



From robert.kern at gmail.com  Wed Jul 29 23:58:13 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 29 Jul 2009 16:58:13 -0500
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
	default)
In-Reply-To: <068714c7e55c9b989319917b9ac8cc44@preisshare.net>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>	<20090728171210.136823A4099@sparrow.telecommunity.com>	<4A6F9F94.9000507@canterbury.ac.nz>	<20090729021839.D97983A4099@sparrow.telecommunity.com>	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>	<4A6FED63.4040207@taupro.com>
	<068714c7e55c9b989319917b9ac8cc44@preisshare.net>
Message-ID: <h4qgll$3dl$1@ger.gmane.org>

On 2009-07-29 16:47, David Lyon wrote:

> Anyway, you're kindof biting the hairs on the tail here.. because 3rd
> party packages don't impact the size of the whole python installation
> that much.

My site-packages directory would like a word with you:

[~]$ cd /Library/Frameworks/Python.framework/Versions/Current
[Current]$ du -hsc .
1.5G    .
1.5G    total
[Current]$ du -hsc lib/python2.5/site-packages
1.4G    lib/python2.5/site-packages
1.4G    total

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From exarkun at divmod.com  Thu Jul 30 00:46:27 2009
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Wed, 29 Jul 2009 18:46:27 -0400
Subject: [Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the
 default)
In-Reply-To: <319e029f0907290037m409f45a6of0372495a313be5d@mail.gmail.com>
Message-ID: <20090729224627.11822.345000650.divmod.quotient.414@henry.divmod.com>

On Wed, 29 Jul 2009 09:37:17 +0200, Lennart Regebro <regebro at gmail.com> wrote:
>2009/7/29 Jeff Rush <jeff at taupro.com>:
>> Hi David. ?Not just your post but others here are making assumptions on
>> your own working environment. ?Yes there are systems you need to save
>> disk space on, yes there are systems where you care about I/O
>> performance. ?These are embedded systems.
>
>Exactly. But the fact still is that these systems are the specialized
>case today, so lets stop optimizing the *default* settings for them.
>
>> And the benefit of defaulting to zipped eggs is that it enforces on the
>> developer the discipline of writing his packages to use pkg_resources
>> instead of file I/O
>
>No, it just forces the developer to set zip_safe to False.
>

+1.  Python offers too many convenient ways to do it "wrong".  Zipped
eggs break deployments.  They don't make developers write code that
works in that environment.  Such code only gets written when developers
choose to care about such cases.  If you want Python to excel in these
areas, you need to convince developers to care.

Jean-Paul

From david.lyon at preisshare.net  Thu Jul 30 01:20:07 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 29 Jul 2009 19:20:07 -0400
Subject: [Distutils] =?utf-8?q?Distutils_on_embedded_devices_-_was_Cache_P?=
 =?utf-8?q?YTHONPATH=3F_=28Re=3A_make_unzipped_eggs_be_the_default=29?=
In-Reply-To: <h4qgll$3dl$1@ger.gmane.org>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>	<20090728171210.136823A4099@sparrow.telecommunity.com>	<4A6F9F94.9000507@canterbury.ac.nz>	<20090729021839.D97983A4099@sparrow.telecommunity.com>	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>	<4A6FED63.4040207@taupro.com>
	<068714c7e55c9b989319917b9ac8cc44@preisshare.net>
	<h4qgll$3dl$1@ger.gmane.org>
Message-ID: <187e7a1bfed4f9b1e0c3900939724814@preisshare.net>

On Wed, 29 Jul 2009 16:58:13 -0500, Robert Kern <robert.kern at gmail.com>
wrote:
> My site-packages directory would like a word with you:
> 
> [~]$ cd /Library/Frameworks/Python.framework/Versions/Current
> [Current]$ du -hsc .
> 1.5G    .
> 1.5G    total
> [Current]$ du -hsc lib/python2.5/site-packages
> 1.4G    lib/python2.5/site-packages
> 1.4G    total

ok - so what are you complaining about? you have a 1.4G drive
or more...

It's probably a flash memory drive..

Anyway, I only do a package manager. I've never tried on
an embedded device..

I can't imagine anybody typing opening a command prompt on
a tiny screen and typing setup.py....

What is the go there with package installation..



From robert.kern at gmail.com  Thu Jul 30 01:36:49 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 29 Jul 2009 18:36:49 -0500
Subject: [Distutils] Distutils on embedded devices - was Cache
 PYTHONPATH? (Re: make unzipped eggs be the default)
In-Reply-To: <187e7a1bfed4f9b1e0c3900939724814@preisshare.net>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>	<20090728171210.136823A4099@sparrow.telecommunity.com>	<4A6F9F94.9000507@canterbury.ac.nz>	<20090729021839.D97983A4099@sparrow.telecommunity.com>	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>	<4A6FED63.4040207@taupro.com>	<068714c7e55c9b989319917b9ac8cc44@preisshare.net>	<h4qgll$3dl$1@ger.gmane.org>
	<187e7a1bfed4f9b1e0c3900939724814@preisshare.net>
Message-ID: <h4qmei$ifm$1@ger.gmane.org>

On 2009-07-29 18:20, David Lyon wrote:
> On Wed, 29 Jul 2009 16:58:13 -0500, Robert Kern<robert.kern at gmail.com>
> wrote:
>> My site-packages directory would like a word with you:
>>
>> [~]$ cd /Library/Frameworks/Python.framework/Versions/Current
>> [Current]$ du -hsc .
>> 1.5G    .
>> 1.5G    total
>> [Current]$ du -hsc lib/python2.5/site-packages
>> 1.4G    lib/python2.5/site-packages
>> 1.4G    total
>
> ok - so what are you complaining about? you have a 1.4G drive
> or more...

I am not complaining about anything. I am disputing your assertion that "3rd
party packages don't impact the size of the whole python installation
that much." That's not a universally true statement.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From david.lyon at preisshare.net  Thu Jul 30 01:44:22 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 29 Jul 2009 19:44:22 -0400
Subject: [Distutils]
 =?utf-8?q?Distutils_on_embedded_devices_-_was_Cache_P?=
 =?utf-8?q?YTHONPATH=3F_=28Re=3A_make_unzipped_eggs_be_the_default=29?=
In-Reply-To: <h4qmei$ifm$1@ger.gmane.org>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>	<20090728171210.136823A4099@sparrow.telecommunity.com>	<4A6F9F94.9000507@canterbury.ac.nz>	<20090729021839.D97983A4099@sparrow.telecommunity.com>	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>	<4A6FED63.4040207@taupro.com>	<068714c7e55c9b989319917b9ac8cc44@preisshare.net>	<h4qgll$3dl$1@ger.gmane.org>
	<187e7a1bfed4f9b1e0c3900939724814@preisshare.net>
	<h4qmei$ifm$1@ger.gmane.org>
Message-ID: <d97f269e248565d5c1274647ee4a6920@preisshare.net>

On Wed, 29 Jul 2009 18:36:49 -0500, Robert Kern <robert.kern at gmail.com>
wrote:
> I am not complaining about anything. I am disputing your assertion that
> "3rd
> party packages don't impact the size of the whole python installation
> that much." That's not a universally true statement.

ok but is it a real problem or a perceived problem ?

If it's a real problem then spend some time to trim some fat..

or spend an extra $20 and get a bigger memory card..

At least your embedded device isn't a 4k one... then we could
moan and groan together about the bad old good old days....

I really don't know enough about your hardware to say any more...

David

From robert.kern at gmail.com  Thu Jul 30 01:57:14 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 29 Jul 2009 18:57:14 -0500
Subject: [Distutils] Distutils on embedded devices - was Cache
 PYTHONPATH? (Re: make unzipped eggs be the default)
In-Reply-To: <d97f269e248565d5c1274647ee4a6920@preisshare.net>
References: <03ADC5F2-4226-424F-A6D4-AABC64000D00@zooko.com>	<20090728171210.136823A4099@sparrow.telecommunity.com>	<4A6F9F94.9000507@canterbury.ac.nz>	<20090729021839.D97983A4099@sparrow.telecommunity.com>	<3e7c0cfeaa315884e3d6791d49c88214@preisshare.net>	<4A6FED63.4040207@taupro.com>	<068714c7e55c9b989319917b9ac8cc44@preisshare.net>	<h4qgll$3dl$1@ger.gmane.org>	<187e7a1bfed4f9b1e0c3900939724814@preisshare.net>	<h4qmei$ifm$1@ger.gmane.org>
	<d97f269e248565d5c1274647ee4a6920@preisshare.net>
Message-ID: <h4qnkr$kss$1@ger.gmane.org>

On 2009-07-29 18:44, David Lyon wrote:
> On Wed, 29 Jul 2009 18:36:49 -0500, Robert Kern<robert.kern at gmail.com>
> wrote:
>> I am not complaining about anything. I am disputing your assertion that
>> "3rd
>> party packages don't impact the size of the whole python installation
>> that much." That's not a universally true statement.
>
> ok but is it a real problem or a perceived problem ?
>
> If it's a real problem then spend some time to trim some fat..
>
> or spend an extra $20 and get a bigger memory card..
>
> At least your embedded device isn't a 4k one... then we could
> moan and groan together about the bad old good old days....
>
> I really don't know enough about your hardware to say any more...

I'm not on an embedded device. I don't have a particular problem that I am 
asking you to solve. I am challenging your assumption that third party packages 
don't impact the size of the whole Python installation. It's just not true.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From kevin at bud.ca  Thu Jul 30 21:28:32 2009
From: kevin at bud.ca (Kevin Teague)
Date: Thu, 30 Jul 2009 12:28:32 -0700 (PDT)
Subject: [Distutils] setuptools: can I specify different
	install_requires for different python versions?
In-Reply-To: <20090728195736.264103A4099@sparrow.telecommunity.com>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com> 
	<20090728192344.8904A3A4099@sparrow.telecommunity.com>
	<op.uxsl6nnvbrrvlq@double> 
	<20090728195736.264103A4099@sparrow.telecommunity.com>
Message-ID: <6cf3380a-f6da-491c-9776-be6a23829b7a@p10g2000prm.googlegroups.com>

On Jul 28, 1:00 pm, "P.J. Eby" <p... at telecommunity.com> wrote:
>
> Please note that *future* fixes won't help the person who asked what
> to do right now.
>

As long as we're on the topic of *future* fixes that provide no help
what so ever for the OP ...

... It would be nice if the python standard library was packaged up
into a set of distributions in some sensible way. These distributions
would still be pulled into main Python release so that they are
installed the same as they always have, but the [python-install]/lib/
python/ directory would contain .egg-info files, so that it would be
possible to tell that the 'multiprocessing' distro is supplied by the
standard lib, and what version of the distro is included in a
particular Python release.

Then it would no longer be necessary to use hacks to require
'multiprocessing' for older versions of python, but not newer
versions, even though newer versions of python have the distro
included them, but it's now an invisible distro without a version
number, undetectable to any package installation tools.

From ianb at colorstudy.com  Fri Jul 31 00:00:04 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 30 Jul 2009 17:00:04 -0500
Subject: [Distutils] setuptools: can I specify different
	install_requires for different python versions?
In-Reply-To: <6cf3380a-f6da-491c-9776-be6a23829b7a@p10g2000prm.googlegroups.com>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com> 
	<20090728192344.8904A3A4099@sparrow.telecommunity.com>
	<op.uxsl6nnvbrrvlq@double> 
	<20090728195736.264103A4099@sparrow.telecommunity.com>
	<6cf3380a-f6da-491c-9776-be6a23829b7a@p10g2000prm.googlegroups.com>
Message-ID: <b654cd2e0907301500l5d0cdf08ra7e0373a8bf52b3c@mail.gmail.com>

On Thu, Jul 30, 2009 at 2:28 PM, Kevin Teague<kevin at bud.ca> wrote:
> ... It would be nice if the python standard library was packaged up
> into a set of distributions in some sensible way. These distributions
> would still be pulled into main Python release so that they are
> installed the same as they always have, but the [python-install]/lib/
> python/ directory would contain .egg-info files, so that it would be
> possible to tell that the 'multiprocessing' distro is supplied by the
> standard lib, and what version of the distro is included in a
> particular Python release.

This is done for ElementTree (and maybe a couple other things?), but I
agree, it would be great for every new addition to the standard
library.

It would be possible to create a script that did this for existing
Python installations.  Necessary in a sense, because 2.6.0
installations can't be changed (along with every other old
installation), and dealing with older versions is the entire point of
such an exercise.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From david.lyon at preisshare.net  Fri Jul 31 02:46:04 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Thu, 30 Jul 2009 20:46:04 -0400
Subject: [Distutils]
 =?utf-8?q?setuptools=3A_can_I_specify_different_insta?=
 =?utf-8?q?ll=5Frequires_for_different_python_versions=3F?=
In-Reply-To: <b654cd2e0907301500l5d0cdf08ra7e0373a8bf52b3c@mail.gmail.com>
References: <f6f643a20907281204p3af7694ay7fbae250d83656fc@mail.gmail.com>
	<20090728192344.8904A3A4099@sparrow.telecommunity.com>
	<op.uxsl6nnvbrrvlq@double>
	<20090728195736.264103A4099@sparrow.telecommunity.com>
	<6cf3380a-f6da-491c-9776-be6a23829b7a@p10g2000prm.googlegroups.com>
	<b654cd2e0907301500l5d0cdf08ra7e0373a8bf52b3c@mail.gmail.com>
Message-ID: <1db5ffbd539786ce008acda11b94d151@preisshare.net>

On Thu, 30 Jul 2009 17:00:04 -0500, Ian Bicking <ianb at colorstudy.com>
wrote:
> On Thu, Jul 30, 2009 at 2:28 PM, Kevin Teague<kevin at bud.ca> wrote:
>> ... It would be nice if the python standard library was packaged up
>> into a set of distributions in some sensible way. These distributions
>> would still be pulled into main Python release so that they are
>> installed the same as they always have, but the [python-install]/lib/
>> python/ directory would contain .egg-info files, so that it would be
>> possible to tell that the 'multiprocessing' distro is supplied by the
>> standard lib, and what version of the distro is included in a
>> particular Python release.
> 
> This is done for ElementTree (and maybe a couple other things?), but I
> agree, it would be great for every new addition to the standard
> library.
> 
> It would be possible to create a script that did this for existing
> Python installations.  Necessary in a sense, because 2.6.0
> installations can't be changed (along with every other old
> installation), and dealing with older versions is the entire point of
> such an exercise.

Is that a job for a package manager program?

or is it something that will be included within the standard python
do you think?

David