From mat.yeates at gmail.com  Mon May  2 20:35:11 2011
From: mat.yeates at gmail.com (Mathew Yeates)
Date: Mon, 2 May 2011 11:35:11 -0700
Subject: [Distutils] setup.py rebuild EVERYTHING on windows.
Message-ID: <BANLkTinDNxBhf+Lk4DLT=9XbGCes83E6rQ@mail.gmail.com>

Hi
I'm trying to build an extension (spice-0.12) on windows. Whenever I change
a single file, everything gets rebuilt.

??

Python2.7.1
Windows XP Visual Studio 9
setuptools 0.6c11

-Mathew

From chris at simplistix.co.uk  Tue May  3 16:09:52 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 03 May 2011 15:09:52 +0100
Subject: [Distutils] Announcing buildout-versions 1.6
Message-ID: <4DC00CB0.5020004@simplistix.co.uk>

Hi All,

I'm pleased to announce a new release of buildout-versions.

This release features the following changes:

- Fix problems with mixed-case packages when :mod:`buildout-versions`
   is used with :mod:`mr.developer`.

   Thanks to Maurits van Rees for the patch.

- Fix use with :mod:`distribute` where :mod:`distribute` would never
   be considered pinned.

   Thanks to Ruslan Spivak for the patch.

The PyPI page is here:
http://pypi.python.org/pypi/buildout-versions

The documentation is here:
http://packages.python.org/buildout-versions/use.html

If you have any problems or suggestions, please let me know on this list 
or the Simplistix open source google group!

cheers,

Chris




From tobias at typhoonae.org  Tue May  3 16:59:04 2011
From: tobias at typhoonae.org (Tobias)
Date: Tue, 3 May 2011 16:59:04 +0200
Subject: [Distutils] distribute_setup.py points to 0.6.15
Message-ID: <3BF81ECD-C285-4334-A533-12EB16590F2D@typhoonae.org>

Hi everybody,

http://python-distribute.org/distribute_setup.py points to 0.6.15

DEFAULT_VERSION should be "0.6.16" (the latest release on PyPI) instead, correct?

Furthermore, when bootstrapping with zc.buildout and distribute 0.6.16 on Mac OS X Snow Leopard (system Python 2.5), I get a Permission denied error, because distribute wants to be installed in the system Python's site-packages directory which didn't happen with 0.6.15. This is very likely caused by the incorrect DEFAULT_VERSION.

Many thanks in advance and best regards,
Tobias

From ziade.tarek at gmail.com  Tue May  3 17:24:57 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 3 May 2011 17:24:57 +0200
Subject: [Distutils] distribute_setup.py points to 0.6.15
In-Reply-To: <3BF81ECD-C285-4334-A533-12EB16590F2D@typhoonae.org>
References: <3BF81ECD-C285-4334-A533-12EB16590F2D@typhoonae.org>
Message-ID: <BANLkTinECn4ji4E4Cc9Da0-2Rsv9O8ddjg@mail.gmail.com>

On Tue, May 3, 2011 at 4:59 PM, Tobias <tobias at typhoonae.org> wrote:
> Hi everybody,
>
> http://python-distribute.org/distribute_setup.py points to 0.6.15
>
> DEFAULT_VERSION should be "0.6.16" (the latest release on PyPI) instead, correct?
>
> Furthermore, when bootstrapping with zc.buildout and distribute 0.6.16 on Mac OS X Snow Leopard (system Python 2.5), I get a Permission denied error, because distribute wants to be installed in the system Python's site-packages directory which didn't happen with 0.6.15. This is very likely caused by the incorrect DEFAULT_VERSION.
>
> Many thanks in advance and best regards,
> Tobias

Yes, that was a bad coordination on my side. Jason released it and it
did not update the online version - the script that does the release
requires my ssh key to access to the server.

I will fix this right now

Jason, can you send me a ssh key so we avoid the problem next time ?

Thx and sorry

Tarek



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



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

From mat.yeates at gmail.com  Tue May  3 22:52:08 2011
From: mat.yeates at gmail.com (Mathew Yeates)
Date: Tue, 3 May 2011 13:52:08 -0700
Subject: [Distutils] setup.py rebuild EVERYTHING on windows.
In-Reply-To: <BANLkTinDNxBhf+Lk4DLT=9XbGCes83E6rQ@mail.gmail.com>
References: <BANLkTinDNxBhf+Lk4DLT=9XbGCes83E6rQ@mail.gmail.com>
Message-ID: <BANLkTi=6PPs=B45dhwFEJhmvxMns54i=Kw@mail.gmail.com>

BUMP. Any help?


On Mon, May 2, 2011 at 11:35 AM, Mathew Yeates <mat.yeates at gmail.com> wrote:
> Hi
> I'm trying to build an extension (spice-0.12) on windows. Whenever I change
> a single file, everything gets rebuilt.
>
> ??
>
> Python2.7.1
> Windows XP Visual Studio 9
> setuptools 0.6c11
>
> -Mathew
>

From m.van.rees at zestsoftware.nl  Wed May  4 11:53:23 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Wed, 04 May 2011 11:53:23 +0200
Subject: [Distutils] setup.py rebuild EVERYTHING on windows.
In-Reply-To: <BANLkTinDNxBhf+Lk4DLT=9XbGCes83E6rQ@mail.gmail.com>
References: <BANLkTinDNxBhf+Lk4DLT=9XbGCes83E6rQ@mail.gmail.com>
Message-ID: <ipr7mj$8v8$1@dough.gmane.org>

Op 02-05-11 20:35, Mathew Yeates schreef:
> Hi
> I'm trying to build an extension (spice-0.12) on windows. Whenever I change
> a single file, everything gets rebuilt.
>
> ??
>
> Python2.7.1
> Windows XP Visual Studio 9
> setuptools 0.6c11

At first glance this seems normal behaviour to me.  If one file changes, 
this may influence the complete build.  Perhaps some compilers are smart 
enough to know in some cases that not every needs to be rebuilt, but 
still: rebuilding everything may not be the fastest solution, but it is 
the safest.


-- 
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/


From barry at python.org  Wed May  4 18:01:18 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 May 2011 12:01:18 -0400
Subject: [Distutils] virtualenv3
Message-ID: <20110504120118.76ff1b47@neurotica.wooz.org>

What's the current status of virtualenv3?  When I search the Cheeseshop, I get
two hits:

http://pypi.python.org/pypi?%3Aaction=search&term=virtualenv3&submit=search

It looks like Holger's virtualenv5 is a temporary fork of Brandon's
virtualenv3 port.  The latter seems to work fine for me on Ubuntu.  I'd like
to get a version of virtualenv3 packaged for Debian/Ubuntu, but I'm not
entirely sure which one to use.

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

From carl at oddbird.net  Wed May  4 18:15:15 2011
From: carl at oddbird.net (Carl Meyer)
Date: Wed, 04 May 2011 11:15:15 -0500
Subject: [Distutils] virtualenv3
In-Reply-To: <20110504120118.76ff1b47@neurotica.wooz.org>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
Message-ID: <4DC17B93.6070503@oddbird.net>

Hi Barry,

On 05/04/2011 11:01 AM, Barry Warsaw wrote:
> What's the current status of virtualenv3?  When I search the Cheeseshop, I get
> two hits:
> 
> http://pypi.python.org/pypi?%3Aaction=search&term=virtualenv3&submit=search
> 
> It looks like Holger's virtualenv5 is a temporary fork of Brandon's
> virtualenv3 port.  The latter seems to work fine for me on Ubuntu.  I'd like
> to get a version of virtualenv3 packaged for Debian/Ubuntu, but I'm not
> entirely sure which one to use.

Virtualenv itself supports Python 2.4 - 3.2 from a single codebase,
beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip.
Try it out!

As far as I know neither virtualenv3 nor virtualenv5 will be developed
anymore, as both were intended as stopgaps while virtualenv lacked
Python 3 support. Holger or Brandon can correct me if I'm wrong there.

Carl

From brandon.craig.rhodes at gmail.com  Wed May  4 18:47:52 2011
From: brandon.craig.rhodes at gmail.com (Brandon Craig Rhodes)
Date: Wed, 04 May 2011 12:47:52 -0400
Subject: [Distutils] virtualenv3
In-Reply-To: <4DC17B93.6070503@oddbird.net> (Carl Meyer's message of "Wed, 04
	May 2011 11:15:15 -0500")
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
Message-ID: <87tyda2z0n.fsf@asaph.rhodesmill.org>

Carl Meyer <carl at oddbird.net> writes:

> As far as I know neither virtualenv3 nor virtualenv5 will be developed
> anymore, as both were intended as stopgaps while virtualenv lacked
> Python 3 support. Holger or Brandon can correct me if I'm wrong there.

You have everything correct, Carl!  I should add a note to the
virtualenv3 entry on PyPI stating this fact so that we can discourage
its use from now on; I will add something like that this evening.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon

From barry at python.org  Wed May  4 20:05:47 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 May 2011 14:05:47 -0400
Subject: [Distutils] virtualenv3
In-Reply-To: <4DC17B93.6070503@oddbird.net>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
Message-ID: <20110504140547.2d5d1bae@neurotica.wooz.org>

On May 04, 2011, at 11:15 AM, Carl Meyer wrote:

>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase,
>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip.
>Try it out!
>
>As far as I know neither virtualenv3 nor virtualenv5 will be developed
>anymore, as both were intended as stopgaps while virtualenv lacked
>Python 3 support. Holger or Brandon can correct me if I'm wrong there.

Ah, fantastic, thanks!  Debian sid has 1.6 so I'll get that sync'd for Ubuntu
oneiric and put a back port in my PPA.

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

From lac at openend.se  Wed May  4 21:36:35 2011
From: lac at openend.se (Laura Creighton)
Date: Wed, 04 May 2011 21:36:35 +0200
Subject: [Distutils] virtualenv3
In-Reply-To: Message from Barry Warsaw <barry@python.org> of "Wed,
	04 May 2011 14:05:47 EDT." <20110504140547.2d5d1bae@neurotica.wooz.org>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
	<20110504140547.2d5d1bae@neurotica.wooz.org> 
Message-ID: <201105041936.p44JaZ0U015660@theraft.openend.se>

In a message of Wed, 04 May 2011 14:05:47 EDT, Barry Warsaw writes:
>On May 04, 2011, at 11:15 AM, Carl Meyer wrote:
>
>>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase,
>>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip.
>>Try it out!
>>
>>As far as I know neither virtualenv3 nor virtualenv5 will be developed
>>anymore, as both were intended as stopgaps while virtualenv lacked
>>Python 3 support. Holger or Brandon can correct me if I'm wrong there.
>
>Ah, fantastic, thanks!  Debian sid has 1.6 so I'll get that sync'd for Ub
>un=
>tu
>oneiric and put a back port in my PPA.
>
>Cheers,
>-Barry

If you want something that works with PyPy 1.5, you need 1.6.1 released
on Saturday.  1.6 will not work.

Laura

From barry at python.org  Wed May  4 21:40:42 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 4 May 2011 15:40:42 -0400
Subject: [Distutils] virtualenv3
In-Reply-To: <201105041936.p44JaZ0U015660@theraft.openend.se>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
	<20110504140547.2d5d1bae@neurotica.wooz.org>
	<201105041936.p44JaZ0U015660@theraft.openend.se>
Message-ID: <20110504154042.657cf1d9@neurotica.wooz.org>

On May 04, 2011, at 09:36 PM, Laura Creighton wrote:

>If you want something that works with PyPy 1.5, you need 1.6.1 released
>on Saturday.  1.6 will not work.

Cool, thanks for the info.  I've noticed that even the Debian version of 1.6
isn't being built for Python 3, so I'm going to see if I can get that enabled
first.  Then it should be fairly easy to update it to virtualenv 1.6.1.

Cheers,
-Barry

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

From barry at python.org  Fri May  6 22:49:15 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 6 May 2011 16:49:15 -0400
Subject: [Distutils] virtualenv3
In-Reply-To: <4DC17B93.6070503@oddbird.net>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
Message-ID: <20110506164915.72ae232a@neurotica.wooz.org>

On May 04, 2011, at 11:15 AM, Carl Meyer wrote:

>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase,
>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip.
>Try it out!

So I have some more information on this.  Debian Wheezy has 1.6 now, but -p
python3 still did not work.  Here is the bug report:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625784

The problem occurs when virtualenv.py re-invokes itself.  As you know, Python
puts the script's directory in sys.path[0].  On Debian virtualenv.py is a
symlink to /usr/share/pyshared/virtualenv.py so it's /usr/share/pyshared that
gets put on sys.path[0] on the second invocation.  That directory will contain
Python 2's version of pkg_resources.py which naturally causes the traceback.

OT1H, this bug is due Debian policy of symlinking its modules so that they can
be shared, which doesn't play nicely with virtualenv's re-invocation.  OTOH,
sys.path[0] isn't helpful in any case, and I can imagine some situations where
that could cause problems even on non-Debian systems.

I've worked up a patch, which you can find in the above tracker, that just
deletes sys.path[0] when VIRTUALENV_INTERPRETER_RUNNING is 'true' and when
sys.path[0] == '/usr/share/pyshared' (the latter is just paranoia ;).  I've
verified this fixes the problem on Debian and doesn't seem to cause any bad
side-effects.  I wonder if a similar patch shouldn't be applied upstream
though, to be sure that the re-invocation is insulated from the surrounding
environment?

Another suggestion given was to put virtualenv.py in a private directory,
i.e. not in Debian's equivalent of site-packages.  I don't know whether there
are other packages that try to import virtualenv.py though, so to be safe, I
just went with the sys.path hacking.

Any thoughts?

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

From lac at openend.se  Fri May  6 23:30:53 2011
From: lac at openend.se (Laura Creighton)
Date: Fri, 06 May 2011 23:30:53 +0200
Subject: [Distutils] virtualenv3
In-Reply-To: Message from Barry Warsaw <barry@python.org> of "Fri,
	06 May 2011 16:49:15 EDT." <20110506164915.72ae232a@neurotica.wooz.org>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
	<20110506164915.72ae232a@neurotica.wooz.org> 
Message-ID: <201105062130.p46LUr7h003655@theraft.openend.se>


In a message of Fri, 06 May 2011 16:49:15 EDT, Barry Warsaw writes:
>On May 04, 2011, at 11:15 AM, Carl Meyer wrote:
>
>>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase,
>>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip.
>>Try it out!
>
>So I have some more information on this.  Debian Wheezy has 1.6 now, but 
> -p python3 still did not work.  Here is the bug report:
>
>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D625784
>
>The problem occurs when virtualenv.py re-invokes itself.  As you know, Python
>puts the script's directory in sys.path[0].  On Debian virtualenv.py is a
>symlink to /usr/share/pyshared/virtualenv.py so it's /usr/share/pyshared 
>that gets put on sys.path[0] on the second invocation.  That directory will
>contain Python 2's version of pkg_resources.py which naturally causes the 
>traceback.
>
>OT1H, this bug is due Debian policy of symlinking its modules so that they
>can be shared, which doesn't play nicely with virtualenv's re-invocation.
>OTOH,
>sys.path[0] isn't helpful in any case, and I can imagine some situations 
>where that could cause problems even on non-Debian systems.
>
>I've worked up a patch, which you can find in the above tracker, that just
>deletes sys.path[0] when VIRTUALENV_INTERPRETER_RUNNING is 'true' and when
>sys.path[0] == '/usr/share/pyshared' (the latter is just paranoia ;).
>I've
>verified this fixes the problem on Debian and doesn't seem to cause any bad
>side-effects.  I wonder if a similar patch shouldn't be applied upstream
>though, to be sure that the re-invocation is insulated from the surrounding
>environment?
>
>Another suggestion given was to put virtualenv.py in a private directory,
>i.e. not in Debian's equivalent of site-packages.  I don't know whether 
>there are other packages that try to import virtualenv.py though, so to 
>be safe, I just went with the sys.path hacking.
>
>Any thoughts?
>
>Cheers,
>-Barry

Holger will have an opinion on this.  And I think tox http://codespeak.net/tox/index.html
tries to import virtualenv.py .

Laura

From carl at oddbird.net  Fri May  6 23:43:11 2011
From: carl at oddbird.net (Carl Meyer)
Date: Fri, 06 May 2011 16:43:11 -0500
Subject: [Distutils] virtualenv3
In-Reply-To: <20110506164915.72ae232a@neurotica.wooz.org>
References: <20110504120118.76ff1b47@neurotica.wooz.org>	<4DC17B93.6070503@oddbird.net>
	<20110506164915.72ae232a@neurotica.wooz.org>
Message-ID: <4DC46B6F.7000403@oddbird.net>

Hi Barry,

On 05/06/2011 03:49 PM, Barry Warsaw wrote:
> So I have some more information on this.  Debian Wheezy has 1.6 now, but -p
> python3 still did not work.  Here is the bug report:
> 
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625784
> 
> The problem occurs when virtualenv.py re-invokes itself.  As you know, Python
> puts the script's directory in sys.path[0].  On Debian virtualenv.py is a
> symlink to /usr/share/pyshared/virtualenv.py so it's /usr/share/pyshared that
> gets put on sys.path[0] on the second invocation.  That directory will contain
> Python 2's version of pkg_resources.py which naturally causes the traceback.
> 
> OT1H, this bug is due Debian policy of symlinking its modules so that they can
> be shared, which doesn't play nicely with virtualenv's re-invocation.  OTOH,
> sys.path[0] isn't helpful in any case, and I can imagine some situations where
> that could cause problems even on non-Debian systems.
> 
> I've worked up a patch, which you can find in the above tracker, that just
> deletes sys.path[0] when VIRTUALENV_INTERPRETER_RUNNING is 'true' and when
> sys.path[0] == '/usr/share/pyshared' (the latter is just paranoia ;).  I've
> verified this fixes the problem on Debian and doesn't seem to cause any bad
> side-effects.  I wonder if a similar patch shouldn't be applied upstream
> though, to be sure that the re-invocation is insulated from the surrounding
> environment?

I don't quite understand this. On my Ubuntu system, with either Ubuntu's
Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the
empty string, never the actual full path of the script's directory. How
is it ever == '/usr/share/pyshared' for you?

I was going to say that for a slightly less Debian-specific form of
paranoia, could we only delete sys.path[0] if its in fact the empty
string? But there seems to be something I'm still missing.

> Another suggestion given was to put virtualenv.py in a private directory,
> i.e. not in Debian's equivalent of site-packages.  I don't know whether there
> are other packages that try to import virtualenv.py though, so to be safe, I
> just went with the sys.path hacking.

Yes, there is code out there that imports virtualenv and uses it
programmatically, and this is supported, so breaking it would be bad.

Modulo my confusion about how your patch actually works, it seems like a
reasonable approach to me, and I'd consider applying a
non-Debian-specific version of the patch to virtualenv.

Carl

From carl at oddbird.net  Fri May  6 23:51:11 2011
From: carl at oddbird.net (Carl Meyer)
Date: Fri, 06 May 2011 16:51:11 -0500
Subject: [Distutils] virtualenv3
In-Reply-To: <4DC46B6F.7000403@oddbird.net>
References: <20110504120118.76ff1b47@neurotica.wooz.org>	<4DC17B93.6070503@oddbird.net>	<20110506164915.72ae232a@neurotica.wooz.org>
	<4DC46B6F.7000403@oddbird.net>
Message-ID: <4DC46D4F.2090201@oddbird.net>



On 05/06/2011 04:43 PM, Carl Meyer wrote:
> I don't quite understand this. On my Ubuntu system, with either Ubuntu's
> Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the
> empty string, never the actual full path of the script's directory. How
> is it ever == '/usr/share/pyshared' for you?

Eh, never mind - guess it uses the actual directory when you provide a
script file to run, instead of running interactively. I never knew that.

> I was going to say that for a slightly less Debian-specific form of
> paranoia, could we only delete sys.path[0] if its in fact the empty
> string? But there seems to be something I'm still missing.

Alternatively, could we actually follow the paths ourselves and ensure
the path that's being removed is the location of virtualenv.py? I'd just
rather not have the Debian-specific version of the fix in virtualenv.

Or, if sys.path[0] being the script's directory is an absolute
guarantee, we could just skip the paranoia entirely?

Carl

From barry at python.org  Sat May  7 00:06:01 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 6 May 2011 18:06:01 -0400
Subject: [Distutils] virtualenv3
In-Reply-To: <4DC46B6F.7000403@oddbird.net>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
	<20110506164915.72ae232a@neurotica.wooz.org>
	<4DC46B6F.7000403@oddbird.net>
Message-ID: <20110506180601.69cdd868@neurotica.wooz.org>

On May 06, 2011, at 04:43 PM, Carl Meyer wrote:

>I don't quite understand this. On my Ubuntu system, with either Ubuntu's
>Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the
>empty string, never the actual full path of the script's directory. How
>is it ever == '/usr/share/pyshared' for you?

Even in the subprocess, i.e. when the Popen.subprocess() re-invokes
sys.executable with the full path to the virtualenv.py file?

>I was going to say that for a slightly less Debian-specific form of
>paranoia, could we only delete sys.path[0] if its in fact the empty
>string? But there seems to be something I'm still missing.

See above.  It makes sense too, given how Python initializes sys.path.  I
think the extra paranoia (whether Debian-specific or not) probably isn't
necessary.  sys.path[0] just isn't needed.

>> Another suggestion given was to put virtualenv.py in a private directory,
>> i.e. not in Debian's equivalent of site-packages.  I don't know whether there
>> are other packages that try to import virtualenv.py though, so to be safe, I
>> just went with the sys.path hacking.
>
>Yes, there is code out there that imports virtualenv and uses it
>programmatically, and this is supported, so breaking it would be bad.

Great to know, thanks!

>Modulo my confusion about how your patch actually works, it seems like a
>reasonable approach to me, and I'd consider applying a
>non-Debian-specific version of the patch to virtualenv.

Cool.

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

From barry at python.org  Sat May  7 00:12:47 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 6 May 2011 18:12:47 -0400
Subject: [Distutils] virtualenv3
In-Reply-To: <4DC46D4F.2090201@oddbird.net>
References: <20110504120118.76ff1b47@neurotica.wooz.org>
	<4DC17B93.6070503@oddbird.net>
	<20110506164915.72ae232a@neurotica.wooz.org>
	<4DC46B6F.7000403@oddbird.net> <4DC46D4F.2090201@oddbird.net>
Message-ID: <20110506181247.709b47e0@neurotica.wooz.org>

On May 06, 2011, at 04:51 PM, Carl Meyer wrote:

>On 05/06/2011 04:43 PM, Carl Meyer wrote:
>> I don't quite understand this. On my Ubuntu system, with either Ubuntu's
>> Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the
>> empty string, never the actual full path of the script's directory. How
>> is it ever == '/usr/share/pyshared' for you?
>
>Eh, never mind - guess it uses the actual directory when you provide a
>script file to run, instead of running interactively. I never knew that.

Look down about line 762 (depending on version), and you'll see the Popen()
call.  It's basically calling $python /path/to/virtualenv.py where $python is
the argument to -p.

>> I was going to say that for a slightly less Debian-specific form of
>> paranoia, could we only delete sys.path[0] if its in fact the empty
>> string? But there seems to be something I'm still missing.
>
>Alternatively, could we actually follow the paths ourselves and ensure
>the path that's being removed is the location of virtualenv.py? I'd just
>rather not have the Debian-specific version of the fix in virtualenv.
>
>Or, if sys.path[0] being the script's directory is an absolute
>guarantee, we could just skip the paranoia entirely?

I think so.  I'm fairly convinced sys.path[0] just isn't necessary to resolve
any of the imports that virtualenv will need, at least in the common case.
There may of course be some alternative usages I'm not aware of.  But I think
it's safe to say that sys.path[0] will always be the directory path containing
virtualenv.py.

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

From setuptools at bugs.python.org  Mon May  9 08:56:05 2011
From: setuptools at bugs.python.org (yaneurabeya)
Date: Mon, 09 May 2011 06:56:05 +0000
Subject: [Distutils] [issue127] time.mktime simple checks fail when is_dst
	applies to the	original timestamp
In-Reply-To: <1304924165.3.0.885475292893.issue127@psf.upfronthosting.co.za>
Message-ID: <1304924165.3.0.885475292893.issue127@psf.upfronthosting.co.za>


New submission from yaneurabeya <yanegomi at gmail.com>:

There's an optimization in pkg_resources.ZipProvider._extract_resource that checks the timestamp of a zip egg's files vs the os.stat output for the real file on disk (if it exists). time.mktime is used. The problem with using this function call with -1, is that if the underlying timezone is modified between the time that the file was installed, and the next time the file is being installed or the file itself was stored without a value relative to a timezone, the _extract_resource method will re-extract and install the new file, even if the contents are the same on disk. This generates more unnecessary I/O, and creates race conditions depending on how things are installed on disk.

calendar.timegm can be used in its place, but it's not necessarily present on non-Unix platforms. A quick check that I ran shows that it's present on Cygwin, FreeBSD, Linux, and OSX however.

----------
messages: 622
nosy: yaneurabeya
priority: feature
status: unread
title: time.mktime simple checks fail when is_dst applies to the original timestamp

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

From chris at simplistix.co.uk  Mon May  9 18:05:52 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 09 May 2011 17:05:52 +0100
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>
Message-ID: <4DC810E0.8030908@simplistix.co.uk>

On 19/04/2011 20:02, Mathieu Leduc-Hamel wrote:
> Hi all, i'm curious about the status of this "issue", is there any
> support in zc.buildout/setuptools for multiple index ?

Buildout has had this with the find-links option since forever, I'm sure 
easy_install has a --find-links option too...

cheers,

Chris

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

From marrakis at gmail.com  Mon May  9 21:09:38 2011
From: marrakis at gmail.com (Mathieu Leduc-Hamel)
Date: Mon, 9 May 2011 15:09:38 -0400
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <4DC810E0.8030908@simplistix.co.uk>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>
	<4DC810E0.8030908@simplistix.co.uk>
Message-ID: <BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>

yes but with find-links i think you are forced to defined a specific
link which point directly to the package, and the index option is
where you can specify another pypi index.

am i right ?

On Mon, May 9, 2011 at 12:05 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> On 19/04/2011 20:02, Mathieu Leduc-Hamel wrote:
>>
>> Hi all, i'm curious about the status of this "issue", is there any
>> support in zc.buildout/setuptools for multiple index ?
>
> Buildout has had this with the find-links option since forever, I'm sure
> easy_install has a --find-links option too...
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? ?- http://www.simplistix.co.uk
>



-- 
Mathieu Leduc-Hamel

From carl at oddbird.net  Mon May  9 21:20:56 2011
From: carl at oddbird.net (Carl Meyer)
Date: Mon, 09 May 2011 14:20:56 -0500
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>	<4DC810E0.8030908@simplistix.co.uk>
	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>
Message-ID: <4DC83E98.3040504@oddbird.net>



On 05/09/2011 02:09 PM, Mathieu Leduc-Hamel wrote:
> yes but with find-links i think you are forced to defined a specific
> link which point directly to the package, and the index option is
> where you can specify another pypi index.
> 
> am i right ?

Depends what you mean by "point directly to the package" - you give
find-links a URL that contains HTML links to package tarballs, named
appropriately (or with #egg= suffixes) to be recognizable as
project+version. So it's pretty easy to use a webserver directory with
directory indexes on and dump whatever sdists you want in there.

But you're right that find-links isn't quite the same as using an
alternative index, or multiple indexes, just in that the URL structures
used for project/version lookups on a PyPI-compatible index have an
inherent nesting. This only really matters if you're dealing with so
many packages that dumping the sdists in a single directory becomes
unwieldy.

FWIW, pip supports both --find-links and multiple indexes (via
--extra-index-url).

Carl

From ruslan.spivak at gmail.com  Mon May  9 21:29:25 2011
From: ruslan.spivak at gmail.com (Ruslan Spivak)
Date: Mon, 9 May 2011 15:29:25 -0400
Subject: [Distutils] Setuptools + specifying project's version
Message-ID: <BANLkTinqbzGxpgs_39mQWpy7O+vCtbq4kg@mail.gmail.com>

Hi,

In http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
there is a statement that 2.1-rc2 means you've already released 2.1
and an example

"""
....
>>> parse_version('2.1-rc2') < parse_version('2.1')
False
....
"""

Running the example gives quite the opposite result (setuptools-0.6c11):

>>> parse_version('2.1-rc2') < parse_version('2.1')
True

and actually it turns out that a pre-release tag 2.1rc2 is equal to
the post-release tag 2.1-rc2

 >>> parse_version('2.1-rc2') == parse_version('2.1rc2')
True

Does anyone have any idea why that's the case or is it a bug?

Cheers,
Ruslan

From tseaver at palladion.com  Mon May  9 22:24:09 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 09 May 2011 16:24:09 -0400
Subject: [Distutils] Setuptools + specifying project's version
In-Reply-To: <BANLkTinqbzGxpgs_39mQWpy7O+vCtbq4kg@mail.gmail.com>
References: <BANLkTinqbzGxpgs_39mQWpy7O+vCtbq4kg@mail.gmail.com>
Message-ID: <iq9ih9$ev8$1@dough.gmane.org>

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

On 05/09/2011 03:29 PM, Ruslan Spivak wrote:
> Hi,
> 
> In http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
> there is a statement that 2.1-rc2 means you've already released 2.1
> and an example
> 
> """
> ....
>>>> parse_version('2.1-rc2') < parse_version('2.1')
> False
> ....
> """
> 
> Running the example gives quite the opposite result (setuptools-0.6c11):
> 
>>>> parse_version('2.1-rc2') < parse_version('2.1')
> True
> 
> and actually it turns out that a pre-release tag 2.1rc2 is equal to
> the post-release tag 2.1-rc2
> 
>  >>> parse_version('2.1-rc2') == parse_version('2.1rc2')
> True
> 
> Does anyone have any idea why that's the case or is it a bug?

Likely a bug, due to the fact that nobody who could fix it uses
post-release tags (I can't see the point, myself) -- just make another
release already).



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

iEYEARECAAYFAk3ITWkACgkQ+gerLs4ltQ4YogCfdXZw8noDKlQ/eRoBjz8Y1gO5
yN0Anj0seQNVfFw2iDGpmxpkrOpHIeRH
=IIDM
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Mon May  9 22:35:08 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 09 May 2011 16:35:08 -0400
Subject: [Distutils] Setuptools + specifying project's version
In-Reply-To: <BANLkTinqbzGxpgs_39mQWpy7O+vCtbq4kg@mail.gmail.com>
References: <BANLkTinqbzGxpgs_39mQWpy7O+vCtbq4kg@mail.gmail.com>
Message-ID: <20110509203502.748D33A4061@sparrow.telecommunity.com>

At 03:29 PM 5/9/2011 -0400, Ruslan Spivak wrote:
>Hi,
>
>In 
>http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
>there is a statement that 2.1-rc2 means you've already released 2.1
>and an example
>
>"""
>....
> >>> parse_version('2.1-rc2') < parse_version('2.1')
>False
>....
>"""
>
>Running the example gives quite the opposite result (setuptools-0.6c11):
>
> >>> parse_version('2.1-rc2') < parse_version('2.1')
>True
>
>and actually it turns out that a pre-release tag 2.1rc2 is equal to
>the post-release tag 2.1-rc2
>
>  >>> parse_version('2.1-rc2') == parse_version('2.1rc2')
>True
>
>Does anyone have any idea why that's the case or is it a bug?

If it's a bug, it's a documentation bug.  Originally, setuptools had 
the behavior described, and I later realized it was a bad idea.  ;-)

I think I skipped updating the documentation at the time, though, 
because there were still versions of setuptools in the field which 
could confuse the two, and thus using a '-' would still be a bad practice.

It might be a good idea to update it *now*, though.  ;-)


From setuptools at bugs.python.org  Tue May 10 14:51:20 2011
From: setuptools at bugs.python.org (Guy Rozendorn)
Date: Tue, 10 May 2011 12:51:20 +0000
Subject: [Distutils] [issue128] parse_version post-release tags do not work
	as expected
In-Reply-To: <1305031880.13.0.957122206521.issue128@psf.upfronthosting.co.za>
Message-ID: <1305031880.13.0.957122206521.issue128@psf.upfronthosting.co.za>


New submission from Guy Rozendorn <guy at rzn.co.il>:

according to http://peak.telecommunity.com/DevCenter/setuptools:


>>> from pkg_resources import parse_version
>>> parse_version('2.1-rc2') < parse_version('2.1')
False

but both setuptools 0.6c11 and 0.6c12dev_r88795 show that:
In [7]: parse_version('2.1-rc2') < parse_version('2.1')
Out[7]: True

So pkg_resources acts the opposite of what the documentation says.

----------
keyword: pkg_resources
messages: 623
nosy: guyroz
priority: urgent
status: unread
title: parse_version post-release tags do not work as expected

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

From hekevintran at gmail.com  Wed May 11 01:41:02 2011
From: hekevintran at gmail.com (Kevin Tran)
Date: Tue, 10 May 2011 16:41:02 -0700
Subject: [Distutils] Where is the reference of buildout options?
Message-ID: <296E53B6-48F5-485F-8C46-FF1DDB02F95A@gmail.com>

Where is a reference to the buildout options? By options I am referring to parts, eggs-directory, find-links, eggs, etc. I have seen these in other peoples' config files, but where can I find the full list of options. I was unable to find it on http://www.buildout.org/docs/index.html.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110510/b0e60872/attachment.html>

From ruslan.spivak at gmail.com  Wed May 11 02:53:52 2011
From: ruslan.spivak at gmail.com (Ruslan Spivak)
Date: Tue, 10 May 2011 20:53:52 -0400
Subject: [Distutils] Where is the reference of buildout options?
In-Reply-To: <296E53B6-48F5-485F-8C46-FF1DDB02F95A@gmail.com>
References: <296E53B6-48F5-485F-8C46-FF1DDB02F95A@gmail.com>
Message-ID: <BANLkTimmqjxbdD0yegQUm=52jUjQs_iSoA@mail.gmail.com>

On Tue, May 10, 2011 at 7:41 PM, Kevin Tran <hekevintran at gmail.com> wrote:
> Where is a reference to the buildout options? By options I am referring
> to?parts, eggs-directory, find-links, eggs, etc. I have seen these in other
> peoples' config files, but where can I find the full list of options.?I was
> unable to find it on?http://www.buildout.org/docs/index.html.

You can find it here:
http://pypi.python.org/pypi/zc.buildout/1.5.2

Cheers,
Ruslan

From chris at simplistix.co.uk  Wed May 11 15:21:13 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 11 May 2011 14:21:13 +0100
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>
	<4DC810E0.8030908@simplistix.co.uk>
	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>
Message-ID: <4DCA8D49.6090807@simplistix.co.uk>

On 09/05/2011 20:09, Mathieu Leduc-Hamel wrote:
> yes but with find-links i think you are forced to defined a specific
> link which point directly to the package, and the index option is
> where you can specify another pypi index.
>
> am i right ?

Nope,

find-links can be an a folder on disk or an html page containing links, 
such as that served by Apache's indexes. Other things may work too, 
those are the two I've tried...

cheers,

Chris

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

From jim at zope.com  Wed May 11 15:21:12 2011
From: jim at zope.com (Jim Fulton)
Date: Wed, 11 May 2011 09:21:12 -0400
Subject: [Distutils] Buildout status
Message-ID: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>

Buildout has become too complex for me to maintain.  Two factors in
particular have increased it's complexity to the breaking point, the
isolation machinery introduced in 1.5 and the code to support the fork
of setuptools.

Let me be clear about 1.5: I really *really* appreciate the effort
Gary Poster put in to that release.  I don't fault his effort, given
it's goals, I've just decided that the goals were too ambitious.

I recently released 2.0.0a1 for Python 3. Not all tests pass under
Python 2 or 3, but enough pass to make this usable with Python 3.  The
next phase of work will probably involve responding to problems people
report with this release. (So far, it's been much quieter than I
expected.)  After that, I'll get going on the version 2 release in
earnest. In the mean time, people will have some time to respond to
what I say next, which may be controversial. :)

While the current release of buildout 2 has all the features from 1.5,
future releases will not. Buildout has to get simpler, or someone else
has to take over maintenance.  Assuming the former, I plan to
eliminate some high maintenance features, including:

- Support for multiple Python interpreters within a single buildout

- Partial isolation from site packages and site.py

  Buildout will have an "isolated" mode. In this mode, it will exclude
  directories from the path that are added by site.py. (I'm not
  certain what the default should be. I previously thought buildout
  should switch to being isolated by default, but given the popularity
  of using buildout with virtualenv, I'm leaning towards making
  isolation optional.)

  z3c.recipe.scripts will be spun off to a separate project along with
  it's support code currently living in the zc.buildout package. I'll
  to whatever I can, by providing hooks, to support this recipe, but
  the maintenance of this feature has to move out of buildout.

- Support for both setuptools and distribute

  I'm going to support one, or the other, or neither.  I'm in a tough
  spot.  Distribute, which was created because setuptools wasn't being
  maintained, is no longer being maintained, except there was a recent
  release. Setuptools, which is being maintained, doesn't work with
  Python 3.  (I was thinking about forking distribute to eliminate the
  dependency, but after further consideration, I don't think that's a
  good idea, as one of these is needed to build source releases that
  depend on them.)  My current leaning is toward porting setuptools to
  2&3 and supporting only setuptools.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton

From marrakis at gmail.com  Wed May 11 15:26:00 2011
From: marrakis at gmail.com (Mathieu Leduc-Hamel)
Date: Wed, 11 May 2011 09:26:00 -0400
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <4DCA8D49.6090807@simplistix.co.uk>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>
	<4DC810E0.8030908@simplistix.co.uk>
	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>
	<4DCA8D49.6090807@simplistix.co.uk>
Message-ID: <BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>

Great, thanks Chris and Carl, but does it mean i can use the
find-links in the same spirit of the index option ?

i'll like to be able to point our buildout to our internal pypi
instance and also other ones, that was the point of my question...

On Wed, May 11, 2011 at 9:21 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> On 09/05/2011 20:09, Mathieu Leduc-Hamel wrote:
>>
>> yes but with find-links i think you are forced to defined a specific
>> link which point directly to the package, and the index option is
>> where you can specify another pypi index.
>>
>> am i right ?
>
> Nope,
>
> find-links can be an a folder on disk or an html page containing links, such
> as that served by Apache's indexes. Other things may work too, those are the
> two I've tried...
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? - http://www.simplistix.co.uk
>



-- 
Mathieu Leduc-Hamel

From chris at simplistix.co.uk  Wed May 11 15:29:23 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 11 May 2011 14:29:23 +0100
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>
	<4DC810E0.8030908@simplistix.co.uk>
	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>
	<4DCA8D49.6090807@simplistix.co.uk>
	<BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>
Message-ID: <4DCA8F33.7010601@simplistix.co.uk>

On 11/05/2011 14:26, Mathieu Leduc-Hamel wrote:
> Great, thanks Chris and Carl, but does it mean i can use the
> find-links in the same spirit of the index option ?

YES. ;-)

Chris

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

From chris at simplistix.co.uk  Wed May 11 15:37:55 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 11 May 2011 14:37:55 +0100
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
Message-ID: <4DCA9133.8050206@simplistix.co.uk>

On 11/05/2011 14:21, Jim Fulton wrote:
> While the current release of buildout 2 has all the features from 1.5,
> future releases will not. Buildout has to get simpler,

That would be good for everyone :-)

> has to take over maintenance.  Assuming the former, I plan to
> eliminate some high maintenance features, including:
>
> - Support for multiple Python interpreters within a single buildout

Yay!

> - Partial isolation from site packages and site.py

-0 - It's a nice idea, and it'd be great to rely on some stuff from 
system python (especially when that's Enthought's Python Distribution) 
or Debian/Ubuntu/Red Hat packages when libraries are hard to compile, 
but this seems to work fine in Buildout's "non-isolated" mode, right?
(ie: if I say I want fancylib 1.3, and the system has 1.2, Buildout will 
try and install?)

>    certain what the default should be. I previously thought buildout
>    should switch to being isolated by default, but given the popularity
>    of using buildout with virtualenv, I'm leaning towards making
>    isolation optional.)

I think people only use virtualenv with buildout because it isn't 
isolated by default.

>    z3c.recipe.scripts will be spun off to a separate project along with
>    it's support code currently living in the zc.buildout package. I'll
>    to whatever I can, by providing hooks, to support this recipe, but
>    the maintenance of this feature has to move out of buildout.

+0

> - Support for both setuptools and distribute
>
>    I'm going to support one, or the other, or neither.

Neither would get my vote, but then I suspect maintaining the needed 
subset of both to do the things you need to do may be a lot of work :-/

Chris

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

From ziade.tarek at gmail.com  Wed May 11 16:21:44 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 11 May 2011 16:21:44 +0200
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
Message-ID: <BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>

On Wed, May 11, 2011 at 3:21 PM, Jim Fulton <jim at zope.com> wrote:
...
>
> - Support for both setuptools and distribute
>
> ?I'm going to support one, or the other, or neither. ?I'm in a tough
> ?spot. ?Distribute, which was created because setuptools wasn't being
> ?maintained, is no longer being maintained, except there was a recent
> ?release.

Distribute is not as active as it was because we focus on the stdlib,
but some people are working on it and doing releases.

And we are planning to use it as a bridge for Python 3.3 new
Distutils2 adoption by adding forward-compatibility for the new
dist-info format.

But in any case, if there's a bug, feel free to provide a patch, and
it will be commited, then released.  OSS ftw.


> Setuptools, which is being maintained, doesn't work with?Python 3.

ha ha, that is such a funny statement: it's more maintained than
Distribute but does not work with Python 3     :)


>?(I was thinking about forking distribute to eliminate the
> ?dependency, but after further consideration, I don't think that's a
> ?good idea, as one of these is needed to build source releases that
> ?depend on them.)
> My current leaning is toward porting setuptools to
> ?2&3 and supporting only setuptools.

Not sure to folllow.  You want to port Setuptools into py3k... again ?
 If so, this was done already in Distribute, and you can join the
project.

Or you want to copy our work from Distribute back into Setuptools  ?
I would not mind of course, merging back the 2 projects would be
awesome -- but I have no hopes on this.

Although, my suggestion would be to start digging into the
Distutils2/packaging project instead, since that will be in the
standard library, and backported in 2.x.

I believe it provides all the features buildout needs. And if not we
should add them

I think it boils down to: we should *all* work together in the
Distutils2/packaging project for all the basic packaging features we
need in third-party tools.


Cheers
Tarek

>
> Jim
>
> --
> Jim Fulton
> http://www.linkedin.com/in/jimfulton
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From carl at oddbird.net  Wed May 11 18:02:03 2011
From: carl at oddbird.net (Carl Meyer)
Date: Wed, 11 May 2011 11:02:03 -0500
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>	<4DC810E0.8030908@simplistix.co.uk>	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>	<4DCA8D49.6090807@simplistix.co.uk>
	<BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>
Message-ID: <4DCAB2FB.3080108@oddbird.net>

Hi Mathieu. To complexify Chris' unambiguous "YES!" slightly:

On 05/11/2011 08:26 AM, Mathieu Leduc-Hamel wrote:
> Great, thanks Chris and Carl, but does it mean i can use the
> find-links in the same spirit of the index option ?

In the same spirit, certainly. But the details of how you use it will be
different, as I explained in my last message.

> i'll like to be able to point our buildout to our internal pypi
> instance and also other ones, that was the point of my question...

Depends what you mean by "our internal pypi instance." If you already
have a running instance of some software that emulates PyPI, including
the specific layout of PyPI's project/version URLs, and you're tied to
keeping that, you will not be able to just point find-links at that
index. You would need something more like pip's --extra-index-url; I
don't know if buildout has something like that or not.

On the other hand, if by "our internal PyPI" you just mean that you have
some sdist tarballs and you can put them on a webserver, then yes, just
dump them all in a single web-served directory, turn indexes on, and
point find-links at that URL, and that should meet your needs just as well.

Carl

From chris at simplistix.co.uk  Wed May 11 18:17:54 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 11 May 2011 17:17:54 +0100
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <4DCAB2FB.3080108@oddbird.net>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>	<4DC810E0.8030908@simplistix.co.uk>	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>	<4DCA8D49.6090807@simplistix.co.uk>
	<BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>
	<4DCAB2FB.3080108@oddbird.net>
Message-ID: <4DCAB6B2.5070408@simplistix.co.uk>

On 11/05/2011 17:02, Carl Meyer wrote:
> Depends what you mean by "our internal pypi instance." If you already
> have a running instance of some software that emulates PyPI, including
> the specific layout of PyPI's project/version URLs, and you're tied to
> keeping that, you will not be able to just point find-links at that
> index.

Sure you would, as if this was the case, it would have the same 'simple' 
view that the real PyPI has, you'd just need to point find-links at that.

I'm not sure, but you might see find-links doing the insane setuptools 
spidering this, in which case, even non-simply links will be fine.

So, the short YES would have sufficed and been less confusing ;-)

Chris

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

From carl at oddbird.net  Wed May 11 18:45:09 2011
From: carl at oddbird.net (Carl Meyer)
Date: Wed, 11 May 2011 11:45:09 -0500
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <4DCAB6B2.5070408@simplistix.co.uk>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>	<4DC810E0.8030908@simplistix.co.uk>	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>	<4DCA8D49.6090807@simplistix.co.uk>
	<BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>
	<4DCAB2FB.3080108@oddbird.net> <4DCAB6B2.5070408@simplistix.co.uk>
Message-ID: <4DCABD15.10007@oddbird.net>

Hi Chris,

On 05/11/2011 11:17 AM, Chris Withers wrote:
> On 11/05/2011 17:02, Carl Meyer wrote:
>> Depends what you mean by "our internal pypi instance." If you already
>> have a running instance of some software that emulates PyPI, including
>> the specific layout of PyPI's project/version URLs, and you're tied to
>> keeping that, you will not be able to just point find-links at that
>> index.
> 
> Sure you would, as if this was the case, it would have the same 'simple'
> view that the real PyPI has, you'd just need to point find-links at that.

That doesn't actually work. The simple index is still one link away from
the actual tarball links, and find-links doesn't spider across. I just
tested with both easy_install and pip, and with either one, pointing
find-links directly at the PyPI simple/ page does not work. You'd have
to use e.g. --find-links http://pypi.python.org/simple/projectname when
installing "projectname".

> I'm not sure, but you might see find-links doing the insane setuptools
> spidering this, in which case, even non-simply links will be fine.

simple/ is irrelevant here, it would have to spider in either case. And
it doesn't.

> So, the short YES would have sufficed and been less confusing ;-)

Also wrong ;-)

Carl

From chris at simplistix.co.uk  Wed May 11 18:44:50 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 11 May 2011 17:44:50 +0100
Subject: [Distutils] Support for multi-index ?
In-Reply-To: <4DCABD15.10007@oddbird.net>
References: <BANLkTimJKSXGsY-BGUPxfYcupH364GpwCA@mail.gmail.com>	<4DC810E0.8030908@simplistix.co.uk>	<BANLkTin0sE6x+8M_XUgozkGTCdczTj4ttQ@mail.gmail.com>	<4DCA8D49.6090807@simplistix.co.uk>
	<BANLkTi=da74Td9bxz1wZR8=r8w3d09ACoA@mail.gmail.com>
	<4DCAB2FB.3080108@oddbird.net> <4DCAB6B2.5070408@simplistix.co.uk>
	<4DCABD15.10007@oddbird.net>
Message-ID: <4DCABD02.8000305@simplistix.co.uk>

On 11/05/2011 17:45, Carl Meyer wrote:
>> So, the short YES would have sufficed and been less confusing ;-)
>
> Also wrong ;-)

*shrugs* Now I'm glad that setting up a folder full of sdists and 
pointing Apache at them is both easy *and* works, I've never had to do 
anything crazy like set up my own PyPI ;-)

Chris

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

From jim at zope.com  Wed May 11 18:44:47 2011
From: jim at zope.com (Jim Fulton)
Date: Wed, 11 May 2011 12:44:47 -0400
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
Message-ID: <BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>

On Wed, May 11, 2011 at 10:21 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton <jim at zope.com> wrote:
> ...
> Not sure to folllow. ?You want to port Setuptools into py3k... again ?
> ?If so, this was done already in Distribute, and you can join the
> project.

I don't really want to join a project. I already have a number of
projects.

> Or you want to copy our work from Distribute back into Setuptools ??
> I would not mind of course, merging back the 2 projects would be
> awesome -- but I have no hopes on this.

It's possible that I could reuse that work.  I'd rather port to 2&3
rather than 3.  That is, I'd rather not rely on 2to3 at deployment
time. I find installing distribute in Python 3 to be really annoying
due to the spew from 2to3. I also find the 2to3 development model
really unattractive.

> Although, my suggestion would be to start digging into the
> Distutils2/packaging project instead, since that will be in the
> standard library, and backported in 2.x.

When it's mature, I'll use it.

> I believe it provides all the features buildout needs. And if not we
> should add them

Buildout needs entry points.  Regardless, I fully expect to use
Packaging when it's ready, but I'm stuck with setuptools/distribute
now. I so wish that fork hadn't been done.

> I think it boils down to: we should *all* work together in the
> Distutils2/packaging project for all the basic packaging features we
> need in third-party tools.

I have lots of interesting projects I am working on and want to work
on. I have no interest in making packaging a career.  I'll use
Packaging when it's ready. In the mean time, lots of people need
buildout to work with Python 3 today.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton

From setuptools at bugs.python.org  Thu May 12 09:15:34 2011
From: setuptools at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=)
Date: Thu, 12 May 2011 07:15:34 +0000
Subject: [Distutils] [issue129] Installation problem with pyx on windows
In-Reply-To: <1305184534.54.0.503554995804.issue129@psf.upfronthosting.co.za>
Message-ID: <1305184534.54.0.503554995804.issue129@psf.upfronthosting.co.za>


New submission from Bj?rn Lindqvist <bjourne at gmail.com>:

H:\>easy_install pyx
Searching for pyx
Reading http://pypi.python.org/simple/pyx/
Reading http://pyx.sourceforge.net/
Reading http://sourceforge.net/project/showfiles.php?group_id=45430
Best match: PyX 0.10
Downloading http://sourceforge.net/projects/pyx/files/pyx/0.10/PyX-0.10.tar.gz/download
Processing PyX-0.10.tar.gz
Running PyX-0.10\setup.py -q bdist_egg --dist-dir c:\users\bjolin\appdata\local\temp\easy_install-jaiul5\PyX-0.10\egg-dist-tmp-4kffgf
error: Setup script exited with error: SandboxViolation: mkdir('C:\\Python27\\share\\pyx', 511) {}

The package setup script has attempted to modify files on your system
that are not within the EasyInstall build area, and has been aborted.

This package cannot be safely installed by EasyInstall, and may not
support alternate installation locations even if you run its setup
script by hand.  Please inform the package's author and the EasyInstall
maintainers to find out if a fix or workaround is available.

----------
messages: 624
nosy: bjourne
priority: bug
status: unread
title: Installation problem with pyx on windows

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

From starsareblueandfaraway at gmail.com  Thu May 12 10:09:21 2011
From: starsareblueandfaraway at gmail.com (Roy Hyunjin Han)
Date: Thu, 12 May 2011 04:09:21 -0400
Subject: [Distutils] Option --show-response not working properly when
	uploading to PyPI
Message-ID: <BANLkTik5dgVuaM06saVc7e6dmtWMUkZvLw@mail.gmail.com>

Hi,

When I try to upload a package to PyPI using the --show-response
option, I get the following result.

python setup.py sdist upload --show-response

Python 2.7 (r27:82500, Sep 16 2010, 18:03:06)
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2

Traceback (most recent call last):
  File "setup.py", line 31, in <module>
    zip_safe=True)
  File "/usr/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/lib/python2.7/distutils/command/upload.py", line 189, in
upload_file
    self.announce('-'*75, result.read(), '-'*75)
TypeError: announce() takes at most 3 arguments (4 given)

Please CC me if you are responding to this message.

Thanks,
RHH

From ziade.tarek at gmail.com  Thu May 12 12:56:58 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 12 May 2011 12:56:58 +0200
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
Message-ID: <BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>

On Wed, May 11, 2011 at 6:44 PM, Jim Fulton <jim at zope.com> wrote:
> On Wed, May 11, 2011 at 10:21 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton <jim at zope.com> wrote:
>> ...
>> Not sure to folllow. ?You want to port Setuptools into py3k... again ?
>> ?If so, this was done already in Distribute, and you can join the
>> project.
>
> I don't really want to join a project. I already have a number of
> projects.

But the work is not going to happen only into the zc.buildout tree, right ?

>
>> Or you want to copy our work from Distribute back into Setuptools ??
>> I would not mind of course, merging back the 2 projects would be
>> awesome -- but I have no hopes on this.
>
> It's possible that I could reuse that work. ?I'd rather port to 2&3
> rather than 3. ?That is, I'd rather not rely on 2to3 at deployment
> time. I find installing distribute in Python 3 to be really annoying
> due to the spew from 2to3. I also find the 2to3 development model
> really unattractive.


The major benefit is that you don't have to maintain separate branches
for py3. Another thing is that you often don't have to deal with 2to3
internals, as you just adapt your code to be 2to3 friendly

I agree that extending 2to3 is tough, but that almost never occur. If
it occurs, you just need to ask Lennart ;)

And the benefits are larger than going manually. We tried !  I don't
see the extra spew at install time as a problem.

>
>> Although, my suggestion would be to start digging into the
>> Distutils2/packaging project instead, since that will be in the
>> standard library, and backported in 2.x.
>
> When it's mature, I'll use it.

Some of the code you need is usable today.

examples:

- easy_install's package index can be replaced by the index tool we have.
- browsing installed packages (the new PEP 376 and the old
setuptools/distutils standards)
- ...

There are a few corner cases we don't deal with. For instance, we get
things installed as non-zipped egg. I think that would be a good
default for buildout2.

But yeah, the code is not "mature" I guess, but it's driven by known
use cases for you, not new features we'll ask people to try out. And
it's going to be published in Python 3.3 in +1 year. Not sure what
your roadmap looks like but if buildout2 is a rewrite, by the time its
mature itself, 3.3 will be out imho

>
>> I believe it provides all the features buildout needs. And if not we
>> should add them
>
> Buildout needs entry points.

Entry points are just a feature on the top of browsable metadata of
installed packages. The browsable part is already provided by d2. The
installation of custom metadata is going to be
done this summer during the GSOC, Basically, a CUSTOM file in the
metadata directory. With a backward compat layer to install entry
point as custom metadata.

In a new Python3.3/packaging based projects, people will be able to
add in their setup.cfg file:

  [metadata]
  X-Entry-Points =
          group:name = here.it.is

And this will be copied in project.dist-info/CUSTOM

In fact  the plan is to *publish* setup.cfg to PyPI so tools will be
able to read it without downloading anything !

For you, it means that you could use a single API to browse metadata
for every installed project, whether they are setuptools-based or
distutils2-based.


>Regardless, I fully expect to use
> Packaging when it's ready, but I'm stuck with setuptools/distribute
> now. I so wish that fork hadn't been done.

I so wished that we could have all worked together in the first
place... On my side, the plan was to extend Distribute but that did
not happen there, as we discussed the options in the Language
Summit(s)
and imo that was a good decision. Now I am looking forward to the new tools.

But the reality is that some projects can run under Python 3 thanks to
Distribute. It's now used in most major Linux distributions, and you
saying "I will not support anything else that setuptools in buildout2"
does not sound right to me. By taking the road you've mentioned, it
seems to me that it's going to be more work and trouble that you
expect because:

- you are going to re-do all the py3 porting we already did, and that
needs backward compatibility w/ distribute,  because some people use
it for the extra python3 features we added
- you are going to maintain several branches if you don't use 2to3
- what's going to happen when distutils2-based packages will be
published ? are you going to add backward compat in setuptools, so
redo what we did in d2 in reverse ? (this is planned in Distribute, so
doubled-work again)

A simple direction in my opinion would be:

- make sure all stuff done on setuptools lately that were neglected on
distribute side get merged back - so we really have 100% identical
behavior that works under py3
  that's *way* less work.
- use when possible, pieces of distutils2 in buildout2, since we
target backward compat for all our APIs.

Because as far as I know, the Setuptools project is just doing
bugfixing. I don't think there are yet new features in it. I consider
that all setuptools-related technologies are now superseded by the new
stuff we do in packaging (that greatly inherit from them)

An even most simple direction, which would be for the best for all --
but that's not going to happen I guess :

- merge Distribute and Setuptools projects in the same codebase, and
have more people maintaining it. It's a mutual benefit. Features added
in Distribute are not controversial. (per-user easy install support,
py3 support)
- start to use in it, when possible, pieces of distutils2, so
Distribute/Setuptools become PEP 345/PEP 376 aware
- stop adding features so distutils2/packaging slowly takes over


>
>> I think it boils down to: we should *all* work together in the
>> Distutils2/packaging project for all the basic packaging features we
>> need in third-party tools.
>
> I have lots of interesting projects I am working on and want to work
> on. I have no interest in making packaging a career.

We're all on the same page here. And it seems to me that you're
planning quite a packaging career in buildout2 ;)

> I'll use
> Packaging when it's ready. In the mean time, lots of people need
> buildout to work with Python 3 today.

So imho you should take the shortest path to this goal, but in the
meantime without ignoring what's coming next -- because you'll want to
use d2-based projects in buildout2 quite soon


Cheers
Tarek

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

From jim at zope.com  Thu May 12 15:28:20 2011
From: jim at zope.com (Jim Fulton)
Date: Thu, 12 May 2011 09:28:20 -0400
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
Message-ID: <BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>

On Thu, May 12, 2011 at 6:56 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Wed, May 11, 2011 at 6:44 PM, Jim Fulton <jim at zope.com> wrote:
>> On Wed, May 11, 2011 at 10:21 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton <jim at zope.com> wrote:
>>> ...
>>> Not sure to folllow. ?You want to port Setuptools into py3k... again ?
>>> ?If so, this was done already in Distribute, and you can join the
>>> project.
>>
>> I don't really want to join a project. I already have a number of
>> projects.
>
> But the work is not going to happen only into the zc.buildout tree,
> right ?

No. If I do this, I'd work with Phillip Eby.

If you tell me that distribute is being actively maintained, I'll use
distribute. What I've heard in the past is that distribute wasn't
being worked on. I'd interpreted this to mean that it wasn't being
maintained. Perhaps I misinterpreted. Again, if you assure me that it
is being maintained, I'll use it instead.

...

>>> Although, my suggestion would be to start digging into the
>>> Distutils2/packaging project instead, since that will be in the
>>> standard library, and backported in 2.x.
>>
>> When it's mature, I'll use it.
>
> Some of the code you need is usable today.

"Some" isn't good enough. There's another issue that I'll mention below.

>
> examples:
>
> - easy_install's package index can be replaced by the index tool we have.
> - browsing installed packages (the new PEP 376 and the old
> setuptools/distutils standards)
> - ...
>
> There are a few corner cases we don't deal with. For instance, we get
> things installed as non-zipped egg. I think that would be a good
> default for buildout2.
>
> But yeah, the code is not "mature" I guess, but it's driven by known
> use cases for you, not new features we'll ask people to try out. And
> it's going to be published in Python 3.3 in +1 year. Not sure what
> your roadmap looks like but if buildout2 is a rewrite, by the time its
> mature itself, 3.3 will be out imho

Buildout needs setuptools/distribute in 2 ways:

1. Buildout uses it to download and install packages

2. Buildout makes it available in the path when installing source
   distributions that import setuptools.  It's going to be a *long*
   time before this need goes away.

For a while, I was thinking of forking distribute to address #1, but
that wouldn't address #2, which is just as importasnt.

...

>>Regardless, I fully expect to use
>> Packaging when it's ready, but I'm stuck with setuptools/distribute
>> now. I so wish that fork hadn't been done.
>
> I so wished that we could have all worked together in the first
> place...

What?  I don't understand.  You make it sound as if I refused to work
with you.  If you are suggesting that I failed to contribute to
distribute or distutils2, you'll have to excuse me for choosing to
work on other projects. Buildout is just a consumer of setuptools (and
packaging in the future).

...

> But the reality is that some projects can run under Python 3 thanks to
> Distribute.

True, including buildout.

> It's now used in most major Linux distributions, and you
> saying "I will not support anything else that setuptools in buildout2"
> does not sound right to me. By taking the road you've mentioned, it
> seems to me that it's going to be more work and trouble that you
> expect because:
>
> - you are going to re-do all the py3 porting we already did, and that
> needs backward compatibility w/ distribute, ?because some people use
> it for the extra python3 features we added
> - you are going to maintain several branches if you don't use 2to3
> - what's going to happen when distutils2-based packages will be
> published ? are you going to add backward compat in setuptools, so
> redo what we did in d2 in reverse ? (this is planned in Distribute, so
> doubled-work again)

What I said was that I wasn't going to support both. Again, if you
assure me that distribute is being maintained, then I'll avoid the
work of porting setuptools to Python 3 and just use distribute.  OTOH,
if you tell me I have to wait for "packaging" to be widely adopted,
well, that's just not going to cut it.

> A simple direction in my opinion would be:
>
> - make sure all stuff done on setuptools lately that were neglected on
> distribute side get merged back - so we really have 100% identical
> behavior that works under py3

I soo f%$#ing hate the fork.

> ?that's *way* less work.

<shrug>

> - use when possible, pieces of distutils2 in buildout2, since we
> target backward compat for all our APIs.
>
> Because as far as I know, the Setuptools project is just doing
> bugfixing. I don't think there are yet new features in it. I consider
> that all setuptools-related technologies are now superseded by the new
> stuff we do in packaging (that greatly inherit from them)

>From talking to Phillip, I think he intends to update setuptools to
reflect new peps.  Personally, I'd be happy to see it (and distribute)
just fix bugs and remain stable.

I'm totally on board with the move to packaging, but until all of the
packages that buildout needs to install switch away from setuptools, I
have to be able to provide setuptools support.

>
> An even most simple direction, which would be for the best for all --
> but that's not going to happen I guess :
>
> - merge Distribute and Setuptools projects in the same codebase, and
> have more people maintaining it. It's a mutual benefit. Features added
> in Distribute are not controversial. (per-user easy install support,
> py3 support)

IOW, unfork. I would *love* *LOVE* to see that happen.

> - start to use in it, when possible, pieces of distutils2, so
> Distribute/Setuptools become PEP 345/PEP 376 aware

<shrug> sure. That's reasonable. First, buildout has to get under
control. That's my problem (and the problem of people graciously
helping me).


> - stop adding features so distutils2/packaging slowly takes over

Absolutely.  I couldn't agree more.  Just understand that we're going
to have to support old packages that import setuptools in their setup
scripts indefinitely.  That's one of the biggest challenges I see.
Maybe packaging can (does?) provide a shim for this.

>>> I think it boils down to: we should *all* work together in the
>>> Distutils2/packaging project for all the basic packaging features we
>>> need in third-party tools.
>>
>> I have lots of interesting projects I am working on and want to work
>> on. I have no interest in making packaging a career.
>
> We're all on the same page here. And it seems to me that you're
> planning quite a packaging career in buildout2 ;)

I'm committed to buildout because I use it and the community depends
on it.  I don't want to be responsible for the infrastructure
underneath it -- if I can avoid it.

>> I'll use
>> Packaging when it's ready. In the mean time, lots of people need
>> buildout to work with Python 3 today.
>
> So imho you should take the shortest path to this goal, but in the
> meantime without ignoring what's coming next -- because you'll want to
> use d2-based projects in buildout2 quite soon

That's a good point, but I also have to support setuptools-based
projects indefinitely.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton

From barry at python.org  Thu May 12 15:46:42 2011
From: barry at python.org (Barry Warsaw)
Date: Thu, 12 May 2011 15:46:42 +0200
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
	<BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
Message-ID: <20110512154642.67ebde8e@snowdog>

On May 12, 2011, at 09:28 AM, Jim Fulton wrote:

>If you tell me that distribute is being actively maintained, I'll use
>distribute. What I've heard in the past is that distribute wasn't
>being worked on. I'd interpreted this to mean that it wasn't being
>maintained. Perhaps I misinterpreted. Again, if you assure me that it
>is being maintained, I'll use it instead.

FWIW, if buildout 2 only supports setuptools, it'll be much less interesting
to me.  Debian and Ubuntu use distribute by default, as does all of my own
personal projects.

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

From agroszer.ll at gmail.com  Thu May 12 15:54:19 2011
From: agroszer.ll at gmail.com (Adam GROSZER)
Date: Thu, 12 May 2011 15:54:19 +0200
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
	<BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
Message-ID: <4DCBE68B.50706@gmail.com>

Hello,

On 05/12/2011 03:28 PM, Jim Fulton wrote:
> If you tell me that distribute is being actively maintained, I'll use
> distribute. What I've heard in the past is that distribute wasn't
> being worked on. I'd interpreted this to mean that it wasn't being
> maintained. Perhaps I misinterpreted. Again, if you assure me that it
> is being maintained, I'll use it instead.

I fixed a bug some weeks ago.
https://bitbucket.org/tarek/distribute/issue/200/win-amd64exe-cannot-be-installed
I sort of dropped the lead to PJE too.
The result is that distribute had the release in about a week, 
setuptools is nowhere.

-- 
Best regards,
  Adam GROSZER
--
Quote of the day:
The most incomprehensible thing about the world is that it is 
comprehensible.  -  Albert Einstein

From mikroman at shaw.ca  Thu May 12 04:28:01 2011
From: mikroman at shaw.ca (mikroman at shaw.ca)
Date: Wed, 11 May 2011 19:28:01 -0700
Subject: [Distutils] third party program or python error
Message-ID: <3DC588DC629147D1BB3817D03A28DF4D@MikePC>

    This request may be beyond the scope of your help. I am trying to solve an issue that involves tix84.dll, a side-by-side error, .mp4 extension, and a wininst.exe that occurs from within Corel?s Paint Shop Photo Pro x3. An unusual request that may not involve Python at all, but, rather ?some else?s programming.? ? of course. I have scanned through Python?s FAQ?s and bug checker - as a side note I must say that I deeply respect the way this website is organized ? truly brilliant and a lot of webmasters could learn from this layout. I can say that I am not a programmer. At least not advanced enough to be commercially successful. I would consider myself to be a competent bug checker yet I am stumped. I have included here a lot of information pertaining to this error. Would it be appropriate to send you error logs that might help?
    Python was included in Corel?s Paint Shop Photo Pro x3 version that I installed. Strangely the tix84.dll is not present in the Python dll library directory that is installed by PSP. I did locate that file from a known source and place it there which allows a certain PSP installation package to operate (which I believe is not supposed to occur in the first place); that would be wininst-8_d.exe which is present in the proper directory ? yet Windows error log reports that it can?t find it. This installer wouldn?t continue without that dll. Now that it was able to continue and finish this peculiar installation, any attempt to start the program halts with ?DetectLanguage()error. Exiting.?  The program did function normally in every way it was supposed to previous to this odd installation. The strangest thing is that this installer was only initiated when I would attempt to open an .mp4 file in any fashion whether PSP was running or not. Until recently I would normally cancel the install operation and if I was running the application PSP would continue as usual. I ignored it. This was the first program I had installed after completely installing and updating a clean Windows 7 64bit on a new machine. The PSP program itself was further updated four times. This problem occurred before and after that procedure. Everything else that has been installed, 32 or 64 bit, has performed perfectly...well as perfect as humans can get.
    I have viewed the Corel message board and found several occurrences of this problem with no solutions provided. I will also post this to comp.lang.python seeking help.
    I would like to thank you now for taking your time to read this and I hope you can lead me in the right direction.

Mike Loewen
c=64 rulez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110511/4763cb6b/attachment.html>

From ziade.tarek at gmail.com  Thu May 12 16:09:56 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 12 May 2011 16:09:56 +0200
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
	<BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
Message-ID: <BANLkTin+y0aiyZLNnsWYGag_DVfTA=WAPA@mail.gmail.com>

On Thu, May 12, 2011 at 3:28 PM, Jim Fulton <jim at zope.com> wrote:
> On Thu, May 12, 2011 at 6:56 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Wed, May 11, 2011 at 6:44 PM, Jim Fulton <jim at zope.com> wrote:
>>> On Wed, May 11, 2011 at 10:21 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton <jim at zope.com> wrote:
>>>> ...
>>>> Not sure to folllow. ?You want to port Setuptools into py3k... again ?
>>>> ?If so, this was done already in Distribute, and you can join the
>>>> project.
>>>
>>> I don't really want to join a project. I already have a number of
>>> projects.
>>
>> But the work is not going to happen only into the zc.buildout tree,
>> right ?
>
> No. If I do this, I'd work with Phillip Eby.
>
> If you tell me that distribute is being actively maintained, I'll use
> distribute. What I've heard in the past is that distribute wasn't
> being worked on. I'd interpreted this to mean that it wasn't being
> maintained. Perhaps I misinterpreted. Again, if you assure me that it
> is being maintained, I'll use it instead.

I can't spend anymore the time on it regularly unfortunately, I have
to make choice about my free time and I chose to work in the stdlib
upcoming package.

But I can assure the following (that what happened lately) :

1- anyone that wish to contribute a patch can do it, I give commiter
writes for this
2- we are now several people that can push a release at PyPI. I can
add more people if I know them
3- When I do releases, I do post-review of patches
4- Some other folks have enough knowledge now to do 3.

There are a few patches pending that should be commited, and I am not
following Setuptools activity as I used too by a lack of time,
so there are probably a few commits to backport.

I think that's less of a day of work altogether as far as I can see.
I can spent this time real soon and do a release so we're up to date,
but you or someone else would need to help in the future.

I don't know if this is a superior approach to PJE's approach on
maintenanceship, but it means that any big issue that would happen in
the code will not be locked by a single person.

For instance OS packagers have an access to it, and can work out
problems they had downstream. I don't think we're anymore on the "no
one can understand the code base" line.


...

>>
>> I so wished that we could have all worked together in the first
>> place...
>
> What? ?I don't understand. ?You make it sound as if I refused to work
> with you. ?If you are suggesting that I failed to contribute to
> distribute or distutils2, you'll have to excuse me for choosing to
> work on other projects. Buildout is just a consumer of setuptools (and
> packaging in the future).

Sorry for the confusion, I was not pointing any finger at you.  "we"
referred to all parties involved for packaging tools, setuptools,
distutils, distribute.

I was just indirectly saying that I also wished we did not forked and
be able to get along. But  I am still glad we did since we offered
setuptools for py3.

...
>> - what's going to happen when distutils2-based packages will be
>> published ? are you going to add backward compat in setuptools, so
>> redo what we did in d2 in reverse ? (this is planned in Distribute, so
>> doubled-work again)
>
> What I said was that I wasn't going to support both.

But if a project supports only distutils2 in the future, you cannot
force it to use setuptools' metadata.

Yet, it will express dependencies you need to deal with. (PEP 345)

...
>
> From talking to Phillip, I think he intends to update setuptools to
> reflect new peps. ?Personally, I'd be happy to see it (and distribute)
> just fix bugs and remain stable.

I agree for bug fixing.

In the meantime I also partially agree w/ PJE:  package_resources
should be able to see packages installed by distutils2,
o/w that's not going to work well


>
> I'm totally on board with the move to packaging, but until all of the
> packages that buildout needs to install switch away from setuptools, I
> have to be able to provide setuptools support.

So do we. Packaging supports the installation of setuptools-based
projects, and also reading metadata from project installed by it.

...
>
> IOW, unfork. I would *love* *LOVE* to see that happen.

Me too, as long as we have more than one person on board  :)


>
>> - start to use in it, when possible, pieces of distutils2, so
>> Distribute/Setuptools become PEP 345/PEP 376 aware
>
> <shrug> sure. That's reasonable. First, buildout has to get under
> control. That's my problem (and the problem of people graciously
> helping me).
>
>
>> - stop adding features so distutils2/packaging slowly takes over
>
> Absolutely. ?I couldn't agree more. ?Just understand that we're going
> to have to support old packages that import setuptools in their setup
> scripts indefinitely. ?That's one of the biggest challenges I see.
> Maybe packaging can (does?) provide a shim for this.

As I said earlier, we do have backward compat in everything we do with
packages. That leads to ugly code in some places, but we have to.

But as you said, there's the maturity problem...

Cheers
Tarek

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

From jim at zope.com  Thu May 12 16:29:55 2011
From: jim at zope.com (Jim Fulton)
Date: Thu, 12 May 2011 10:29:55 -0400
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTin+y0aiyZLNnsWYGag_DVfTA=WAPA@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
	<BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
	<BANLkTin+y0aiyZLNnsWYGag_DVfTA=WAPA@mail.gmail.com>
Message-ID: <BANLkTikpd3WV0WsC43YER5m7k+g8K5jCgQ@mail.gmail.com>

On Thu, May 12, 2011 at 10:09 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
...
>>> - stop adding features so distutils2/packaging slowly takes over
>>
>> Absolutely. ?I couldn't agree more. ?Just understand that we're going
>> to have to support old packages that import setuptools in their setup
>> scripts indefinitely. ?That's one of the biggest challenges I see.
>> Maybe packaging can (does?) provide a shim for this.
>
> As I said earlier, we do have backward compat in everything we do with
> packages. That leads to ugly code in some places, but we have to.
>
> But as you said, there's the maturity problem...

OK, given the discussion, I guess the easiest course for buildout would be
for buildout 2 to support just distribute next (to simplify the code)
and then work
on transitioning to packaging.  Buildout 1 would largely stay as it is with bug
fixes.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton

From kelsey.hightower at gmail.com  Thu May 12 20:20:57 2011
From: kelsey.hightower at gmail.com (Kelsey Hightower)
Date: Thu, 12 May 2011 14:20:57 -0400
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTikpd3WV0WsC43YER5m7k+g8K5jCgQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
	<BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
	<BANLkTin+y0aiyZLNnsWYGag_DVfTA=WAPA@mail.gmail.com>
	<BANLkTikpd3WV0WsC43YER5m7k+g8K5jCgQ@mail.gmail.com>
Message-ID: <BANLkTin3Rur129PYeGUj+FiaB6J2m4zENw@mail.gmail.com>

> OK, given the discussion, I guess the easiest course for buildout would be
> for buildout 2 to support just distribute next (to simplify the code)
> and then work
> on transitioning to packaging. ?Buildout 1 would largely stay as it is with bug
> fixes.

Tarek, correct me if I am wrong here, but 3rd party tools will need to
rely on distribute(setuptools) as packaging/d2 will never provide a
backwards compatible substitute or API. Packaging/d2 relies on
distribute as an external dependency.

So in this case buildout2 will need to support distribute and later
add support for packaging down the road.

So buildout2 will need packaging/d2 + distribute.

From pje at telecommunity.com  Thu May 12 21:14:48 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 12 May 2011 15:14:48 -0400
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTikpd3WV0WsC43YER5m7k+g8K5jCgQ@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
	<BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
	<BANLkTin+y0aiyZLNnsWYGag_DVfTA=WAPA@mail.gmail.com>
	<BANLkTikpd3WV0WsC43YER5m7k+g8K5jCgQ@mail.gmail.com>
Message-ID: <20110512191452.C119A3A4061@sparrow.telecommunity.com>

At 10:29 AM 5/12/2011 -0400, Jim Fulton wrote:
>On Thu, May 12, 2011 at 10:09 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>...
> >>> - stop adding features so distutils2/packaging slowly takes over
> >>
> >> Absolutely.  I couldn't agree more.  Just understand that we're going
> >> to have to support old packages that import setuptools in their setup
> >> scripts indefinitely.  That's one of the biggest challenges I see.
> >> Maybe packaging can (does?) provide a shim for this.
> >
> > As I said earlier, we do have backward compat in everything we do with
> > packages. That leads to ugly code in some places, but we have to.
> >
> > But as you said, there's the maturity problem...
>
>OK, given the discussion, I guess the easiest course for buildout would be
>for buildout 2 to support just distribute next (to simplify the code)
>and then work
>on transitioning to packaging.  Buildout 1 would largely stay as it 
>is with bug
>fixes.

You should be aware of a few things going forward, with respect to 
compatibility.  While Distribute includes many changes that are not 
in setuptools; the reverse is also true: setuptools includes bug 
fixes that are not currently fixed in Distribute.

One important fix is rather complex, as there was a problem with 
build-time dependency recursion that manifested itself as multiple 
bug reports for multiple packages.  This was fixed in setuptools, but 
the Distribute developers opted not to port the fix when it first 
came out a year or two ago, and AFAIK that has not changed.

So, you should be aware that you may have some non-trivial merge work 
ahead, if you want to include those fixes into Distribute.

In addition, Distribute contains various pieces of "anti-setuptools" 
code, in the sense that it deliberately attempts to prevent 
setuptools being installed or updated.  I don't know if you care 
about that one way or the other, but you should be aware that it exists.

(And of course, there is 2to3.)


From ziade.tarek at gmail.com  Thu May 12 21:19:31 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 12 May 2011 21:19:31 +0200
Subject: [Distutils] Buildout status
In-Reply-To: <BANLkTin3Rur129PYeGUj+FiaB6J2m4zENw@mail.gmail.com>
References: <BANLkTimex5tsbj71RO=EBXPPDzYkupSCpQ@mail.gmail.com>
	<BANLkTikR1Q4C7bpUTSJdmtTQ4+On8r0dhw@mail.gmail.com>
	<BANLkTi=DBKizTDLCB1a5s3cL+cyvKxXM9w@mail.gmail.com>
	<BANLkTi=njWDckvCcLQGujG+fTarj9X0DMQ@mail.gmail.com>
	<BANLkTikXOjz3ZeC3V81ZcR0JKCUapTc4LQ@mail.gmail.com>
	<BANLkTin+y0aiyZLNnsWYGag_DVfTA=WAPA@mail.gmail.com>
	<BANLkTikpd3WV0WsC43YER5m7k+g8K5jCgQ@mail.gmail.com>
	<BANLkTin3Rur129PYeGUj+FiaB6J2m4zENw@mail.gmail.com>
Message-ID: <BANLkTimU-XGAS16_WBBqScYFPhd3U8HDbA@mail.gmail.com>

2011/5/12 Kelsey Hightower <kelsey.hightower at gmail.com>:
>> OK, given the discussion, I guess the easiest course for buildout would be
>> for buildout 2 to support just distribute next (to simplify the code)
>> and then work
>> on transitioning to packaging. ?Buildout 1 would largely stay as it is with bug
>> fixes.
>
> Tarek, correct me if I am wrong here, but 3rd party tools will need to
> rely on distribute(setuptools) as packaging/d2 will never provide a
> backwards compatible substitute or API. Packaging/d2 relies on
> distribute as an external dependency.
>
> So in this case buildout2 will need to support distribute and later
> add support for packaging down the road.
>
> So buildout2 will need packaging/d2 + distribute.

There are three concerns:

1 - tools used by zc.buildout itself to manage packages.
2 - what's imported in setup.py in every project
3 - the project's dependencies

for 1, packaging only can be used in the long term since we provide
backward compat.
for 2, if "setuptools" is imported there, it's required of course. same for 3.


Now for how packaging installs setuptools-based project, it's dealt at
our level.

IOW, zc.buildout in the long term will only have to deal with the
packaging APIS and not worry about what we do internally.

Practically speaking, What's not clear yet is how we will inform that
we need that extra Distribute dependency.

Last, for 2 and 3, if the project uses some APIs that are supposed to
see all installed packages for example, it'll have to use Distribute
once it has added the PEP forward compat layer
(unless Setuptools also adds it, so both will work)

I hope this is clear :)

Cheers
Tarek



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

From merwok at netwok.org  Fri May 13 17:02:50 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 13 May 2011 17:02:50 +0200
Subject: [Distutils] Option --show-response not working properly when
 uploading to PyPI
In-Reply-To: <BANLkTik5dgVuaM06saVc7e6dmtWMUkZvLw@mail.gmail.com>
References: <BANLkTik5dgVuaM06saVc7e6dmtWMUkZvLw@mail.gmail.com>
Message-ID: <4DCD481A.5040908@netwok.org>

Hi,

Your bug is solved in 2.7.1.  Can you update your Python version and try
again?

The original report is http://bugs.python.org/issue9199

Regards

From ermitaoj at gmail.com  Fri May 13 20:19:58 2011
From: ermitaoj at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Alfredo?=)
Date: Fri, 13 May 2011 15:19:58 -0300
Subject: [Distutils] Geraldo Reports + Buildout
Message-ID: <BANLkTikSU87tzUJrT398J9mZmFp8L1aUvA@mail.gmail.com>

Hi everybody,

I'm not sure if this is a geraldo issue or a buildout issue but here we go.
I'm trying to include geraldo into my project buildout but it fails to
build with the following error:

 File "/Users/joaoalf/Dropbox/Projetos/dx.nfe/eggs/setuptools-0.6c12dev_r88795-py2.7.egg/setuptools/sandbox.py",
line 64, in <lambda>
 File "setup.py", line 12, in <module>
   package_dir={'': 'src'},
 File "/var/folders/Fa/Faj+MzOzGuWUpLWQhPYR+++++TI/-Tmp-/easy_install-LmafwR/Geraldo-0.4.12-stable/geraldo/__init__.py",
line 56, in <module>
 File "/var/folders/Fa/Faj+MzOzGuWUpLWQhPYR+++++TI/-Tmp-/easy_install-LmafwR/Geraldo-0.4.12-stable/geraldo/base.py",
line 8, in <module>
ImportError: No module named reportlab.lib.units
An error occurred when trying to install Geraldo 0.4.12-stable. Look
above this message for any errors that were output by easy_install.
While:
 Installing Geraldo.
 Getting distribution for 'Geraldo'.
Error: Couldn't install: Geraldo 0.4.12-stable

and here is my buildout.cfg:

[buildout]
develop = .
parts =
     xmlsec
     Geraldo
     PySPED
     dx.nfe

[xmlsec]
recipe = hexagonit.recipe.cmmi
url = http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.18.tar.gz

[Geraldo]
recipe = zc.recipe.egg
eggs =
    reportlab
    Geraldo

[PySPED]
recipe = gitrecipe
repository = https://github.com/aricaldeira/PySPED.git

[dx.nfe]
recipe = zc.recipe.egg
scripts = dxnfe
interpreter = py
eggs =
    zope.interface
    zope.component
    zope.event
    lxml
    PyXMLSec
src = src/dx/nfe

reportlab is installed into my buildout eggs directory but geraldo
seens to miss it.

Can anyone tell me how to fix it?

Thanks in advance.

Jo?o Alfredo

-- 
Jo?o Alfredo <ermitaoj at gmail.com>

From reinout at vanrees.org  Sat May 14 01:21:50 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Sat, 14 May 2011 01:21:50 +0200
Subject: [Distutils] Geraldo Reports + Buildout
In-Reply-To: <BANLkTikSU87tzUJrT398J9mZmFp8L1aUvA@mail.gmail.com>
References: <BANLkTikSU87tzUJrT398J9mZmFp8L1aUvA@mail.gmail.com>
Message-ID: <iqkeee$98r$1@dough.gmane.org>

On 13-05-11 20:19, Jo?o Alfredo wrote:
> ImportError: No module named reportlab.lib.units
> An error occurred when trying to install Geraldo 0.4.12-stable. Look
> above this message for any errors that were output by easy_install.

Perhaps reportlab.lib.units existed in an earlier version of reportlab? 
Perhaps you need an older one? Something like that is what I'd investigate.


Reinout

-- 
Reinout van Rees                    http://reinout.vanrees.org/
reinout at vanrees.org             http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"


From ermitaoj at gmail.com  Sat May 14 02:35:29 2011
From: ermitaoj at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Alfredo?=)
Date: Fri, 13 May 2011 21:35:29 -0300
Subject: [Distutils] Geraldo Reports + Buildout
In-Reply-To: <iqkeee$98r$1@dough.gmane.org>
References: <BANLkTikSU87tzUJrT398J9mZmFp8L1aUvA@mail.gmail.com>
	<iqkeee$98r$1@dough.gmane.org>
Message-ID: <BANLkTi=Oh51TsJJo1AsZDDrAjFx1Qq_6HQ@mail.gmail.com>

reportlab.lib.units exists into
<buildout_root>/eggs/reportlab-2.5-py2.7-macosx-10.5-intel.egg/ but
buildout doesn't seens to be adding it to sys.path during the building
process.

Jo?o Alfredo

2011/5/13 Reinout van Rees <reinout at vanrees.org>:
> On 13-05-11 20:19, Jo?o Alfredo wrote:
>>
>> ImportError: No module named reportlab.lib.units
>> An error occurred when trying to install Geraldo 0.4.12-stable. Look
>> above this message for any errors that were output by easy_install.
>
> Perhaps reportlab.lib.units existed in an earlier version of reportlab?
> Perhaps you need an older one? Something like that is what I'd investigate.
>
>
> Reinout
>
> --
> Reinout van Rees ? ? ? ? ? ? ? ? ? ?http://reinout.vanrees.org/
> reinout at vanrees.org ? ? ? ? ? ? http://www.nelen-schuurmans.nl/
> "If you're not sure what to do, make something. -- Paul Graham"
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Jo?o Alfredo <ermitaoj at gmail.com>

From starsareblueandfaraway at gmail.com  Tue May 17 14:35:13 2011
From: starsareblueandfaraway at gmail.com (Roy Hyunjin Han)
Date: Tue, 17 May 2011 08:35:13 -0400
Subject: [Distutils] Option --show-response not working properly when
 uploading to PyPI
In-Reply-To: <4DCD481A.5040908@netwok.org>
References: <BANLkTik5dgVuaM06saVc7e6dmtWMUkZvLw@mail.gmail.com>
	<4DCD481A.5040908@netwok.org>
Message-ID: <BANLkTinijrAb+FimbQZqWGXLpGxvF=Wqfg@mail.gmail.com>

2011/5/13 ?ric Araujo <merwok at netwok.org>:
> Your bug is solved in 2.7.1. ?Can you update your Python version and try
> again?

Thanks, ?ric.  I'll wait for Fedora 15 and tell you if the bug is there or not.

RHH

From chris at simplistix.co.uk  Tue May 17 18:53:46 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 17 May 2011 17:53:46 +0100
Subject: [Distutils] in search of graceful co-routines
Message-ID: <4DD2A81A.4030303@simplistix.co.uk>

Hi All,

I'm looking for a graceful pattern for the situation where I have a 
provider of a sequence, the consumer of a sequence and code to moderate 
the two, and where I'd like to consumer to be able to signal to the 
provider that it hasn't succeeded in processing one element in the queue.

So, I'd want the controlling code to look a lot like:

for item in provider:
   try:
     consumer.handleItem(self)
   except:
      provider.failed(item)

Now, since the sequence is long, and comes from a file, I wanted the 
provider to be an iterator, so it occurred to me I could try and use the 
new 2-way generator communication to solve the "communicate back with 
the provider", with something like:

for item in provider:
   try:
     consumer.handleItem(self)
   except:
      provider.send('fail')
   else:
      provider.send('succeed')

..but of course, this won't work, as 'send' causes the provider 
iteration to continue and then returns a value itself. That feels weird 
and wrong to me, but I guess my use case might not be what was intended 
for the send method.

Anyway, I wonder how other people would write this?
(I'm particularly interested in a sane way to use the two way 
communication that PEP 342 introduced)

cheers,

Chris

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

From chris at simplistix.co.uk  Tue May 17 19:04:40 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 17 May 2011 18:04:40 +0100
Subject: [Distutils] in search of graceful co-routines
In-Reply-To: <4DD2A81A.4030303@simplistix.co.uk>
References: <4DD2A81A.4030303@simplistix.co.uk>
Message-ID: <4DD2AAA8.9000109@simplistix.co.uk>

Apologies, wrong list...

Chris

On 17/05/2011 17:53, Chris Withers wrote:
> Hi All,
>
> I'm looking for a graceful pattern for the situation where I have a
> provider of a sequence, the consumer of a sequence and code to moderate
> the two, and where I'd like to consumer to be able to signal to the
> provider that it hasn't succeeded in processing one element in the queue.
>
> So, I'd want the controlling code to look a lot like:
>
> for item in provider:
> try:
> consumer.handleItem(self)
> except:
> provider.failed(item)
>
> Now, since the sequence is long, and comes from a file, I wanted the
> provider to be an iterator, so it occurred to me I could try and use the
> new 2-way generator communication to solve the "communicate back with
> the provider", with something like:
>
> for item in provider:
> try:
> consumer.handleItem(self)
> except:
> provider.send('fail')
> else:
> provider.send('succeed')
>
> ..but of course, this won't work, as 'send' causes the provider
> iteration to continue and then returns a value itself. That feels weird
> and wrong to me, but I guess my use case might not be what was intended
> for the send method.
>
> Anyway, I wonder how other people would write this?
> (I'm particularly interested in a sane way to use the two way
> communication that PEP 342 introduced)
>
> cheers,
>
> Chris
>

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

From interstar at gmail.com  Wed May 18 00:41:54 2011
From: interstar at gmail.com (phil jones)
Date: Tue, 17 May 2011 23:41:54 +0100
Subject: [Distutils] in search of graceful co-routines
In-Reply-To: <4DD2AAA8.9000109@simplistix.co.uk>
References: <4DD2A81A.4030303@simplistix.co.uk>
	<4DD2AAA8.9000109@simplistix.co.uk>
Message-ID: <BANLkTinvqSUZ5iCuqL_S5rrzqJ7O8sz4nQ@mail.gmail.com>

Yes, but it's a fascinating question. Where can I follow the answers?

phil

On Tue, May 17, 2011 at 6:04 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Apologies, wrong list...
>
> Chris
>
> On 17/05/2011 17:53, Chris Withers wrote:
>>
>> Hi All,
>>
>> I'm looking for a graceful pattern for the situation where I have a
>> provider of a sequence, the consumer of a sequence and code to moderate
>> the two, and where I'd like to consumer to be able to signal to the
>> provider that it hasn't succeeded in processing one element in the queue.
>>
>> So, I'd want the controlling code to look a lot like:
>>
>> for item in provider:
>> try:
>> consumer.handleItem(self)
>> except:
>> provider.failed(item)
>>
>> Now, since the sequence is long, and comes from a file, I wanted the
>> provider to be an iterator, so it occurred to me I could try and use the
>> new 2-way generator communication to solve the "communicate back with
>> the provider", with something like:
>>
>> for item in provider:
>> try:
>> consumer.handleItem(self)
>> except:
>> provider.send('fail')
>> else:
>> provider.send('succeed')
>>
>> ..but of course, this won't work, as 'send' causes the provider
>> iteration to continue and then returns a value itself. That feels weird
>> and wrong to me, but I guess my use case might not be what was intended
>> for the send method.
>>
>> Anyway, I wonder how other people would write this?
>> (I'm particularly interested in a sane way to use the two way
>> communication that PEP 342 introduced)
>>
>> 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 chris at simplistix.co.uk  Wed May 18 07:07:35 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 18 May 2011 06:07:35 +0100
Subject: [Distutils] in search of graceful co-routines
In-Reply-To: <BANLkTinvqSUZ5iCuqL_S5rrzqJ7O8sz4nQ@mail.gmail.com>
References: <4DD2A81A.4030303@simplistix.co.uk>	<4DD2AAA8.9000109@simplistix.co.uk>
	<BANLkTinvqSUZ5iCuqL_S5rrzqJ7O8sz4nQ@mail.gmail.com>
Message-ID: <4DD35417.5070307@simplistix.co.uk>

The main python list :-)

Chris

On 17/05/2011 23:41, phil jones wrote:
> Yes, but it's a fascinating question. Where can I follow the answers?
>
> phil
>
> On Tue, May 17, 2011 at 6:04 PM, Chris Withers<chris at simplistix.co.uk>  wrote:
>> Apologies, wrong list...
>>
>> Chris
>>
>> On 17/05/2011 17:53, Chris Withers wrote:
>>>
>>> Hi All,
>>>
>>> I'm looking for a graceful pattern for the situation where I have a
>>> provider of a sequence, the consumer of a sequence and code to moderate
>>> the two, and where I'd like to consumer to be able to signal to the
>>> provider that it hasn't succeeded in processing one element in the queue.
>>>
>>> So, I'd want the controlling code to look a lot like:
>>>
>>> for item in provider:
>>> try:
>>> consumer.handleItem(self)
>>> except:
>>> provider.failed(item)
>>>
>>> Now, since the sequence is long, and comes from a file, I wanted the
>>> provider to be an iterator, so it occurred to me I could try and use the
>>> new 2-way generator communication to solve the "communicate back with
>>> the provider", with something like:
>>>
>>> for item in provider:
>>> try:
>>> consumer.handleItem(self)
>>> except:
>>> provider.send('fail')
>>> else:
>>> provider.send('succeed')
>>>
>>> ..but of course, this won't work, as 'send' causes the provider
>>> iteration to continue and then returns a value itself. That feels weird
>>> and wrong to me, but I guess my use case might not be what was intended
>>> for the send method.
>>>
>>> Anyway, I wonder how other people would write this?
>>> (I'm particularly interested in a sane way to use the two way
>>> communication that PEP 342 introduced)
>>>
>>> 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
>>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

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

From setuptools at bugs.python.org  Mon May 16 16:28:52 2011
From: setuptools at bugs.python.org (Paul Makepeace)
Date: Mon, 16 May 2011 14:28:52 +0000
Subject: [Distutils] [issue130] Setuptools fails to detect Python2.7 install,
	then provides useless dialog
In-Reply-To: <1305556132.74.0.641952442617.issue130@psf.upfronthosting.co.za>
Message-ID: <1305556132.74.0.641952442617.issue130@psf.upfronthosting.co.za>


New submission from Paul Makepeace <paulm+python at paulm.com>:

I'm attempting to install setuptools with both 2.6 & 2.7 .msi

Midway thru' I get a modal complaining about not finding Python in the registry (I have a stock install so this is puzzling). Python is in C:\Python27

Upon 'OK'ing that dialog I get this useless form; see attached. Can't proceed.

----------
files: setuptools-fail-windows.PNG
messages: 626
nosy: paulm
priority: bug
status: unread
title: Setuptools fails to detect Python2.7 install, then provides useless dialog
Added file: http://bugs.python.org/setuptools/file77/setuptools-fail-windows.PNG

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue130>
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setuptools-fail-windows.PNG
Type: image/png
Size: 56042 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110516/2e26993c/attachment-0001.png>

From wjshipman at gmail.com  Thu May 19 00:08:06 2011
From: wjshipman at gmail.com (Bill Shipman)
Date: Wed, 18 May 2011 18:08:06 -0400
Subject: [Distutils] Looking for advice on distutils/dist.py and
	distutils.cfg
Message-ID: <BANLkTikJ3ncdbCsdn6W6QsELhjYXHMdp5g@mail.gmail.com>

Good evening!

I'm looking for some direction on a compiler problem.

As per the instructions at

http://www.pdynamo.org/mainpages/installation/windows.html

I am creating the file distutils/distutils.cfg which has 2 lines,
****************
[build]
compiler=mingw32
****************

as per distutils/dist.py I've also added an identical file setup.cfg in the
installation directory of this library.

Thus far it always tries to compile using the Visual Studio 9's C compiler
when I run python Install.py

I am awaiting advice from the pdynamo group but I need to move on this
quickly.

I'm using python 2.6.6 on Windows 7.  I have been advised that pdynamo will
not compile with 64bit python.

The guy who maintains their Windows installation guide sent me revised
instructions for Win7 which he says works fine for him.

Any advice would be much appreciated.

Thanks
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110518/4511e34b/attachment.html>

From wichert at wiggy.net  Thu May 19 00:11:41 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Thu, 19 May 2011 00:11:41 +0200
Subject: [Distutils] symlinks in sources
In-Reply-To: <4DB69018.1000902@wiggy.net>
References: <4DB69018.1000902@wiggy.net>
Message-ID: <4DD4441D.5090202@wiggy.net>

I love the nature feel I get from the sound of crickets, but I'ld like 
to move this forward a bit. Especially with Tarek working packaging for
Python 3.x now would be a good time to sort out the intended behaviour imho.



On 2011-4-26 11:27, Wichert Akkerman wrote:
> I am trying to figure out the intended behaviour of dealing with
> symlinks in package sources. My use case is that I have a number of
> package implementation web things, and they tend to have an interactive
> (static) prototype parts of which are reused directly in the
> application. The filesystem structure for those packages is one of two
> options:
>
> 1. Prototype is at the toplevel of the source. For example:
>
> Prototype/index.html
> Prototyle/style/main.css
> setup.py
> MANIFEST.in
> src/namespace/__init__.py
> src/namespace/templates/index.html
> src/namespace/templates/style -> ../../../Prototype/style
>
> 2. Prototype is at outside the source. For example:
>
> Prototype/index.html
> Prototyle/style/main.css
> buildout/bootstrap.py
> buildout/buildout.cfg
> buildout/src/mypackage/setup.py
> buildout/src/mypackage/MANIFEST.in
> buildout/src/mypackage/src/namespace/__init__.py
> buildout/src/mypackage/src/namespace/templates/index.html
> buildout/src/mypackage/src/namespace/templates/style ->
> ../../../../../../Prototype/style
>
> My goal is to be able to create an sdist for my package and upload that
> to pypi, and when people install that namespace/templates/style/main.css
> must exist. Currently this does not appear to be possible. The problems
> I see are:
>
> a) symlinks are skipped by distutils
> b) if you use a file finder plugin which traverses the symlink and
> reports the files they end up twice in the sdist: once for the
> Prototype and once inside the package. They second one is stored
> as a link inside the sdist, but that link is not unpacked when
> installing from the sdist and the files go missing.
>
> Trying to analyse things a bit I see a number of possible scenarios for
> symlinks:
>
> i) symlink pointing to file inside the packgage
> ii) symlink pointing to directory inside the packgage
> iii) symlink pointing to file outside the packgage, but in SCM
> iv) symlink pointing to directory outside the packgage, but in SCM
> v) symlink pointing to something outside package and not managed by SCM
>
> My expectation is that i and ii work out of the box, iii and iv should
> work if you have a file finder plugin for setuptools that traverses the
> symlink, and v to not work. Is that expectation reasonable?
>
>
> Wichert.
>


-- 
Wichert Akkerman <wichert at wiggy.net>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

From erik.m.bray at gmail.com  Thu May 19 22:10:13 2011
From: erik.m.bray at gmail.com (Erik Bray)
Date: Thu, 19 May 2011 16:10:13 -0400
Subject: [Distutils] distribute's sandboxing doesn't preserve working_set;
 leads to setup_requires problems
Message-ID: <BANLkTikDh+=j+F61fKt3kyKhcyK5b58u2g@mail.gmail.com>

Hello all,
I've got a tricky problem I'm trying to deal with.  Here's the scenario:

I'm trying to build a package that has two requirements in
setup_requires; let's say `setup_requires = ['package_A',
'package_B']`.
The problem is that "package_B" also contains "package_A" in its own
setup_requires.

What happens when I do an install/build is that package_B is
downloaded and installed--in the process it also downloads and
installs package_A in its sandbox.  This wouldn't be a problem except
that the sandboxed temp install of package_A is left in
pkg_resources.working_set.entries, and so it's assumed package_A is
already installed, and the main install doesn't try to fetch it.
However, when it goes to import from package_A, I get an import error
(because the sandbox it was installed in has since been deleted).

If I reverse the order it doesn't work either for a different, but
related problem.  package_A gets installed into the cwd and is added
to pkg_resources.working_set.  When package_B is installed it uses the
existing package_A installation, so that's fine.  But then, due to
some complicated interplay, package_A never gets added to sys.path.

I'd consider this a defect, though I'm wondering if there's something
I could do differently to avoid this situation.

Thanks,
Erik

From erik.m.bray at gmail.com  Thu May 19 22:35:47 2011
From: erik.m.bray at gmail.com (Erik Bray)
Date: Thu, 19 May 2011 16:35:47 -0400
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <BANLkTikDh+=j+F61fKt3kyKhcyK5b58u2g@mail.gmail.com>
References: <BANLkTikDh+=j+F61fKt3kyKhcyK5b58u2g@mail.gmail.com>
Message-ID: <BANLkTika+ghNnV5_7yNwBMN7OYUs=-NJhw@mail.gmail.com>

On Thu, May 19, 2011 at 4:10 PM, Erik Bray <erik.m.bray at gmail.com> wrote:
> Hello all,
> I've got a tricky problem I'm trying to deal with. ?Here's the scenario:
>
> I'm trying to build a package that has two requirements in
> setup_requires; let's say `setup_requires = ['package_A',
> 'package_B']`.
> The problem is that "package_B" also contains "package_A" in its own
> setup_requires.
>
> What happens when I do an install/build is that package_B is
> downloaded and installed--in the process it also downloads and
> installs package_A in its sandbox. ?This wouldn't be a problem except
> that the sandboxed temp install of package_A is left in
> pkg_resources.working_set.entries, and so it's assumed package_A is
> already installed, and the main install doesn't try to fetch it.
> However, when it goes to import from package_A, I get an import error
> (because the sandbox it was installed in has since been deleted).
>
> If I reverse the order it doesn't work either for a different, but
> related problem. ?package_A gets installed into the cwd and is added
> to pkg_resources.working_set. ?When package_B is installed it uses the
> existing package_A installation, so that's fine. ?But then, due to
> some complicated interplay, package_A never gets added to sys.path.
>
> I'd consider this a defect, though I'm wondering if there's something
> I could do differently to avoid this situation.

Just to confirm my theory about this, I modified
setuptools.sandbox.run_setup to also save off and restore
pkg_resources.working_set.{entries,entry_keys,by_key}.  This solves
the problem, and the build works regardless of how my setup_requires
are ordered.  Is there any reason this shouldn't be done?  It seems
reasonable to me...

It would also still be nice to find a workaround until and unless this
gets patched.  All I can think of at the moment is monkey-patching :/

Thanks,
Erik

From pje at telecommunity.com  Thu May 19 22:47:05 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 19 May 2011 16:47:05 -0400
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <BANLkTikDh+=j+F61fKt3kyKhcyK5b58u2g@mail.gmail.com>
References: <BANLkTikDh+=j+F61fKt3kyKhcyK5b58u2g@mail.gmail.com>
Message-ID: <20110519204713.907A83A4061@sparrow.telecommunity.com>

At 04:10 PM 5/19/2011 -0400, Erik Bray wrote:
>Hello all,
>I've got a tricky problem I'm trying to deal with.  Here's the scenario:
>
>I'm trying to build a package that has two requirements in
>setup_requires; let's say `setup_requires = ['package_A',
>'package_B']`.
>The problem is that "package_B" also contains "package_A" in its own
>setup_requires.
>
>What happens when I do an install/build is that package_B is
>downloaded and installed--in the process it also downloads and
>installs package_A in its sandbox.  This wouldn't be a problem except
>that the sandboxed temp install of package_A is left in
>pkg_resources.working_set.entries, and so it's assumed package_A is
>already installed, and the main install doesn't try to fetch it.
>However, when it goes to import from package_A, I get an import error
>(because the sandbox it was installed in has since been deleted).
>
>If I reverse the order it doesn't work either for a different, but
>related problem.  package_A gets installed into the cwd and is added
>to pkg_resources.working_set.  When package_B is installed it uses the
>existing package_A installation, so that's fine.  But then, due to
>some complicated interplay, package_A never gets added to sys.path.
>
>I'd consider this a defect, though I'm wondering if there's something
>I could do differently to avoid this situation.

One such workaround would be to use setuptools, since I fixed this 
bug a couple of years ago.

(Apparently, the fix still hasn't made it to Distribute.)


From pje at telecommunity.com  Fri May 20 04:28:00 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 19 May 2011 22:28:00 -0400
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <BANLkTika+ghNnV5_7yNwBMN7OYUs=-NJhw@mail.gmail.com>
References: <BANLkTikDh+=j+F61fKt3kyKhcyK5b58u2g@mail.gmail.com>
	<BANLkTika+ghNnV5_7yNwBMN7OYUs=-NJhw@mail.gmail.com>
Message-ID: <20110520022805.630EA3A4061@sparrow.telecommunity.com>

At 04:35 PM 5/19/2011 -0400, Erik Bray wrote:
>Just to confirm my theory about this, I modified 
>setuptools.sandbox.run_setup to also save off and restore 
>pkg_resources.working_set.{entries,entry_keys,by_key}.  This solves 
>the problem, and the build works regardless of how my setup_requires 
>are ordered.  Is there any reason this shouldn't be done?  It seems 
>reasonable to me... It would also still be nice to find a workaround 
>until and unless this gets patched.

That's necessary, but I don't think it's sufficient.  The changes I 
did to fix this in 2009 save other aspects of pkg_resources state 
besides just those, and I don't think it's something you can fix by 
monkeypatching.

(I could be wrong, of course, but given that setuptools was already 
been fixed, I'm not that motivated to investigate more deeply.)


From ziade.tarek at gmail.com  Fri May 20 08:58:14 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 20 May 2011 08:58:14 +0200
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <BANLkTika+ghNnV5_7yNwBMN7OYUs=-NJhw@mail.gmail.com>
References: <BANLkTikDh+=j+F61fKt3kyKhcyK5b58u2g@mail.gmail.com>
	<BANLkTika+ghNnV5_7yNwBMN7OYUs=-NJhw@mail.gmail.com>
Message-ID: <BANLkTinV_WqXtBTDzBHn0PJgKb_Ce4j97Q@mail.gmail.com>

On Thu, May 19, 2011 at 10:35 PM, Erik Bray <erik.m.bray at gmail.com> wrote:
> On Thu, May 19, 2011 at 4:10 PM, Erik Bray <erik.m.bray at gmail.com> wrote:
>> Hello all,
>> I've got a tricky problem I'm trying to deal with. ?Here's the scenario:
>>
>> I'm trying to build a package that has two requirements in
>> setup_requires; let's say `setup_requires = ['package_A',
>> 'package_B']`.
>> The problem is that "package_B" also contains "package_A" in its own
>> setup_requires.
>>
>> What happens when I do an install/build is that package_B is
>> downloaded and installed--in the process it also downloads and
>> installs package_A in its sandbox. ?This wouldn't be a problem except
>> that the sandboxed temp install of package_A is left in
>> pkg_resources.working_set.entries, and so it's assumed package_A is
>> already installed, and the main install doesn't try to fetch it.
>> However, when it goes to import from package_A, I get an import error
>> (because the sandbox it was installed in has since been deleted).
>>
>> If I reverse the order it doesn't work either for a different, but
>> related problem. ?package_A gets installed into the cwd and is added
>> to pkg_resources.working_set. ?When package_B is installed it uses the
>> existing package_A installation, so that's fine. ?But then, due to
>> some complicated interplay, package_A never gets added to sys.path.
>>
>> I'd consider this a defect, though I'm wondering if there's something
>> I could do differently to avoid this situation.
>
> Just to confirm my theory about this, I modified
> setuptools.sandbox.run_setup to also save off and restore
> pkg_resources.working_set.{entries,entry_keys,by_key}. ?This solves
> the problem, and the build works regardless of how my setup_requires
> are ordered. ?Is there any reason this shouldn't be done? ?It seems
> reasonable to me...
>
> It would also still be nice to find a workaround until and unless this
> gets patched. ?All I can think of at the moment is monkey-patching :/

I have added an issue about this here:
https://bitbucket.org/tarek/distribute/issue/205/distributes-sandboxing-doesnt-preserve

Since we're plannning a release this week-end for the upcoming python
3 release, I'll see if I can add a patch for this problem

Thanks

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



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

From lazyweb at gmail.com  Sun May 22 20:28:21 2011
From: lazyweb at gmail.com (chiggsy)
Date: Sun, 22 May 2011 11:28:21 -0700 (PDT)
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <20110519204713.907A83A4061@sparrow.telecommunity.com>
Message-ID: <26366060.2524.1306088901251.JavaMail.geo-discussion-forums@prfg19>

Are people still using setuptools? I thought that distribute was the new way 
forward...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110522/244bbed4/attachment.html>

From pje at telecommunity.com  Sun May 22 21:06:34 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 22 May 2011 15:06:34 -0400
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <26366060.2524.1306088901251.JavaMail.geo-discussion-forums
	@prfg19>
References: <20110519204713.907A83A4061@sparrow.telecommunity.com>
	<26366060.2524.1306088901251.JavaMail.geo-discussion-forums@prfg19>
Message-ID: <20110522190650.5B92F3A402D@sparrow.telecommunity.com>

At 11:28 AM 5/22/2011 -0700, chiggsy wrote:
>Are people still using setuptools?

Yes.  Over the last 9 hours alone, the 0.6 development snapshot 
version (0.6c12dev_r88795) was downloaded from over 100 unique IPs.

They most likely represent people manually upgrading to the latest 
version, since the user agents are mostly older setuptools versions, 
like 0.6c5, 0.6c9 and 0.6c11.


>  I thought that distribute was the new way forward...?

Not really.  Unless you're using Python 3, or you want different 
default options from setuptools, there's little advantage to using 
distribute.  (It also includes bugs that setuptools does not.)

In addition, the announced direction of distribute is that they're 
replacing it with the new "packaging" project, formerly known as distutils2.

Which means, again, that outside of Python 3, there's no compelling 
reason to switch; you might as well wait for "packaging" to roll around.

So, all the hype was pretty much just that: hype and FUD-slinging.


From sdouche at gmail.com  Mon May 23 01:49:45 2011
From: sdouche at gmail.com (Sebastien Douche)
Date: Mon, 23 May 2011 01:49:45 +0200
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <20110522190650.5B92F3A402D@sparrow.telecommunity.com>
References: <20110519204713.907A83A4061@sparrow.telecommunity.com>
	<26366060.2524.1306088901251.JavaMail.geo-discussion-forums@prfg19>
	<20110522190650.5B92F3A402D@sparrow.telecommunity.com>
Message-ID: <BANLkTinAMr1SB5WXK5ra6h3-PNOvAQRGdQ@mail.gmail.com>

On Sun, May 22, 2011 at 21:06, P.J. Eby <pje at telecommunity.com> wrote:
> So, all the hype was pretty much just that: hype and FUD-slinging.

Stop! We are tired of reading your perpetual whining.


-- 
Sebastien Douche <sdouche at gmail.com>
Twitter: @sdouche (agile, lean, python, git, open source)

From dstanek at dstanek.com  Mon May 23 02:49:07 2011
From: dstanek at dstanek.com (David Stanek)
Date: Sun, 22 May 2011 20:49:07 -0400
Subject: [Distutils] distribute's sandboxing doesn't preserve
 working_set; leads to setup_requires problems
In-Reply-To: <20110522190650.5B92F3A402D@sparrow.telecommunity.com>
References: <20110519204713.907A83A4061@sparrow.telecommunity.com>
	<26366060.2524.1306088901251.JavaMail.geo-discussion-forums@prfg19>
	<20110522190650.5B92F3A402D@sparrow.telecommunity.com>
Message-ID: <BANLkTinnQ2B0THWZSM+aH=5xPSo-pbHEgg@mail.gmail.com>

On Sun, May 22, 2011 at 3:06 PM, P.J. Eby <pje at telecommunity.com> wrote:

>
> Not really.  Unless you're using Python 3, or you want different default
> options from setuptools, there's little advantage to using distribute.  (It
> also includes bugs that setuptools does not.)
>
>
I agree. I spent a significant amount of time trying to figure out what I
should be using only to circle back to setuptools.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110522/9e7f533b/attachment.html>

From ziade.tarek at gmail.com  Thu May 26 12:29:39 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 26 May 2011 12:29:39 +0200
Subject: [Distutils] Distribute 0.6.17 incoming
Message-ID: <BANLkTinOYwzeMVprydTi3zf+Ui3kv0YuGQ@mail.gmail.com>

Hi

I am going to release 0.6.17 this week-end, with a few fixes, most
important ones:

1 - python 3.2.1 compat
2 - "ValueError: invalid literal for int() with base 10" during
download -  https://bitbucket.org/tarek/distribute/issue/196
3 - pkg_resources sandboxing issue -
https://bitbucket.org/tarek/distribute/issue/205

If you see anything that you'd like to be fixed in this release,
please point me a bug or a patch today or tomorrow.

Cheers
Tarek

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

From justrandombytes at gmail.com  Sun May 29 01:42:03 2011
From: justrandombytes at gmail.com (James)
Date: Sat, 28 May 2011 16:42:03 -0700
Subject: [Distutils] windows setuptools.exe
Message-ID: <BANLkTik1iEg4aR-BkURgNAW=M+6SL0E7GA@mail.gmail.com>

I just tried to download and run the python2.5 0.6c11 setuptools and I get a
message that there is no record of python in the registry and the install
cannot proceed. Annoyingly there are two empty text boxes that look like one
might be able to type a path in but they are disabled.

 This is on Windows 7 x64, I'm wondering if the binary is looking into the
32 bit registry? The
standard HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.5 entries are all
there (in the 64 bit registry)

Any ideas how to proceed?

Cheers,
  - James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110528/6c8dc6fb/attachment.html>

From ziade.tarek at gmail.com  Mon May 30 18:06:29 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 30 May 2011 18:06:29 +0200
Subject: [Distutils] Distribute 0.6.17
Message-ID: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>

Hello

I've pushed 0.6.17, which fixes the Python 3.2.1 compat' and a few
bugs. Thanks to the people involved in this release.

If you have any issue with this release, or want to see a particular
problem fixed in the next one, let me know


Cheers
Tarek

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

From skippy.hammond at gmail.com  Tue May 31 03:48:44 2011
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 31 May 2011 11:48:44 +1000
Subject: [Distutils] windows setuptools.exe
In-Reply-To: <BANLkTik1iEg4aR-BkURgNAW=M+6SL0E7GA@mail.gmail.com>
References: <BANLkTik1iEg4aR-BkURgNAW=M+6SL0E7GA@mail.gmail.com>
Message-ID: <4DE448FC.5030800@gmail.com>

On 29/05/2011 9:42 AM, James wrote:
> I just tried to download and run the python2.5 0.6c11 setuptools and I
> get a message that there is no record of python in the registry and the
> install cannot proceed. Annoyingly there are two empty text boxes that
> look like one might be able to type a path in but they are disabled.
>
>   This is on Windows 7 x64, I'm wondering if the binary is looking into
> the 32 bit registry?

A 32-bit binary will be looking in the 32bit registry, as intended. 
Assuming you don't have a 64bit Python 2.5, then your registry entries 
should also be in the 32bit registry.  If you have grabbed the 64bit 
version of Python 2.5, then you are unlikely to find a corresponding 
64bit installer for setuptools as making 64bit extensions with 2.5 was 
incredibly painful - you might be better off looking at 2.6...

HTH,

Mark

From justrandombytes at gmail.com  Tue May 31 08:21:56 2011
From: justrandombytes at gmail.com (James)
Date: Mon, 30 May 2011 23:21:56 -0700
Subject: [Distutils] windows setuptools.exe
In-Reply-To: <4DE448FC.5030800@gmail.com>
References: <BANLkTik1iEg4aR-BkURgNAW=M+6SL0E7GA@mail.gmail.com>
	<4DE448FC.5030800@gmail.com>
Message-ID: <BANLkTikA4C-bTxB7HjCBUp+SuFYfBwD1Yw@mail.gmail.com>

On Mon, May 30, 2011 at 6:48 PM, Mark Hammond <skippy.hammond at gmail.com>wrote:

> On 29/05/2011 9:42 AM, James wrote:
>
>> I just tried to download and run the python2.5 0.6c11 setuptools and I
>> get a message that there is no record of python in the registry and the
>> install cannot proceed.
>
> A 32-bit binary will be looking in the 32bit registry, as intended.
> Assuming you don't have a 64bit Python 2.5, then your registry entries
> should also be in the 32bit registry.  If you have grabbed the 64bit version
> of Python 2.5, then you are unlikely to find a corresponding 64bit installer
> for setuptools as making 64bit extensions with 2.5 was incredibly painful -
> you might be better off looking at 2.6...
>
> HTH,
>
> Mark
>

Maybe I was taking the "easy" part a little too literal for my own good ;) I
thought, wow, that's cool, someone went to the trouble of making one
installer for both 32 and 64 bit. Not that I understand (or want to) what
the installer does but it seemed plausible at the time.

 I arrived  here http://pypi.python.org/pypi/setuptools#id8 from the sphinx
page, there seems to be only a link to one (presumably 32 bit only)
installer for each 2.x python :( Spelunking around in
http://pypi.python.org/packages/ <http://pypi.python.org/packages/2.6/> didn't
get me anywhere either (looking in the 2.6 or 2.7 dirs)

Didn't see any "not-so-easy how to build/install this on x64" notes either.
Can someone point me to that if there is such a thing? If there is no such
thing can someone please let me out of my misery?

thanks,
 - James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110530/348b76c7/attachment.html>

From agroszer.ll at gmail.com  Tue May 31 08:39:48 2011
From: agroszer.ll at gmail.com (Adam GROSZER)
Date: Tue, 31 May 2011 08:39:48 +0200
Subject: [Distutils] windows setuptools.exe
In-Reply-To: <BANLkTikA4C-bTxB7HjCBUp+SuFYfBwD1Yw@mail.gmail.com>
References: <BANLkTik1iEg4aR-BkURgNAW=M+6SL0E7GA@mail.gmail.com>	<4DE448FC.5030800@gmail.com>
	<BANLkTikA4C-bTxB7HjCBUp+SuFYfBwD1Yw@mail.gmail.com>
Message-ID: <4DE48D34.4030303@gmail.com>

On 05/31/2011 08:21 AM, James wrote:
>
>
> Didn't see any "not-so-easy how to build/install this on x64" notes
> either. Can someone point me to that if there is such a thing? If there
> is no such thing can someone please let me out of my misery?

Download the source setuptools-0.6c11.tar.gz, extract it, run
python setup.py install
where python is your 64bit python.

-- 
Best regards,
  Adam GROSZER
--
Quote of the day:
Our deeds determine us, as much as we determine our deeds.
- George Elliot

From m.van.rees at zestsoftware.nl  Tue May 31 11:50:09 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 31 May 2011 11:50:09 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
Message-ID: <is2dkh$6vl$1@dough.gmane.org>

Op 30-05-11 18:06, Tarek Ziad? schreef:
> Hello
>
> I've pushed 0.6.17, which fixes the Python 3.2.1 compat' and a few
> bugs. Thanks to the people involved in this release.
>
> If you have any issue with this release, or want to see a particular
> problem fixed in the next one, let me know

When I try to use this in a Plone buildout, I cannot start my Zope 
instance anymore.  Works fine when I revert to 0.6.16.

This is with zc.buildout 1.4.3 or 1.4.4, Plone 3.3.5 (+python2.4) or 
Plone 4.0.6.1 (with python2.6).

The buildout (created with either the plone3_buildout or plone4_buildout 
templates from ZopeSkel, or a client buildout that has worked fine for 
the past year) finished successfully.  Starting the zope instance on the 
foreground fails with an ImportError; for example this one, but I have 
seen others:

Traceback (most recent call last):
   File 
"/Users/mauritsvanrees/zopes/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py", 
line 709, in import_product
     product=__import__(pname, global_dict, global_dict, silly)
   File 
"/Users/mauritsvanrees/shared-eggs/Products.ATContentTypes-1.3.4-py2.4.egg/Products/ATContentTypes/__init__.py", 
line 64, in ?
     import Products.ATContentTypes.content
   File 
"/Users/mauritsvanrees/shared-eggs/Products.ATContentTypes-1.3.4-py2.4.egg/Products/ATContentTypes/content/__init__.py", 
line 26, in ?
     import Products.ATContentTypes.content.link
   File 
"/Users/mauritsvanrees/shared-eggs/Products.ATContentTypes-1.3.4-py2.4.egg/Products/ATContentTypes/content/link.py", 
line 39, in ?
     from Products.ATContentTypes.content.base import registerATCT
   File 
"/Users/mauritsvanrees/shared-eggs/Products.ATContentTypes-1.3.4-py2.4.egg/Products/ATContentTypes/content/base.py", 
line 63, in ?
     from Products.CMFPlone.PloneFolder import ReplaceableWrapper
   File 
"/Users/mauritsvanrees/shared-eggs/Plone-3.3.4-py2.4.egg/Products/CMFPlone/__init__.py", 
line 215, in ?
     from browser import ploneview
   File 
"/Users/mauritsvanrees/shared-eggs/Plone-3.3.4-py2.4.egg/Products/CMFPlone/browser/ploneview.py", 
line 12, in ?
     from Products.CMFPlone import utils
ImportError: cannot import name utils

When I go in with a pdb in this utils.py everything seems fine but then 
the import error just happens a bit further on, failing to import 
plone.app.layout.  On Plone 4 an import of Shared.DC.ZRDB.Search fails. 
  Again, with distribute 0.6.16 it works fine.

This is on Mac OS X.  Possibly I have strange ways of installing python, 
but it has worked fine so far.  Can anyone else reproduce this?


-- 
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/


From ziade.tarek at gmail.com  Tue May 31 12:04:35 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 31 May 2011 12:04:35 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <is2dkh$6vl$1@dough.gmane.org>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
	<is2dkh$6vl$1@dough.gmane.org>
Message-ID: <BANLkTikWntMuM5Y8d7sTFOrmY_qDDeY1ww@mail.gmail.com>

On Tue, May 31, 2011 at 11:50 AM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
...
> ImportError: cannot import name utils
>
> When I go in with a pdb in this utils.py everything seems fine but then the
> import error just happens a bit further on, failing to import
> plone.app.layout. ?On Plone 4 an import of Shared.DC.ZRDB.Search fails.
> ?Again, with distribute 0.6.16 it works fine.
>
> This is on Mac OS X. ?Possibly I have strange ways of installing python, but
> it has worked fine so far. ?Can anyone else reproduce this?

Could you dump and compare sys.path in both cases ? thanks


>
>
> --
> Maurits van Rees
> Web App Programmer at Zest Software: http://zestsoftware.nl
> Personal website: http://maurits.vanrees.org/
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From m.van.rees at zestsoftware.nl  Tue May 31 12:29:41 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 31 May 2011 12:29:41 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <BANLkTikWntMuM5Y8d7sTFOrmY_qDDeY1ww@mail.gmail.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>	<is2dkh$6vl$1@dough.gmane.org>
	<BANLkTikWntMuM5Y8d7sTFOrmY_qDDeY1ww@mail.gmail.com>
Message-ID: <is2ful$keq$1@dough.gmane.org>

Op 31-05-11 12:04, Tarek Ziad? schreef:
> On Tue, May 31, 2011 at 11:50 AM, Maurits van Rees
> <m.van.rees at zestsoftware.nl>  wrote:
> ....
>> ImportError: cannot import name utils
>>
>> When I go in with a pdb in this utils.py everything seems fine but then the
>> import error just happens a bit further on, failing to import
>> plone.app.layout.  On Plone 4 an import of Shared.DC.ZRDB.Search fails.
>>   Again, with distribute 0.6.16 it works fine.
>>
>> This is on Mac OS X.  Possibly I have strange ways of installing python, but
>> it has worked fine so far.  Can anyone else reproduce this?
>
> Could you dump and compare sys.path in both cases ? thanks

The only difference in both bin/buildout and bin/instance is the 
distribute version.  I will paste the scripts with 0.6.17 below for good 
measure (Plone 4 buildout in this case).

bin/buildout:
======================================================================
#!/Users/mauritsvanrees/envs/py26/bin/python2.6

import sys
sys.path[0:0] = [
   '/Users/mauritsvanrees/shared-eggs/zc.buildout-1.4.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/distribute-0.6.17-py2.6.egg',
   ]

import zc.buildout.buildout

if __name__ == '__main__':
     zc.buildout.buildout.main()
======================================================================


bin/instance:
======================================================================
#!/Users/mauritsvanrees/envs/py26/bin/python2.6

import sys
sys.path[0:0] = [
   '/Users/mauritsvanrees/shared-eggs/Plone-4.0.6-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.recipe.zope2instance-4.1.5-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Zope2-2.12.18-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zc.recipe.egg-1.2.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/mailinglogger-3.3.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/distribute-0.6.17-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zc.buildout-1.4.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.tales-3.4.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.tal-3.5.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.structuredtext-3.4.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.site-3.6.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.publisher-3.8.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.pagetemplate-3.5.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.location-3.6.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.interface-3.5.3-py2.6-macosx-10.6-x86_64.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.i18nmessageid-3.5.3-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.i18n-3.7.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.event-3.4.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.dottedname-3.4.6-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.deprecation-3.4.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.deferredimport-3.5.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.component-3.7.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.publication-3.8.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.locales-3.6.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.container-3.8.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/z3c.autoinclude-0.3.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/wicked-1.1.9-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/transaction-1.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plonetheme.sunburst-1.0.6-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plonetheme.classic-1.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.portlet.static-2.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.portlet.collection-2.0.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.theme-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.session-3.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.protect-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.portlets-2.0.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.openid-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.memoize-1.1.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.locking-2.0.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.intelligenttext-2.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.indexer-1.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.i18n-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.fieldsets-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.contentrules-2.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.browserlayer-2.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.workflow-2.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.vocabularies-2.0.3-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.viewletmanager-2.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.upgrade-1.0.6-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.users-1.0.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.redirector-1.1.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.portlets-2.0.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.openid-2.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.locales-4.0.7-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.linkintegrity-1.3.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.layout-2.0.9-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.kss-1.6.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.jquerytools-1.1.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.iterate-2.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.i18n-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.form-2.0.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.folder-1.0.3-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.customerize-1.2.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.controlpanel-2.0.6-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.contentrules-2.0.6-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.content-2.0.6-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/plone.app.contentmenu-2.0.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.blob-1.5-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/kss.core-1.6.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/five.customerize-1.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/five.localsitemanager-2.0.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/borg.localrole-3.0.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/archetypes.referencebrowserwidget-2.4.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/archetypes.kss-1.6.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/ZODB3-3.9.5-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.TinyMCE-1.1.10-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.statusmessages-4.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.ResourceRegistries-2.0.4-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.PortalTransforms-2.0.5-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.PluginRegistry-1.3b1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.PluggableAuthService-1.7.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.PlonePAS-4.0.7-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.PloneLanguageTool-3.0.8-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.PlacelessTranslationService-2.0.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.PasswordResetTool-2.0.5-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.MimetypesRegistry-2.0.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.GenericSetup-1.6.3-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.ExternalEditor-1.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.ExtendedPathIndex-2.9-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.DCWorkflow-2.2.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.CMFUid-2.2.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.CMFQuickInstallerTool-3.0.5-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.CMFPlacefulWorkflow-1.5.4-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.CMFFormController-3.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.CMFEditions-2.0.7-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.CMFDynamicViewFTI-4.0.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.CMFDiffTool-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.CMFDefault-2.2.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.CMFCore-2.2.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.CMFCalendar-2.2.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.CMFActionIcons-2.1.3-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.ATContentTypes-2.0.7-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.Archetypes-1.6.6-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.kupu-1.4.17-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/ExtensionClass-2.13.2-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/DateTime-2.12.6-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Acquisition-2.13.7-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.schema-3.5.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.publisher-3.8.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.viewlet-3.6.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.traversing-3.7.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.testing-3.9.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.testbrowser-3.6.0a2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.size-3.4.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.sequencesort-3.4.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.sendmail-3.5.3-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.security-3.7.4-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.schema-3.5.4-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.proxy-3.6.1-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.processlifetime-1.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.mkzeoinstance-3.9.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.lifecycleevent-3.6.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.exceptions-3.5.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.contenttype-3.4.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.contentprovider-3.5.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.container-3.8.2-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.configuration-3.6.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zLOG-2.11.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zdaemon-2.0.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/tempstorage-2.11.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/pytz-2011e-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/initgroups-2.13.0-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/five.formlib-1.0.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/docutils-0.7-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/ZopeUndo-2.12.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/ZConfig-2.7.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/ThreadLock-2.13.0-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/RestrictedPython-3.5.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Record-2.13.0-py2.6-macosx-10.6-x86_64.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.ZSQLMethods-2.13.3-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Persistence-2.13.2-py2.6-macosx-10.6-x86_64.egg',
 
'/Users/mauritsvanrees/shared-eggs/MultiMapping-2.13.0-py2.6-macosx-10.6-x86_64.egg',
 
'/Users/mauritsvanrees/shared-eggs/Missing-2.13.1-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.annotation-3.5.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.browser-1.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.authentication-3.7.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.copy-3.5.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.error-3.6.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.dublincore-3.4.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.copypastemove-3.5.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.formlib-3.7.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.keyring-2.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/python_openid-2.2.5-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.ramcache-1.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Unidecode-0.04.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.componentvocabulary-1.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.form-3.8.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.SecureMailHost-1.1.2-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.contentmigration-2.0.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.component-3.8.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.cache-3.6.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/feedparser-4.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.CMFPlone-4.0b1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.folder-1.0.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.cachedescriptors-3.5.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.stringinterp-1.0.4-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.scale-1.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/plone.app.imaging-1.0.5-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/archetypes.schemaextender-2.0.3-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.app.pagetemplate-3.7.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.folder-3.5.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.datetime-3.4.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zc.lockfile-1.0.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/elementtree-1.2.7_20070827_preview-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Markdown-2.0.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/python_gettext-1.1.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.PloneTestCase-0.9.12-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.ZopeVersionControl-1.1.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.validation-2.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.ATReferenceBrowserWidget-3.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/Products.Marshall-2.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/Products.CMFTestCase-0.9.11-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.testing-3.7.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/mechanize-0.1.11-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/ClientForm-0.2.10-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.broken-3.6.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.filerepresentation-3.5.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.hookable-3.4.1-py2.6-macosx-10.6-x86_64.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.basicskin-3.4.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.security-3.7.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.content-3.4.0-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.app.authentication-3.6.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/unittest2-0.5.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.password-3.5.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.dependable-3.4.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.debug-3.4.1-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.appsetup-3.11-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.securitypolicy-3.6.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.principalregistry-3.7.1-py2.6.egg',
 
'/Users/mauritsvanrees/shared-eggs/zope.app.localpermission-3.7.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.app.interface-3.5.2-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.session-3.9.3-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zodbcode-3.4.0-py2.6.egg',
   '/Users/mauritsvanrees/shared-eggs/zope.minmax-1.1.2-py2.6.egg',
   ]

import plone.recipe.zope2instance.ctl

if __name__ == '__main__':
     plone.recipe.zope2instance.ctl.main(
         ["-C", '/Users/mauritsvanrees/tmp/p4/parts/instance/etc/zope.conf']
         + sys.argv[1:])
======================================================================



-- 
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/


From eric at trueblade.com  Tue May 31 12:33:59 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 31 May 2011 06:33:59 -0400
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <is2dkh$6vl$1@dough.gmane.org>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
	<is2dkh$6vl$1@dough.gmane.org>
Message-ID: <4DE4C417.4060800@trueblade.com>

On 5/31/2011 5:50 AM, Maurits van Rees wrote:

> When I go in with a pdb in this utils.py everything seems fine but then
> the import error just happens a bit further on, failing to import
> plone.app.layout.  On Plone 4 an import of Shared.DC.ZRDB.Search fails.
>  Again, with distribute 0.6.16 it works fine.
> 
> This is on Mac OS X.  Possibly I have strange ways of installing python,
> but it has worked fine so far.  Can anyone else reproduce this?

I had this same error (on import of Shared.DC.ZRDB.Search) with 0.6.17
and Plone 4.1rc2. Reverting to 0.6.16 fixed that problem (although I had
upgraded to 0.6.17 in an effort to fix a seemingly unrelated issue).

This is on Fedora 8.

Eric.

From ziade.tarek at gmail.com  Tue May 31 12:36:38 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 31 May 2011 12:36:38 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <is2ful$keq$1@dough.gmane.org>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
	<is2dkh$6vl$1@dough.gmane.org>
	<BANLkTikWntMuM5Y8d7sTFOrmY_qDDeY1ww@mail.gmail.com>
	<is2ful$keq$1@dough.gmane.org>
Message-ID: <BANLkTinObpvnQ-VADOkJv=bL7RoFo+qxnw@mail.gmail.com>

On Tue, May 31, 2011 at 12:29 PM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> Op 31-05-11 12:04, Tarek Ziad? schreef:
>>
>> On Tue, May 31, 2011 at 11:50 AM, Maurits van Rees
>> <m.van.rees at zestsoftware.nl> ?wrote:
>> ....
>>>
>>> ImportError: cannot import name utils
>>>
>>> When I go in with a pdb in this utils.py everything seems fine but then
>>> the
>>> import error just happens a bit further on, failing to import
>>> plone.app.layout. ?On Plone 4 an import of Shared.DC.ZRDB.Search fails.
>>> ?Again, with distribute 0.6.16 it works fine.
>>>
>>> This is on Mac OS X. ?Possibly I have strange ways of installing python,
>>> but
>>> it has worked fine so far. ?Can anyone else reproduce this?
>>
>> Could you dump and compare sys.path in both cases ? thanks
>
> The only difference in both bin/buildout and bin/instance is the distribute
> version. ?I will paste the scripts with 0.6.17 below for good measure (Plone
> 4 buildout in this case).

I was talking about the value of sys,path right before the import that
fails to check if there's any difference besides the distribute
version.

The scripts you are showing are inserting entries in the beginning of sys.path


Cheers
Tarek

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

From ziade.tarek at gmail.com  Tue May 31 12:40:05 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 31 May 2011 12:40:05 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <4DE4C417.4060800@trueblade.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
	<is2dkh$6vl$1@dough.gmane.org> <4DE4C417.4060800@trueblade.com>
Message-ID: <BANLkTinKQXVU6qYLp8mQD8guu+XYtMvbog@mail.gmail.com>

On Tue, May 31, 2011 at 12:33 PM, Eric Smith <eric at trueblade.com> wrote:
> On 5/31/2011 5:50 AM, Maurits van Rees wrote:
>
>> When I go in with a pdb in this utils.py everything seems fine but then
>> the import error just happens a bit further on, failing to import
>> plone.app.layout. ?On Plone 4 an import of Shared.DC.ZRDB.Search fails.
>> ?Again, with distribute 0.6.16 it works fine.
>>
>> This is on Mac OS X. ?Possibly I have strange ways of installing python,
>> but it has worked fine so far. ?Can anyone else reproduce this?
>
> I had this same error (on import of Shared.DC.ZRDB.Search) with 0.6.17
> and Plone 4.1rc2. Reverting to 0.6.16 fixed that problem (although I had
> upgraded to 0.6.17 in an effort to fix a seemingly unrelated issue).
>
> This is on Fedora 8.
>

I added a bug here: https://bitbucket.org/tarek/distribute/issue/210

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



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

From ziade.tarek at gmail.com  Tue May 31 12:43:09 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 31 May 2011 12:43:09 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <BANLkTinKQXVU6qYLp8mQD8guu+XYtMvbog@mail.gmail.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
	<is2dkh$6vl$1@dough.gmane.org> <4DE4C417.4060800@trueblade.com>
	<BANLkTinKQXVU6qYLp8mQD8guu+XYtMvbog@mail.gmail.com>
Message-ID: <BANLkTikzipM7tgjz8AshD4ZR2kNREpHyVw@mail.gmail.com>

I think this regression could be related to this change:

  https://bitbucket.org/tarek/distribute/changeset/a3f0d30e94c2

Would you mind trying to revert this change in your environment to see
if the problem goes away ?


Thanks

On Tue, May 31, 2011 at 12:40 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Tue, May 31, 2011 at 12:33 PM, Eric Smith <eric at trueblade.com> wrote:
>> On 5/31/2011 5:50 AM, Maurits van Rees wrote:
>>
>>> When I go in with a pdb in this utils.py everything seems fine but then
>>> the import error just happens a bit further on, failing to import
>>> plone.app.layout. ?On Plone 4 an import of Shared.DC.ZRDB.Search fails.
>>> ?Again, with distribute 0.6.16 it works fine.
>>>
>>> This is on Mac OS X. ?Possibly I have strange ways of installing python,
>>> but it has worked fine so far. ?Can anyone else reproduce this?
>>
>> I had this same error (on import of Shared.DC.ZRDB.Search) with 0.6.17
>> and Plone 4.1rc2. Reverting to 0.6.16 fixed that problem (although I had
>> upgraded to 0.6.17 in an effort to fix a seemingly unrelated issue).
>>
>> This is on Fedora 8.
>>
>
> I added a bug here: https://bitbucket.org/tarek/distribute/issue/210
>
>> Eric.
>> _______________________________________________
>> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
>
> --
> Tarek Ziad? | http://ziade.org
>



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

From m.van.rees at zestsoftware.nl  Tue May 31 12:46:50 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 31 May 2011 12:46:50 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <BANLkTinObpvnQ-VADOkJv=bL7RoFo+qxnw@mail.gmail.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>	<is2dkh$6vl$1@dough.gmane.org>	<BANLkTikWntMuM5Y8d7sTFOrmY_qDDeY1ww@mail.gmail.com>	<is2ful$keq$1@dough.gmane.org>
	<BANLkTinObpvnQ-VADOkJv=bL7RoFo+qxnw@mail.gmail.com>
Message-ID: <is2guq$pso$1@dough.gmane.org>

Op 31-05-11 12:36, Tarek Ziad? schreef:
> On Tue, May 31, 2011 at 12:29 PM, Maurits van Rees
> <m.van.rees at zestsoftware.nl>  wrote:
>> Op 31-05-11 12:04, Tarek Ziad? schreef:
>>>
>>> On Tue, May 31, 2011 at 11:50 AM, Maurits van Rees
>>> <m.van.rees at zestsoftware.nl>    wrote:
>>> ....
>>>>
>>>> ImportError: cannot import name utils
>>>>
>>>> When I go in with a pdb in this utils.py everything seems fine but then
>>>> the
>>>> import error just happens a bit further on, failing to import
>>>> plone.app.layout.  On Plone 4 an import of Shared.DC.ZRDB.Search fails.
>>>>   Again, with distribute 0.6.16 it works fine.
>>>>
>>>> This is on Mac OS X.  Possibly I have strange ways of installing python,
>>>> but
>>>> it has worked fine so far.  Can anyone else reproduce this?
>>>
>>> Could you dump and compare sys.path in both cases ? thanks
>>
>> The only difference in both bin/buildout and bin/instance is the distribute
>> version.  I will paste the scripts with 0.6.17 below for good measure (Plone
>> 4 buildout in this case).
>
> I was talking about the value of sys,path right before the import that
> fails to check if there's any difference besides the distribute
> version.
>
> The scripts you are showing are inserting entries in the beginning of sys.path
>
>
> Cheers
> Tarek
>

Ah, right.  No, no differences in the sys.path except the distribute 
version.


Here is the last part of the sys.path:

  '/Users/mauritsvanrees/shared-eggs/zope.minmax-1.1.2-py2.6.egg',
  '/Users/mauritsvanrees/tmp/p4/bin',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/site-packages/pip-0.7.2-py2.6.egg',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/site-packages/PILwoTk-1.1.6.4-py2.6-macosx-10.6-x86_64.egg',
  '/Users/mauritsvanrees/envs/py26/lib/python26.zip',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/plat-darwin',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/plat-mac',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/plat-mac/lib-scriptpackages',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/lib-tk',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/lib-old',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/lib-dynload',
  '/Users/mauritsvanrees/buildout/python/parts/opt/lib/python2.6',
 
'/Users/mauritsvanrees/buildout/python/parts/opt/lib/python2.6/plat-darwin',
  '/Users/mauritsvanrees/buildout/python/parts/opt/lib/python2.6/lib-tk',
  '/Users/mauritsvanrees/buildout/python/parts/opt/lib/python2.6/plat-mac',
 
'/Users/mauritsvanrees/buildout/python/parts/opt/lib/python2.6/plat-mac/lib-scriptpackages',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/site-packages',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info',
 
'/Users/mauritsvanrees/buildout/python/parts/opt/lib/python2.6/site-packages',
  '/Users/mauritsvanrees/envs/py26/lib/python26.zip',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/plat-darwin',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/plat-mac',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/plat-mac/lib-scriptpackages',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/lib-tk',
  '/Users/mauritsvanrees/envs/py26/lib/python2.6/lib-old',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info',
 
'/Users/mauritsvanrees/envs/py26/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info']


-- 
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/


From m.van.rees at zestsoftware.nl  Tue May 31 13:43:02 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 31 May 2011 13:43:02 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <BANLkTikzipM7tgjz8AshD4ZR2kNREpHyVw@mail.gmail.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>	<is2dkh$6vl$1@dough.gmane.org>
	<4DE4C417.4060800@trueblade.com>	<BANLkTinKQXVU6qYLp8mQD8guu+XYtMvbog@mail.gmail.com>
	<BANLkTikzipM7tgjz8AshD4ZR2kNREpHyVw@mail.gmail.com>
Message-ID: <is2k86$duv$1@dough.gmane.org>

Op 31-05-11 12:43, Tarek Ziad? schreef:
> I think this regression could be related to this change:
>
>    https://bitbucket.org/tarek/distribute/changeset/a3f0d30e94c2
>
> Would you mind trying to revert this change in your environment to see
> if the problem goes away ?

Bingo: going back to the revision before this changeset solves it for me.


-- 
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/


From ziade.tarek at gmail.com  Tue May 31 13:46:29 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 31 May 2011 13:46:29 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <is2k86$duv$1@dough.gmane.org>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
	<is2dkh$6vl$1@dough.gmane.org> <4DE4C417.4060800@trueblade.com>
	<BANLkTinKQXVU6qYLp8mQD8guu+XYtMvbog@mail.gmail.com>
	<BANLkTikzipM7tgjz8AshD4ZR2kNREpHyVw@mail.gmail.com>
	<is2k86$duv$1@dough.gmane.org>
Message-ID: <BANLkTi=LyGHZ9kyaNDRBZeUSrGFY4FrmGw@mail.gmail.com>

On Tue, May 31, 2011 at 1:43 PM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> Op 31-05-11 12:43, Tarek Ziad? schreef:
>>
>> I think this regression could be related to this change:
>>
>> ? https://bitbucket.org/tarek/distribute/changeset/a3f0d30e94c2
>>
>> Would you mind trying to revert this change in your environment to see
>> if the problem goes away ?
>
> Bingo: going back to the revision before this changeset solves it for me.

Alright, I've asked Aurelien to look at this, so his bugfix does not do this.

We will push the next version asap

>
> --
> Maurits van Rees
> Web App Programmer at Zest Software: http://zestsoftware.nl
> Personal website: http://maurits.vanrees.org/
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From m.van.rees at zestsoftware.nl  Tue May 31 13:51:53 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 31 May 2011 13:51:53 +0200
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <BANLkTi=LyGHZ9kyaNDRBZeUSrGFY4FrmGw@mail.gmail.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>	<is2dkh$6vl$1@dough.gmane.org>
	<4DE4C417.4060800@trueblade.com>	<BANLkTinKQXVU6qYLp8mQD8guu+XYtMvbog@mail.gmail.com>	<BANLkTikzipM7tgjz8AshD4ZR2kNREpHyVw@mail.gmail.com>	<is2k86$duv$1@dough.gmane.org>
	<BANLkTi=LyGHZ9kyaNDRBZeUSrGFY4FrmGw@mail.gmail.com>
Message-ID: <is2kop$h0u$1@dough.gmane.org>

Op 31-05-11 13:46, Tarek Ziad? schreef:
> On Tue, May 31, 2011 at 1:43 PM, Maurits van Rees
> <m.van.rees at zestsoftware.nl>  wrote:
>> Op 31-05-11 12:43, Tarek Ziad? schreef:
>>>
>>> I think this regression could be related to this change:
>>>
>>>    https://bitbucket.org/tarek/distribute/changeset/a3f0d30e94c2
>>>
>>> Would you mind trying to revert this change in your environment to see
>>> if the problem goes away ?
>>
>> Bingo: going back to the revision before this changeset solves it for me.
>
> Alright, I've asked Aurelien to look at this, so his bugfix does not do this.
>
> We will push the next version asap

Thanks for the quick follow-up.


-- 
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/


From eric at trueblade.com  Tue May 31 13:55:16 2011
From: eric at trueblade.com (Eric Smith)
Date: Tue, 31 May 2011 07:55:16 -0400
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <is2k86$duv$1@dough.gmane.org>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>	<is2dkh$6vl$1@dough.gmane.org>	<4DE4C417.4060800@trueblade.com>	<BANLkTinKQXVU6qYLp8mQD8guu+XYtMvbog@mail.gmail.com>	<BANLkTikzipM7tgjz8AshD4ZR2kNREpHyVw@mail.gmail.com>
	<is2k86$duv$1@dough.gmane.org>
Message-ID: <4DE4D724.7020401@trueblade.com>

On 5/31/2011 7:43 AM, Maurits van Rees wrote:
> Op 31-05-11 12:43, Tarek Ziad? schreef:
>> I think this regression could be related to this change:
>>
>>    https://bitbucket.org/tarek/distribute/changeset/a3f0d30e94c2
>>
>> Would you mind trying to revert this change in your environment to see
>> if the problem goes away ?
> 
> Bingo: going back to the revision before this changeset solves it for me.

Same here: reverting that change fixes the problem with importing
Shared.DC.ZRDB.Search.

From eucci.group at gmail.com  Tue May 31 21:40:10 2011
From: eucci.group at gmail.com (Jeff Shell)
Date: Tue, 31 May 2011 13:40:10 -0600
Subject: [Distutils] Distribute 0.6.17
In-Reply-To: <BANLkTikWntMuM5Y8d7sTFOrmY_qDDeY1ww@mail.gmail.com>
References: <BANLkTimBYeWfyyDNCYXV=PXsK_VVYNVzTg@mail.gmail.com>
	<is2dkh$6vl$1@dough.gmane.org>
	<BANLkTikWntMuM5Y8d7sTFOrmY_qDDeY1ww@mail.gmail.com>
Message-ID: <BANLkTi=AC4bWJrVpnZA7eYTAyP7ZKwdqtA@mail.gmail.com>

I've seen the same issue in Mac OS X with namespace packages that are
more than one level deep. 'zope.server' works fine, 'zope.app.server'
(or any other 'zope.app.*') blows up. Works fine with distribute
0.6.16, blows up with 0.6.17.

On Tue, May 31, 2011 at 4:04 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Tue, May 31, 2011 at 11:50 AM, Maurits van Rees
> <m.van.rees at zestsoftware.nl> wrote:
> ...
>> ImportError: cannot import name utils
>>
>> When I go in with a pdb in this utils.py everything seems fine but then the
>> import error just happens a bit further on, failing to import
>> plone.app.layout. ?On Plone 4 an import of Shared.DC.ZRDB.Search fails.
>> ?Again, with distribute 0.6.16 it works fine.
>>
>> This is on Mac OS X. ?Possibly I have strange ways of installing python, but
>> it has worked fine so far. ?Can anyone else reproduce this?
>
> Could you dump and compare sys.path in both cases ? thanks

-- 
Jeff Shell

From pje at telecommunity.com  Tue May 31 21:35:40 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 31 May 2011 15:35:40 -0400
Subject: [Distutils] windows setuptools.exe
In-Reply-To: <BANLkTikA4C-bTxB7HjCBUp+SuFYfBwD1Yw@mail.gmail.com>
References: <BANLkTik1iEg4aR-BkURgNAW=M+6SL0E7GA@mail.gmail.com>
	<4DE448FC.5030800@gmail.com>
	<BANLkTikA4C-bTxB7HjCBUp+SuFYfBwD1Yw@mail.gmail.com>
Message-ID: <20110531193551.471E93A4100@sparrow.telecommunity.com>

At 11:21 PM 5/30/2011 -0700, James wrote:
>Didn't see any "not-so-easy how to build/install this on x64" notes 
>either. Can someone point me to that if there is such a thing? If 
>there is no such thing can someone please let me out of my misery?

I've updated the PyPI page to note the problem prominently under the 
Windows instructions, and included a workaround.  Sorry for the inconvenience.


From anton.panasenko at gmail.com  Mon May 30 21:13:46 2011
From: anton.panasenko at gmail.com (Anton Panasenko)
Date: Mon, 30 May 2011 23:13:46 +0400
Subject: [Distutils] [buildout] [Errno 104] Connection reset by peer
Message-ID: <45760E6A-E3D0-47AD-B975-EA4D28FCEB9C@gmail.com>

Hi guys, 

Who knows how to fix the problem: 

Download error: [Errno 104] Connection reset by peer -- Some packages may not be found! 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110530/7b82bf21/attachment.html>

From dtcaciuc at gmail.com  Fri May 27 19:08:20 2011
From: dtcaciuc at gmail.com (Dimitri Tcaciuc)
Date: Fri, 27 May 2011 10:08:20 -0700 (PDT)
Subject: [Distutils] Using build products instead of the source package
	during development
Message-ID: <aef81d74-263a-4f63-9d4f-21816c1c9c7c@x38g2000pri.googlegroups.com>

Hello everyone,

I have a project with a python package and a compiled component inside
of it. Current directory layout is:

    <project>
      foo/
      foo/__init__.py
      foo/...

      src/
      src/c_foo.c

      tests/
      tests/test_foo.py

      setup.py

When the project is built, distutils create a `build/lib` directory
which I either add to `PYTHONPATH` or install into a virtual
environment. Resulting structure is the following:

    <project>
      build/lib
      build/lib/foo/__init__.py
      build/lib/foo/c_foo.so


The issue with that is that if I start a python interpreter session
from the project root, run tests from the project root etc., it picks
up the source tree instead of the built tree. This is a problem
because in that case the compiled extensions are not found since they
reside with build products.

I found several existing solutions to this in use:

1. Place python sources under a separate directory, eg. `lib/foo`,
`modules/foo` etc. Downside to that is an extra directory level to all
of the source files and inconsistency with projects that don't have
compiled extensions and therefore have their python packages in the
root directory.

2. Keep the packages in the root, which means an inconvenience having
to `chdir` out of the project root (eg. into tests/ directory) so that
python interpreter does not see the source packages (via build script
or manually).

3. Keep the packages in the root under a different name (eg. `foo-
module` or `foo-lib`) with an appropriate `package_dir={'foo':'lib-
foo'}` line in `setup.py`. This is a variation of pt. 1 without an
extra level of directory hierarchy, which is pretty much the same
thing, I suppose.

4. Keep the packages in the root and use `setup.py build_ext --
inplace`, however this contaminates the source tree. In addition, this
does not go well if I use another


Either case introduces an overhead vs. a plain python project where
one can modify/run code right out of the source tree. I'd very much
like to hear if there's a preferred way of dealing with this and/or
which particular method you use for you projects.


Dimitri.