From inform at tiker.net  Tue Feb  1 17:05:48 2011
From: inform at tiker.net (Andreas Kloeckner)
Date: Tue, 01 Feb 2011 11:05:48 -0500
Subject: [Distutils] Weird dependency recursion to self on package install
Message-ID: <87hbcn7nab.fsf@grizzly.selfip.net>

Hi there, 

I just got a truly strange report from a user who sent me the following
install log:

---------------------------------------------------------------------
(pythonenv)knepley:/PETSc3/multicore/pyopencl$ python setup.py install
running install
install_dir /PETSc3/multicore/pythonenv/lib/python2.6/site-packages/
running bdist_egg
running egg_info
creating pyopencl.egg-info
writing requirements to pyopencl.egg-info/requires.txt

(snip... builds as normal)

writing build/bdist.macosx-10.6-i386/egg/EGG-INFO/native_libs.txt
zip_safe flag not set; analyzing archive contents...
creating dist
creating 'dist/pyopencl-2011.1beta3-py2.6-macosx-10.6-i386.egg' and adding
'build/bdist.macosx-10.6-i386/egg' to it
removing 'build/bdist.macosx-10.6-i386/egg' (and everything under it)
Processing pyopencl-2011.1beta3-py2.6-macosx-10.6-i386.egg
creating
/PETSc3/multicore/pythonenv/lib/python2.6/site-packages/pyopencl-2011.1beta3-py2.6-macosx-10.6-i386.egg
Extracting pyopencl-2011.1beta3-py2.6-macosx-10.6-i386.egg to
/PETSc3/multicore/pythonenv/lib/python2.6/site-packages
Adding pyopencl 2011.1beta3 to easy-install.pth file

Installed
/PETSc3/multicore/pythonenv/lib/python2.6/site-packages/pyopencl-2011.1beta3-py2.6-macosx-10.6-i386.egg
Processing dependencies for pyopencl==2011.1beta3
Searching for pyopencl==2011.1beta3
Reading http://pypi.python.org/simple/pyopencl/
Reading http://mathema.tician.de/software/pyopencl
Best match: pyopencl 2011.1beta3
Downloading
http://pypi.python.org/packages/source/p/pyopencl/pyopencl-2011.1beta3.tar.gz#md5=efc633bb5e7a03207fa657a61a12c7af
Processing pyopencl-2011.1beta3.tar.gz
---------------------------------------------------------------------

It appears that the package (PyOpenCL) finds itself as its own
dependency, proceeds to re-download itself (and then fails to build
itself the second time around, but I think that's irrelevant for us
here).

PyOpenCL uses distribute, is installed to the user's empty
distribute-based virtualenv sitting on top of a Mac system Python.

I'd much appreciate any hints on what might be wrong.

Thanks,
Andreas

PS: Versions: virtualenv-1.5.1, distribute-0.6.14
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110201/d1d3e742/attachment.pgp>

From arve.knudsen at gmail.com  Thu Feb  3 13:20:05 2011
From: arve.knudsen at gmail.com (Arve Knudsen)
Date: Thu, 3 Feb 2011 13:20:05 +0100
Subject: [Distutils] [distribute] distribute_setup.py fails on Linux
Message-ID: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>

Hello

I have a rather serious problem with distribute 0.6.14, in that it won't
install for me under Python 2.7 on Linux (RHEL 4u6). What happens is this:

-bash-3.00$ python distribute_setup.py
Extracting in /tmp/tmphDMO8m
Traceback (most recent call last):
  File "distribute_setup.py", line 485, in <module>
    main(sys.argv[1:])
  File "distribute_setup.py", line 481, in main
    _install(tarball)
  File "distribute_setup.py", line 73, in _install
    tar = tarfile.open(tarball)
  File "/usr/local/lib/python2.7/tarfile.py", line 1663, in open
    raise ReadError("file could not be opened successfully")
tarfile.ReadError: file could not be opened successfully


Is the official distribute 0.6.14 archive bad?

Arve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110203/4547a61b/attachment.html>

From ziade.tarek at gmail.com  Thu Feb  3 13:30:43 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 3 Feb 2011 13:30:43 +0100
Subject: [Distutils] [distribute] distribute_setup.py fails on Linux
In-Reply-To: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>
References: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>
Message-ID: <AANLkTimNKK0Xp4V7hTTGEpKfyM9woKX3xQK4O2=YgpUb@mail.gmail.com>

On Thu, Feb 3, 2011 at 1:20 PM, Arve Knudsen <arve.knudsen at gmail.com> wrote:
> Hello
> I have a rather serious problem with distribute 0.6.14, in that it won't
> install for me under Python 2.7 on Linux (RHEL 4u6). What happens is this:
> -bash-3.00$ python distribute_setup.py
> Extracting in /tmp/tmphDMO8m
> Traceback (most recent call last):
> ??File "distribute_setup.py", line 485, in <module>
> ?? ?main(sys.argv[1:])
> ??File "distribute_setup.py", line 481, in main
> ?? ?_install(tarball)
> ??File "distribute_setup.py", line 73, in _install
> ?? ?tar = tarfile.open(tarball)
> ??File "/usr/local/lib/python2.7/tarfile.py", line 1663, in open
> ?? ?raise ReadError("file could not be opened successfully")
> tarfile.ReadError: file could not be opened successfully

Weird, works for me:

arek at tarek-laptop:/tmp$ wget http://python-distribute.org/distribute_setup.py
--2011-02-03 13:27:33--  http://python-distribute.org/distribute_setup.py
Resolving python-distribute.org... 88.191.66.185
Connecting to python-distribute.org|88.191.66.185|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15757 (15K) [text/x-python]
Saving to: `distribute_setup.py'

100%[===================================================================================>]
15,757      18.9K/s   in 0.8s

2011-02-03 13:27:39 (18.9 KB/s) - `distribute_setup.py' saved [15757/15757]

tarek at tarek-laptop:/tmp$ sudo python2.7 distribute_setup.py
[sudo] password for tarek:
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
Extracting in /tmp/tmpw5VpwH
Now working in /tmp/tmpw5VpwH/distribute-0.6.14
Installing Distribute
...some install output..


>
> Is the official distribute 0.6.14 archive bad?

No. Can you try to download it and unpack it manually from
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
?

Maybe there's an permission issue somehow when you call the script.


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



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

From arve.knudsen at gmail.com  Thu Feb  3 13:47:15 2011
From: arve.knudsen at gmail.com (Arve Knudsen)
Date: Thu, 3 Feb 2011 13:47:15 +0100
Subject: [Distutils] [distribute] distribute_setup.py fails on Linux
In-Reply-To: <AANLkTimNKK0Xp4V7hTTGEpKfyM9woKX3xQK4O2=YgpUb@mail.gmail.com>
References: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>
	<AANLkTimNKK0Xp4V7hTTGEpKfyM9woKX3xQK4O2=YgpUb@mail.gmail.com>
Message-ID: <AANLkTikh1L_gnQwRBVHVx0qfs6yF_PzxdOuo_Wrsdeq3@mail.gmail.com>

Hi Tarek

Nevermind, there was a problem with the Python installation so that it
didn't support zlib. Reinstalling Python fixed it :) Sorry for bothering
you. It might be an idea to embellish distribute_setup.py though, so that it
detects that Python can't untar the gzipped archive (due to missing zlib
support). That would've saved us some confusion at least :)

Arve

On Thu, Feb 3, 2011 at 1:30 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> On Thu, Feb 3, 2011 at 1:20 PM, Arve Knudsen <arve.knudsen at gmail.com>
> wrote:
> > Hello
> > I have a rather serious problem with distribute 0.6.14, in that it won't
> > install for me under Python 2.7 on Linux (RHEL 4u6). What happens is
> this:
> > -bash-3.00$ python distribute_setup.py
> > Extracting in /tmp/tmphDMO8m
> > Traceback (most recent call last):
> >   File "distribute_setup.py", line 485, in <module>
> >     main(sys.argv[1:])
> >   File "distribute_setup.py", line 481, in main
> >     _install(tarball)
> >   File "distribute_setup.py", line 73, in _install
> >     tar = tarfile.open(tarball)
> >   File "/usr/local/lib/python2.7/tarfile.py", line 1663, in open
> >     raise ReadError("file could not be opened successfully")
> > tarfile.ReadError: file could not be opened successfully
>
> Weird, works for me:
>
> arek at tarek-laptop:/tmp$ wget
> http://python-distribute.org/distribute_setup.py
> --2011-02-03 13:27:33--  http://python-distribute.org/distribute_setup.py
> Resolving python-distribute.org... 88.191.66.185
> Connecting to python-distribute.org|88.191.66.185|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 15757 (15K) [text/x-python]
> Saving to: `distribute_setup.py'
>
>
> 100%[===================================================================================>]
> 15,757      18.9K/s   in 0.8s
>
> 2011-02-03 13:27:39 (18.9 KB/s) - `distribute_setup.py' saved [15757/15757]
>
> tarek at tarek-laptop:/tmp$ sudo python2.7 distribute_setup.py
> [sudo] password for tarek:
> Downloading
> http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
> Extracting in /tmp/tmpw5VpwH
> Now working in /tmp/tmpw5VpwH/distribute-0.6.14
> Installing Distribute
> ...some install output..
>
>
> >
> > Is the official distribute 0.6.14 archive bad?
>
> No. Can you try to download it and unpack it manually from
>
> http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
> ?
>
> Maybe there's an permission issue somehow when you call the script.
>
>
> > Arve
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
> >
> >
>
>
>
> --
> Tarek Ziad? | http://ziade.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110203/a0ad52f6/attachment.html>

From ziade.tarek at gmail.com  Thu Feb  3 13:52:02 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 3 Feb 2011 13:52:02 +0100
Subject: [Distutils] [distribute] distribute_setup.py fails on Linux
In-Reply-To: <AANLkTikh1L_gnQwRBVHVx0qfs6yF_PzxdOuo_Wrsdeq3@mail.gmail.com>
References: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>
	<AANLkTimNKK0Xp4V7hTTGEpKfyM9woKX3xQK4O2=YgpUb@mail.gmail.com>
	<AANLkTikh1L_gnQwRBVHVx0qfs6yF_PzxdOuo_Wrsdeq3@mail.gmail.com>
Message-ID: <AANLkTikFzyKnNC5FUMrt3qvZKdmzg9ey_fzoLKP054_7@mail.gmail.com>

On Thu, Feb 3, 2011 at 1:47 PM, Arve Knudsen <arve.knudsen at gmail.com> wrote:
> Hi Tarek
> Nevermind, there was a problem with the Python installation so that it
> didn't support zlib. Reinstalling Python fixed it :) Sorry for bothering
> you. It might be an idea to embellish distribute_setup.py though, so that it
> detects that Python can't untar the gzipped archive (due to missing zlib
> support). That would've saved us some confusion at least :)
> Arve

Oh.. mmm I think this should even be addressed in tarfile if possible:
if tarfile encounters a zipped archive, and zlib is not installed, it
should not return a cryptic

tarfile.ReadError: file could not be opened successfully

But an error like

tarfile.ReadError: archive not supported (zlib not installed)

And well, searching for this error in bugs.python.org, it looks like
it will be addressed soon: http://bugs.python.org/issue8978





>
> On Thu, Feb 3, 2011 at 1:30 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> On Thu, Feb 3, 2011 at 1:20 PM, Arve Knudsen <arve.knudsen at gmail.com>
>> wrote:
>> > Hello
>> > I have a rather serious problem with distribute 0.6.14, in that it won't
>> > install for me under Python 2.7 on Linux (RHEL 4u6). What happens is
>> > this:
>> > -bash-3.00$ python distribute_setup.py
>> > Extracting in /tmp/tmphDMO8m
>> > Traceback (most recent call last):
>> > ??File "distribute_setup.py", line 485, in <module>
>> > ?? ?main(sys.argv[1:])
>> > ??File "distribute_setup.py", line 481, in main
>> > ?? ?_install(tarball)
>> > ??File "distribute_setup.py", line 73, in _install
>> > ?? ?tar = tarfile.open(tarball)
>> > ??File "/usr/local/lib/python2.7/tarfile.py", line 1663, in open
>> > ?? ?raise ReadError("file could not be opened successfully")
>> > tarfile.ReadError: file could not be opened successfully
>>
>> Weird, works for me:
>>
>> arek at tarek-laptop:/tmp$ wget
>> http://python-distribute.org/distribute_setup.py
>> --2011-02-03 13:27:33-- ?http://python-distribute.org/distribute_setup.py
>> Resolving python-distribute.org... 88.191.66.185
>> Connecting to python-distribute.org|88.191.66.185|:80... connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 15757 (15K) [text/x-python]
>> Saving to: `distribute_setup.py'
>>
>>
>> 100%[===================================================================================>]
>> 15,757 ? ? ?18.9K/s ? in 0.8s
>>
>> 2011-02-03 13:27:39 (18.9 KB/s) - `distribute_setup.py' saved
>> [15757/15757]
>>
>> tarek at tarek-laptop:/tmp$ sudo python2.7 distribute_setup.py
>> [sudo] password for tarek:
>> Downloading
>> http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
>> Extracting in /tmp/tmpw5VpwH
>> Now working in /tmp/tmpw5VpwH/distribute-0.6.14
>> Installing Distribute
>> ...some install output..
>>
>>
>> >
>> > Is the official distribute 0.6.14 archive bad?
>>
>> No. Can you try to download it and unpack it manually from
>>
>> http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
>> ?
>>
>> Maybe there's an permission issue somehow when you call the script.
>>
>>
>> > Arve
>> > _______________________________________________
>> > 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 arve.knudsen at gmail.com  Thu Feb  3 14:09:38 2011
From: arve.knudsen at gmail.com (Arve Knudsen)
Date: Thu, 3 Feb 2011 14:09:38 +0100
Subject: [Distutils] [distribute] distribute_setup.py fails on Linux
In-Reply-To: <AANLkTikFzyKnNC5FUMrt3qvZKdmzg9ey_fzoLKP054_7@mail.gmail.com>
References: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>
	<AANLkTimNKK0Xp4V7hTTGEpKfyM9woKX3xQK4O2=YgpUb@mail.gmail.com>
	<AANLkTikh1L_gnQwRBVHVx0qfs6yF_PzxdOuo_Wrsdeq3@mail.gmail.com>
	<AANLkTikFzyKnNC5FUMrt3qvZKdmzg9ey_fzoLKP054_7@mail.gmail.com>
Message-ID: <AANLkTi=DgsSbgR2cfYxqTLERhgBo2L80WOwKziLFvUj-@mail.gmail.com>

On Thu, Feb 3, 2011 at 1:52 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> On Thu, Feb 3, 2011 at 1:47 PM, Arve Knudsen <arve.knudsen at gmail.com>
> wrote:
> > Hi Tarek
> > Nevermind, there was a problem with the Python installation so that it
> > didn't support zlib. Reinstalling Python fixed it :) Sorry for bothering
> > you. It might be an idea to embellish distribute_setup.py though, so that
> it
> > detects that Python can't untar the gzipped archive (due to missing zlib
> > support). That would've saved us some confusion at least :)
> > Arve
>
> Oh.. mmm I think this should even be addressed in tarfile if possible:
> if tarfile encounters a zipped archive, and zlib is not installed, it
> should not return a cryptic
>
> tarfile.ReadError: file could not be opened successfully
>
> But an error like
>
> tarfile.ReadError: archive not supported (zlib not installed)
>

Of course, tarfile *should* address this.


> And well, searching for this error in bugs.python.org, it looks like
> it will be addressed soon: http://bugs.python.org/issue8978


Nice surprise :) However, it'll only help with fixed versions of Python, no?
I figure distribute aims to support older Pythons as well.

Arve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110203/96fd8ea5/attachment.html>

From ziade.tarek at gmail.com  Thu Feb  3 14:14:56 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 3 Feb 2011 14:14:56 +0100
Subject: [Distutils] [distribute] distribute_setup.py fails on Linux
In-Reply-To: <AANLkTi=DgsSbgR2cfYxqTLERhgBo2L80WOwKziLFvUj-@mail.gmail.com>
References: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>
	<AANLkTimNKK0Xp4V7hTTGEpKfyM9woKX3xQK4O2=YgpUb@mail.gmail.com>
	<AANLkTikh1L_gnQwRBVHVx0qfs6yF_PzxdOuo_Wrsdeq3@mail.gmail.com>
	<AANLkTikFzyKnNC5FUMrt3qvZKdmzg9ey_fzoLKP054_7@mail.gmail.com>
	<AANLkTi=DgsSbgR2cfYxqTLERhgBo2L80WOwKziLFvUj-@mail.gmail.com>
Message-ID: <AANLkTi=pYV5q74JP0p848ZnYatSpzyAZYAdgHEtjGi6V@mail.gmail.com>

On Thu, Feb 3, 2011 at 2:09 PM, Arve Knudsen <arve.knudsen at gmail.com> wrote:
> On Thu, Feb 3, 2011 at 1:52 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> On Thu, Feb 3, 2011 at 1:47 PM, Arve Knudsen <arve.knudsen at gmail.com>
>> wrote:
>> > Hi Tarek
>> > Nevermind, there was a problem with the Python installation so that it
>> > didn't support zlib. Reinstalling Python fixed it :) Sorry for bothering
>> > you. It might be an idea to embellish distribute_setup.py though, so
>> > that it
>> > detects that Python can't untar the gzipped archive (due to missing zlib
>> > support). That would've saved us some confusion at least :)
>> > Arve
>>
>> Oh.. mmm I think this should even be addressed in tarfile if possible:
>> if tarfile encounters a zipped archive, and zlib is not installed, it
>> should not return a cryptic
>>
>> tarfile.ReadError: file could not be opened successfully
>>
>> But an error like
>>
>> tarfile.ReadError: archive not supported (zlib not installed)
>
> Of course, tarfile *should* address this.
>
>>
>> And well, searching for this error in bugs.python.org, it looks like
>> it will be addressed soon: http://bugs.python.org/issue8978
>
> Nice surprise :) However, it'll only help with fixed versions of Python, no?
> I figure distribute aims to support older Pythons as well.

Sure,  we simply make sure zlib is installed there since Distribute is
always a targz

Patches are welcome :D

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

From arve.knudsen at gmail.com  Thu Feb  3 14:15:31 2011
From: arve.knudsen at gmail.com (Arve Knudsen)
Date: Thu, 3 Feb 2011 14:15:31 +0100
Subject: [Distutils] [distribute] distribute_setup.py fails on Linux
In-Reply-To: <AANLkTi=pYV5q74JP0p848ZnYatSpzyAZYAdgHEtjGi6V@mail.gmail.com>
References: <AANLkTimoz26XwVapeN1FZmmtnKOSOMpocgvExTHNROO6@mail.gmail.com>
	<AANLkTimNKK0Xp4V7hTTGEpKfyM9woKX3xQK4O2=YgpUb@mail.gmail.com>
	<AANLkTikh1L_gnQwRBVHVx0qfs6yF_PzxdOuo_Wrsdeq3@mail.gmail.com>
	<AANLkTikFzyKnNC5FUMrt3qvZKdmzg9ey_fzoLKP054_7@mail.gmail.com>
	<AANLkTi=DgsSbgR2cfYxqTLERhgBo2L80WOwKziLFvUj-@mail.gmail.com>
	<AANLkTi=pYV5q74JP0p848ZnYatSpzyAZYAdgHEtjGi6V@mail.gmail.com>
Message-ID: <AANLkTik3y+nTJcqF58=4BqCTgDFWsQYO191bkLkG=z7N@mail.gmail.com>

On Thu, Feb 3, 2011 at 2:14 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> On Thu, Feb 3, 2011 at 2:09 PM, Arve Knudsen <arve.knudsen at gmail.com>
> wrote:
> > On Thu, Feb 3, 2011 at 1:52 PM, Tarek Ziad? <ziade.tarek at gmail.com>
> wrote:
> >>
> >> On Thu, Feb 3, 2011 at 1:47 PM, Arve Knudsen <arve.knudsen at gmail.com>
> >> wrote:
> >> > Hi Tarek
> >> > Nevermind, there was a problem with the Python installation so that it
> >> > didn't support zlib. Reinstalling Python fixed it :) Sorry for
> bothering
> >> > you. It might be an idea to embellish distribute_setup.py though, so
> >> > that it
> >> > detects that Python can't untar the gzipped archive (due to missing
> zlib
> >> > support). That would've saved us some confusion at least :)
> >> > Arve
> >>
> >> Oh.. mmm I think this should even be addressed in tarfile if possible:
> >> if tarfile encounters a zipped archive, and zlib is not installed, it
> >> should not return a cryptic
> >>
> >> tarfile.ReadError: file could not be opened successfully
> >>
> >> But an error like
> >>
> >> tarfile.ReadError: archive not supported (zlib not installed)
> >
> > Of course, tarfile *should* address this.
> >
> >>
> >> And well, searching for this error in bugs.python.org, it looks like
> >> it will be addressed soon: http://bugs.python.org/issue8978
> >
> > Nice surprise :) However, it'll only help with fixed versions of Python,
> no?
> > I figure distribute aims to support older Pythons as well.
>
> Sure,  we simply make sure zlib is installed there since Distribute is
> always a targz
>
> Patches are welcome :D


I'll consider it :)

Arve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110203/49d01895/attachment.html>

From matt at whoosh.ca  Thu Feb  3 16:17:08 2011
From: matt at whoosh.ca (Matt Chaput)
Date: Thu, 3 Feb 2011 10:17:08 -0500
Subject: [Distutils] Python version in egg name
References: <4D49DF92.4010702@sidefx.com>
Message-ID: <4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>

When I create an egg the Python version used to create the egg is encoded in the egg filename, e.g. Whoosh-1.6.0-py2.7.egg.

Is this version number used to decide what egg a user gets from PyPI? I didn't think it was, but a user is seeming to indicate that he got different versions based on what version of Python he was using.

Is there a way to set this value to "py2.5" as a configuration option, other than running setup.py using the Python 2.5 executable? Or not have it be part of the egg filename at all? I'm using Python 2.7 as my default Python install but I make sure that the code in my library is compatible with 2.5+. I've already someone think the library is only for a later version of Python because that's what I used to build the egg.

Sorry if this is an old question, I looked around but didn't find any docs on the subject.

Thanks,

Matt


From eric at trueblade.com  Thu Feb  3 16:34:44 2011
From: eric at trueblade.com (Eric Smith)
Date: Thu, 03 Feb 2011 10:34:44 -0500
Subject: [Distutils] Python version in egg name
In-Reply-To: <4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>
References: <4D49DF92.4010702@sidefx.com>
	<4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>
Message-ID: <4D4ACB14.9070302@trueblade.com>

On 02/03/2011 10:17 AM, Matt Chaput wrote:
> When I create an egg the Python version used to create the egg is encoded in the egg filename, e.g. Whoosh-1.6.0-py2.7.egg.
>
> Is this version number used to decide what egg a user gets from PyPI? I didn't think it was, but a user is seeming to indicate that he got different versions based on what version of Python he was using.
>
> Is there a way to set this value to "py2.5" as a configuration option, other than running setup.py using the Python 2.5 executable? Or not have it be part of the egg filename at all? I'm using Python 2.7 as my default Python install but I make sure that the code in my library is compatible with 2.5+. I've already someone think the library is only for a later version of Python because that's what I used to build the egg.
>
> Sorry if this is an old question, I looked around but didn't find any docs on the subject.

I use source distributions (python setup.py sdist) and then distribute 
the resulting .tar.gz file. Since it's a source (not binary) 
distribution, it can potentially run with any version of Python.

You see this a lot on PyPI, where the only thing uploaded is a .tar.gz 
file. See http://pypi.python.org/pypi/buildout.dumppickedversions/0.4, 
for example.

Eric.

From matt at whoosh.ca  Thu Feb  3 17:24:59 2011
From: matt at whoosh.ca (Matt Chaput)
Date: Thu, 03 Feb 2011 11:24:59 -0500
Subject: [Distutils] Python version in egg name
In-Reply-To: <4D4ACB14.9070302@trueblade.com>
References: <4D49DF92.4010702@sidefx.com>	<4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>
	<4D4ACB14.9070302@trueblade.com>
Message-ID: <4D4AD6DB.5010405@whoosh.ca>

On 03/02/2011 10:34 AM, Eric Smith wrote:
> I use source distributions (python setup.py sdist) and then distribute
> the resulting .tar.gz file. Since it's a source (not binary)
> distribution, it can potentially run with any version of Python.
>
> You see this a lot on PyPI, where the only thing uploaded is a .tar.gz
> file. See http://pypi.python.org/pypi/buildout.dumppickedversions/0.4,
> for example.

Can people still use easy_install/pip to install it if it's not an egg?

Thanks,

Matt

From eric at trueblade.com  Thu Feb  3 17:39:35 2011
From: eric at trueblade.com (Eric Smith)
Date: Thu, 03 Feb 2011 11:39:35 -0500
Subject: [Distutils] Python version in egg name
In-Reply-To: <4D4AD6DB.5010405@whoosh.ca>
References: <4D49DF92.4010702@sidefx.com>
	<4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>
	<4D4ACB14.9070302@trueblade.com> <4D4AD6DB.5010405@whoosh.ca>
Message-ID: <12523643-34cb-4781-9bb5-bcb7adfe4cd8@email.android.com>

I use buildout, which uses setuptools/distribute. So for that, the answer is yes.  

"Matt Chaput" <matt at whoosh.ca> wrote:

>On 03/02/2011 10:34 AM, Eric Smith wrote:
>> I use source distributions (python setup.py sdist) and then
>distribute
>> the resulting .tar.gz file. Since it's a source (not binary)
>> distribution, it can potentially run with any version of Python.
>>
>> You see this a lot on PyPI, where the only thing uploaded is a
>.tar.gz
>> file. See
>http://pypi.python.org/pypi/buildout.dumppickedversions/0.4,
>> for example.
>
>Can people still use easy_install/pip to install it if it's not an egg?
>
>Thanks,
>
>Matt
>_______________________________________________
>Distutils-SIG maillist  -  Distutils-SIG at python.org
>http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Eric.

From carl at oddbird.net  Thu Feb  3 17:28:06 2011
From: carl at oddbird.net (Carl Meyer)
Date: Thu, 03 Feb 2011 11:28:06 -0500
Subject: [Distutils] Python version in egg name
In-Reply-To: <4D4AD6DB.5010405@whoosh.ca>
References: <4D49DF92.4010702@sidefx.com>	<4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>	<4D4ACB14.9070302@trueblade.com>
	<4D4AD6DB.5010405@whoosh.ca>
Message-ID: <4D4AD796.4020508@oddbird.net>

On 02/03/2011 11:24 AM, Matt Chaput wrote:
> Can people still use easy_install/pip to install it if it's not an egg?

Yes. In fact, pip can only install from source distributions.

A source .tar.gz is the most broadly-compatible distribution format
available, unless your package includes compiled extensions and you're
targeting a platform where compilation is problematic (i.e. Windows).

Carl

From matt at whoosh.ca  Thu Feb  3 19:20:54 2011
From: matt at whoosh.ca (Matt Chaput)
Date: Thu, 03 Feb 2011 13:20:54 -0500
Subject: [Distutils] Python version in egg name
In-Reply-To: <4D4AD796.4020508@oddbird.net>
References: <4D49DF92.4010702@sidefx.com>	<4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>	<4D4ACB14.9070302@trueblade.com>	<4D4AD6DB.5010405@whoosh.ca>
	<4D4AD796.4020508@oddbird.net>
Message-ID: <4D4AF206.5050107@whoosh.ca>

On 03/02/2011 11:28 AM, Carl Meyer wrote:
> On 02/03/2011 11:24 AM, Matt Chaput wrote:
>> Can people still use easy_install/pip to install it if it's not an egg?
>
> Yes. In fact, pip can only install from source distributions.

Interesting. So long bdist_egg!

Thanks all,

Matt

From pje at telecommunity.com  Thu Feb  3 23:19:34 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 03 Feb 2011 17:19:34 -0500
Subject: [Distutils] Python version in egg name
In-Reply-To: <4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>
References: <4D49DF92.4010702@sidefx.com>
	<4B68EED8-32BF-43F4-B79E-AE5054FF45C0@whoosh.ca>
Message-ID: <20110203221940.2E8D23A4758@sparrow.telecommunity.com>

At 10:17 AM 2/3/2011 -0500, Matt Chaput wrote:
>When I create an egg the Python version used to create the egg is 
>encoded in the egg filename, e.g. Whoosh-1.6.0-py2.7.egg.
>
>Is this version number used to decide what egg a user gets from 
>PyPI? I didn't think it was, but a user is seeming to indicate that 
>he got different versions based on what version of Python he was using.
>
>Is there a way to set this value to "py2.5" as a configuration 
>option, other than running setup.py using the Python 2.5 executable? 
>Or not have it be part of the egg filename at all? I'm using Python 
>2.7 as my default Python install but I make sure that the code in my 
>library is compatible with 2.5+. I've already someone think the 
>library is only for a later version of Python because that's what I 
>used to build the egg.
>
>Sorry if this is an old question, I looked around but didn't find 
>any docs on the subject.

I see you've already solved your issue by using source distributions, 
but for the archives I thought I should mention that the reason eggs 
are version specific is because they contained compiled .pyc or .pyo 
files, and those are only compatible with the Python version that 
compiled them.

If you are distributing pure Python code through PyPI, though, there 
is usually no reason to ship it in an egg.  Eggs were designed as a 
binary plugin format for rich application platforms, analagous to 
Java "jars" or Eclipse plugins.  They're intended for scenarios where 
installing from source is overly complex and/or you want to make it 
so users can just drop a file into a plugin directory to get 
going.  (easy_install came later, as a quick hack to automate 
building and installing eggs.)


From rik at inse.ru  Fri Feb  4 12:12:59 2011
From: rik at inse.ru (Roman Kurakin)
Date: Fri, 04 Feb 2011 14:12:59 +0300
Subject: [Distutils] namespace_packages: include itself ot not include
Message-ID: <4D4BDF3B.3010104@inse.ru>

Hi,

    Let suppose that we have package aaa and subpackage bbb and we are going
to write setup.py for bbb using setuptools:

extra = dict(
    namespace_packages=["aaa", "aaa.bbb"],
    zip_safe = False,
    install_requires = ['setuptools'],
    )

if __name__=="__main__":
    setup(name="aaa.bbb",
          version="0.0.1",
          description="Dummy example subpackage",
          author="Mr. Nemo",
          url="http://www.the.way.org/to/hell",
          author_email="MrNemo at the.way.org",
          packages=['aaa.bbb'],
          license='BSD',
          **extra)

    This is the way of namespace_packages usage I against of.  So, the 
questions is
am I right standing that package bbb, subpackage of aaa must list in 
namespace_packages
only namespaces it participate in eq 'aaa', and must not list any 
namespaces it is provides,
in this case 'aaa.bbb'? So correct value namespace_packages=['aaa'] in 
the case above.

Best regards,
    Roman Kurakin



From pje at telecommunity.com  Fri Feb  4 16:20:28 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 04 Feb 2011 10:20:28 -0500
Subject: [Distutils] namespace_packages: include itself ot not  include
In-Reply-To: <4D4BDF3B.3010104@inse.ru>
References: <4D4BDF3B.3010104@inse.ru>
Message-ID: <20110204152035.3217C3A405C@sparrow.telecommunity.com>

At 02:12 PM 2/4/2011 +0300, Roman Kurakin wrote:
>Hi,
>
>    Let suppose that we have package aaa and subpackage bbb and we are going
>to write setup.py for bbb using setuptools:
>
>extra = dict(
>    namespace_packages=["aaa", "aaa.bbb"],
>    zip_safe = False,
>    install_requires = ['setuptools'],
>    )
>
>if __name__=="__main__":
>    setup(name="aaa.bbb",
>          version="0.0.1",
>          description="Dummy example subpackage",
>          author="Mr. Nemo",
>          url="http://www.the.way.org/to/hell",
>          author_email="MrNemo at the.way.org",
>          packages=['aaa.bbb'],
>          license='BSD',
>          **extra)
>
>    This is the way of namespace_packages usage I against of.  So, 
> the questions is
>am I right standing that package bbb, subpackage of aaa must list in 
>namespace_packages
>only namespaces it participate in eq 'aaa', and must not list any 
>namespaces it is provides,
>in this case 'aaa.bbb'? So correct value namespace_packages=['aaa'] 
>in the case above.

If 'aaa.bbb' is not itself a namespace package, then 
namespace_packages should only contain 'aaa'.  And unless you will 
have yet another project which is installing something under aaa.bbb, 
then aaa.bbb does not need to be a namespace package.

namespace_packages should only list namespaces in which the current 
project *participates*.  That is, it should list packages that are 
*containers* for the thing(s) this project is providing, that are 
*shared* by other projects.


From matt at sidefx.com  Wed Feb  2 23:49:54 2011
From: matt at sidefx.com (Matt Chaput)
Date: Wed, 02 Feb 2011 17:49:54 -0500
Subject: [Distutils] Python version in egg name
Message-ID: <4D49DF92.4010702@sidefx.com>

When I create an egg the Python version used to create the egg is 
encoded in the egg filename, e.g. Whoosh-1.6.0-py2.7.egg.

Is this version number used to decide what egg a user gets from PyPI? I 
didn't think it was, but a user is seeming to indicate that he got 
different versions based on what version of Python he was using.

Is there a way to set this value to "py2.5" as a configuration option, 
other than running setup.py using the Python 2.5 executable? Or not have 
it be part of the egg filename at all? I'm using Python 2.7 as my 
default Python install but I make sure that the code in my library is 
compatible with 2.5+. I've already someone think the library is only for 
a later version of Python because that's what I used to build the egg.

Sorry if this is an old question, I looked around but didn't find any 
docs on the subject.

Thanks,

Matt

From glyph at twistedmatrix.com  Sat Feb  5 20:59:04 2011
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Sat, 5 Feb 2011 11:59:04 -0800
Subject: [Distutils] Python version in egg name
In-Reply-To: <4D49DF92.4010702@sidefx.com>
References: <4D49DF92.4010702@sidefx.com>
Message-ID: <5C72E1F3-5337-4185-9410-89A05BFCA9A3@twistedmatrix.com>

On Feb 2, 2011, at 2:49 PM, Matt Chaput wrote:

> Is there a way to set this value to "py2.5" as a configuration option, other than running setup.py using the Python 2.5 executable? Or not have it be part of the egg filename at all? I'm using Python 2.7 as my default Python install but I make sure that the code in my library is compatible with 2.5+. I've already someone think the library is only for a later version of Python because that's what I used to build the egg.

If you're building eggs, they're only going to be compatible with a single version of Python.  Bytecode isn't compatible across multiple versions.  If your module is pure python, you should just set up a linux VM old enough to have the Python versions you want or something :).

So you might be able to hack something together that would cause a broken egg to be installed for users of other versions of python, but you won't be able to fix this issue, no.

Otherwise, you can distribute some other format, like an sdist tarball, which has no pycs in it.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110205/70eb075b/attachment.html>

From rik at inse.ru  Mon Feb  7 22:06:19 2011
From: rik at inse.ru (Roman Kurakin)
Date: Tue, 08 Feb 2011 00:06:19 +0300
Subject: [Distutils] namespace_packages: include itself ot not  include
In-Reply-To: <20110204152035.3217C3A405C@sparrow.telecommunity.com>
References: <4D4BDF3B.3010104@inse.ru>
	<20110204152035.3217C3A405C@sparrow.telecommunity.com>
Message-ID: <4D505ECB.1060404@inse.ru>

P.J. Eby wrote:
> At 02:12 PM 2/4/2011 +0300, Roman Kurakin wrote:
>> Hi,
>>
>>    Let suppose that we have package aaa and subpackage bbb and we are 
>> going
>> to write setup.py for bbb using setuptools:
>>
>> extra = dict(
>>    namespace_packages=["aaa", "aaa.bbb"],
>>    zip_safe = False,
>>    install_requires = ['setuptools'],
>>    )
>>
>> if __name__=="__main__":
>>    setup(name="aaa.bbb",
>>          version="0.0.1",
>>          description="Dummy example subpackage",
>>          author="Mr. Nemo",
>>          url="http://www.the.way.org/to/hell",
>>          author_email="MrNemo at the.way.org",
>>          packages=['aaa.bbb'],
>>          license='BSD',
>>          **extra)
>>
>>    This is the way of namespace_packages usage I against of.  So, the 
>> questions is
>> am I right standing that package bbb, subpackage of aaa must list in 
>> namespace_packages
>> only namespaces it participate in eq 'aaa', and must not list any 
>> namespaces it is provides,
>> in this case 'aaa.bbb'? So correct value namespace_packages=['aaa'] 
>> in the case above.
> If 'aaa.bbb' is not itself a namespace package, then 
> namespace_packages should only contain 'aaa'.  And unless you will 
> have yet another project which is installing something under aaa.bbb, 
> then aaa.bbb does not need to be a namespace package.
Ok. If it is not namespace package by itself all is clear. But in case 
it is?
What is the difference? Why 'aaa.bbb' should even know that there is, or
will be any other, for example 'aaa.bbb.ccc'? For example, in case
'aaa.bbb.ccc' is developed by some one else.
> namespace_packages should only list namespaces in which the current 
> project *participates*.
'Participates' or also 'provides'? In simple case the package 'aaa.bbb' 
only participates
in 'aaa' and provides only 'aaa.bbb'.
> That is, it should list packages that are *containers* for the 
> thing(s) this project is providing, that are *shared* by other projects. 
In a simple case 'shared' is a little bit confusing in case we are 
'extending'
namespace via strict hierarchy aaa.bbb, aaa.ccc, aaa.bbb.ddd etc. Where
any of packages are initial providers of their own namespaces. 'aaa' and
'aaa.bbb' share 'aaa' namespace, but one is initial provider of 'aaa' share
and other consumer of 'aaa' share.

Best regards,
    rik


From pje at telecommunity.com  Tue Feb  8 00:16:14 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 07 Feb 2011 18:16:14 -0500
Subject: [Distutils] namespace_packages: include itself ot not include
In-Reply-To: <4D505ECB.1060404@inse.ru>
References: <4D4BDF3B.3010104@inse.ru>
	<20110204152035.3217C3A405C@sparrow.telecommunity.com>
	<4D505ECB.1060404@inse.ru>
Message-ID: <20110207231630.8AD8B3A405C@sparrow.telecommunity.com>

At 12:06 AM 2/8/2011 +0300, Roman Kurakin wrote:
>but one is initial provider of 'aaa' share
>and other consumer of 'aaa' share.

This statement is why you're confused.  A namespace is not "provided" 
by anyone, only participated in.

Think of it this way.  You and I decide to have lunch together.  I am 
not providing the lunch.  You are not providing the lunch.  But we 
are both participating in the lunch.

That is how namespace packages work.  aaa.bbb participates in the aaa 
namespace, therefore it lists aaa as a namespace package.

Better, a concrete example.  zope.interface participates in the zope 
namespace package, so it lists 'zope' in namespace_packages.  There 
is no "zope" package that stands by itself, there are only zope.* 
packages that together participate in the zope namespace.

>Why 'aaa.bbb' should even know that there is, or
>will be any other, for example 'aaa.bbb.ccc'?

It would only do this if you indeed planned to have that happen.

For example, I have a 'peak.util' namespace package.  There are many 
projects, such as DecoratorTools, Importing, and so forth on PyPI 
that provide modules in that namespace.  DecoratorTools is 
peak.util.decorators, Importing is peak.util.imports, and so on.

There is NO peak.util package, however.  You cannot download 
peak.util someplace, because it is a *namespace* package.

The entire point of a namespace package is that it's just a name, and 
NOT an actual package.  You would never import anything directly from 
peak.util, because it's just a place where other packages live.

"peak" is also a namespace package, and there are other projects that 
contribute modules and subpackages to that namespace.


>In a simple case 'shared' is a little bit confusing in case we are 'extending'
>namespace via strict hierarchy aaa.bbb, aaa.ccc, aaa.bbb.ddd etc. Where
>any of packages are initial providers of their own namespaces. 'aaa' and
>'aaa.bbb' share 'aaa' namespace, but one is initial provider of 'aaa' share
>and other consumer of 'aaa' share.

Namespace packages don't work like that.  All participants in a 
namespace are *equal peers*, not "base plus extensions".

Sure, you can DO it, but the tools don't have any notion that one 
package is the base and another is the extender.  That's why you're 
getting confused: you are thinking "base and extension", but 
namespace packages are peer-to-peer.  You participate in a namespace 
by having some code that goes in it, and EVERY project that 
participates in that namespace must declare it -- no exceptions.

(If a project doesn't declare the namespace, and it ends up first on 
sys.path, it will block access to all the other participants in the 
same namespace.)


From barry at python.org  Tue Feb  8 02:06:35 2011
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Feb 2011 20:06:35 -0500
Subject: [Distutils] python3 setup.py test failing
Message-ID: <20110207200635.39526884@python.org>

I just grabbed distribute_setup.py 0.6.14 and tried to run

    $ python3 setup.py test

using Python 3.2, on the source code at

    bzr branch lp:flufl.enum

I'm certain this used to work, but now after I see all the fixers run, I get
the following failure:


...
running egg_info
creating /home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info
writing /home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info/PKG-INFO
writing namespace_packages to /home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info/namespace_packages.txt
writing top-level names to /home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info/top_level.txt
writing dependency_links to /home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info/dependency_links.txt
writing manifest file '/home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info/SOURCES.txt'
reading manifest file '/home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
no previously-included directories found matching '_build'
writing manifest file '/home/barry/projects/flufl/flufl.enum/build/lib/flufl.enum.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
  File "setup.py", line 48, in <module>
    convert_2to3_doctests=find_doctests(),
  File "/usr/lib/python3.2/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/lib/python3.2/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "build/bdist.linux-x86_64/egg/setuptools/command/test.py", line 137, in run
  File "build/bdist.linux-x86_64/egg/setuptools/command/test.py", line 117, in with_project_on_sys_path
  File "build/bdist.linux-x86_64/egg/setuptools/command/test.py", line 146, in run_tests
  File "/usr/lib/python3.2/unittest/main.py", line 123, in __init__
    self.parseArgs(argv)
  File "/usr/lib/python3.2/unittest/main.py", line 191, in parseArgs
    self.createTests()
  File "/usr/lib/python3.2/unittest/main.py", line 198, in createTests
    self.module)
  File "/usr/lib/python3.2/unittest/loader.py", line 132, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python3.2/unittest/loader.py", line 132, in <listcomp>
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python3.2/unittest/loader.py", line 100, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'enum'

It's proving fairly difficult to debug, not the least of which because if I
run 'python3 setup.py test' again, I just get syntax errors on the doctest
because it's obviously not using the fixed .txt file:

======================================================================
FAIL: /home/barry/projects/flufl/flufl.enum/flufl/enum/docs/using.txt
Doctest: using.txt
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.2/doctest.py", line 2113, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for using.txt
  File "/home/barry/projects/flufl/flufl.enum/flufl/enum/docs/using.txt", line 0

----------------------------------------------------------------------
File "/home/barry/projects/flufl/flufl.enum/flufl/enum/docs/using.txt", line 70, in using.txt
Failed example:
    print Colors.red
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib/python3.2/doctest.py", line 1248, in __run
        compileflags, 1), test.globs)
      File "<doctest using.txt[9]>", line 1
        print Colors.red
                   ^
    SyntaxError: invalid syntax


Any thoughts?  Here's my setup():

setup(
    name='flufl.enum',
    version=__version__,
    namespace_packages=['flufl'],
    packages=find_packages(),
    include_package_data=True,
    maintainer='Barry Warsaw',
    maintainer_email='barry at python.org',
    description=description('README.txt'),
    long_description=long_description(
        'flufl/enum/README.txt',
        'flufl/enum/NEWS.txt'),
    license='LGPLv3',
    url='http://launchpad.net/flufl.enum',
    download_url='https://launchpad.net/flufl.enum/+download',
    test_suite='flufl.enum.tests',
    # Auto-conversion to Python 3.
    use_2to3=True,
    convert_2to3_doctests=find_doctests(),
    )


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

From rik at inse.ru  Tue Feb  8 11:07:58 2011
From: rik at inse.ru (Roman Kurakin)
Date: Tue, 08 Feb 2011 13:07:58 +0300
Subject: [Distutils] namespace_packages: include itself ot not include
In-Reply-To: <20110207231630.8AD8B3A405C@sparrow.telecommunity.com>
References: <4D4BDF3B.3010104@inse.ru>
	<20110204152035.3217C3A405C@sparrow.telecommunity.com>
	<4D505ECB.1060404@inse.ru>
	<20110207231630.8AD8B3A405C@sparrow.telecommunity.com>
Message-ID: <4D5115FE.3060206@inse.ru>

P.J. Eby wrote:
> At 12:06 AM 2/8/2011 +0300, Roman Kurakin wrote:
>> but one is initial provider of 'aaa' share
>> and other consumer of 'aaa' share.
>
> This statement is why you're confused.  A namespace is not "provided" 
> by anyone, only participated in.
No I am confused by practice :-) . The problem I am thinking about is 
__init__.py.
So __init__.py is my namespace provider I thinking of beside the scene. The
problem I hit was with rpm packages I was playing with. The package 
'aaa.bbb'
list itself in namespace_packages and developer states that this is 
needed cause
there is 'aaa.bbb.ccc' package. In this case, installer drops 
__init__.py not only
for aaa/__init__.py but also for aaa/bbb/__init__.py. For 'aaa' this is 
correct
since some one should provide __init__.py for 'aaa' before us. But who will
provide __init__.py for 'aaa.bbb' if we pack it as setuptool provided it 
for us?
> Think of it this way.  You and I decide to have lunch together.  I am 
> not providing the lunch.  You are not providing the lunch.  But we are 
> both participating in the lunch.
>
> That is how namespace packages work.  aaa.bbb participates in the aaa 
> namespace, therefore it lists aaa as a namespace package.
But what about 'aaa.bbb' that lists itself as a namespace package?
Should it list itself or not? In case it should, the question is how to
deal with __init__.py?

That is why I tried to draw such model with providers and extenders.
One should make reservation if lunch is planned in some popular place.

rik
>
> Better, a concrete example.  zope.interface participates in the zope 
> namespace package, so it lists 'zope' in namespace_packages.  There is 
> no "zope" package that stands by itself, there are only zope.* 
> packages that together participate in the zope namespace.
>
>> Why 'aaa.bbb' should even know that there is, or
>> will be any other, for example 'aaa.bbb.ccc'?
>
> It would only do this if you indeed planned to have that happen.
>
> For example, I have a 'peak.util' namespace package.  There are many 
> projects, such as DecoratorTools, Importing, and so forth on PyPI that 
> provide modules in that namespace.  DecoratorTools is 
> peak.util.decorators, Importing is peak.util.imports, and so on.
>
> There is NO peak.util package, however.  You cannot download peak.util 
> someplace, because it is a *namespace* package.
>
> The entire point of a namespace package is that it's just a name, and 
> NOT an actual package.  You would never import anything directly from 
> peak.util, because it's just a place where other packages live.
>
> "peak" is also a namespace package, and there are other projects that 
> contribute modules and subpackages to that namespace.
>
>> In a simple case 'shared' is a little bit confusing in case we are 
>> 'extending'
>> namespace via strict hierarchy aaa.bbb, aaa.ccc, aaa.bbb.ddd etc. Where
>> any of packages are initial providers of their own namespaces. 'aaa' and
>> 'aaa.bbb' share 'aaa' namespace, but one is initial provider of 'aaa' 
>> share
>> and other consumer of 'aaa' share.
>
> Namespace packages don't work like that.  All participants in a 
> namespace are *equal peers*, not "base plus extensions".
>
> Sure, you can DO it, but the tools don't have any notion that one 
> package is the base and another is the extender.  That's why you're 
> getting confused: you are thinking "base and extension", but namespace 
> packages are peer-to-peer.  You participate in a namespace by having 
> some code that goes in it, and EVERY project that participates in that 
> namespace must declare it -- no exceptions.
>
> (If a project doesn't declare the namespace, and it ends up first on 
> sys.path, it will block access to all the other participants in the 
> same namespace.)
>


From setuptools at bugs.python.org  Tue Feb  8 14:32:34 2011
From: setuptools at bugs.python.org (Yegor Bugayenko)
Date: Tue, 08 Feb 2011 13:32:34 +0000
Subject: [Distutils] [issue121] SVN credentials can't be provided to
	easy_install
In-Reply-To: <1297171954.5.0.420754562955.issue121@psf.upfronthosting.co.za>
Message-ID: <1297171954.5.0.420754562955.issue121@psf.upfronthosting.co.za>


New submission from Yegor Bugayenko <team at fazend.com>:

I'm trying to install Python EGG with `easy_install`, providing a URL of Subversion repository, where sources are hosted:

    $ easy_install svn://user:secret at svn.example.com/repo/trunk/my-egg
    Authentication realm: <svn://svn.example.com:3690> repo
    Password for 'me':
    
The problem is that the repository is password protected. How can I provide the desired username/password to `easy_install`?

Everything works fine when I'm using `http://` protocol instead of `svn://`

----------
messages: 581
nosy: yegor256
priority: critical
status: unread
title: SVN credentials can't be provided to easy_install

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

From pje at telecommunity.com  Tue Feb  8 16:09:49 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 08 Feb 2011 10:09:49 -0500
Subject: [Distutils] namespace_packages: include itself ot not include
In-Reply-To: <4D5115FE.3060206@inse.ru>
References: <4D4BDF3B.3010104@inse.ru>
	<20110204152035.3217C3A405C@sparrow.telecommunity.com>
	<4D505ECB.1060404@inse.ru>
	<20110207231630.8AD8B3A405C@sparrow.telecommunity.com>
	<4D5115FE.3060206@inse.ru>
Message-ID: <20110208151006.623B43A405C@sparrow.telecommunity.com>

At 01:07 PM 2/8/2011 +0300, Roman Kurakin wrote:
>P.J. Eby wrote:
>>At 12:06 AM 2/8/2011 +0300, Roman Kurakin wrote:
>>>but one is initial provider of 'aaa' share
>>>and other consumer of 'aaa' share.
>>
>>This statement is why you're confused.  A namespace is not 
>>"provided" by anyone, only participated in.
>No I am confused by practice :-) . The problem I am thinking about 
>is __init__.py.
>So __init__.py is my namespace provider I thinking of beside the scene.

There is no such thing as a namespace provider.  That's why you're 
confused.  A namespace package is just a namespace for other modules 
and packages.  It does not have any existence of its own.


>  The
>problem I hit was with rpm packages I was playing with. The package 'aaa.bbb'
>list itself in namespace_packages and developer states that this is 
>needed cause
>there is 'aaa.bbb.ccc' package. In this case, installer drops 
>__init__.py not only
>for aaa/__init__.py but also for aaa/bbb/__init__.py. For 'aaa' this 
>is correct
>since some one should provide __init__.py for 'aaa' before us.

You're still confused.  In the RPM case, there will be *no* aaa/__init__.py.


>But who will
>provide __init__.py for 'aaa.bbb' if we pack it as setuptool 
>provided it for us?

It is not necessary.  Look for a file like 
"mypackage-version-nspkg.pth" in the directory adjacent to aaa -- you 
will see that it contains code to make the package exist despite the 
nonexistence of the __init__.py


>>Think of it this way.  You and I decide to have lunch together.  I 
>>am not providing the lunch.  You are not providing the lunch.  But 
>>we are both participating in the lunch.
>>
>>That is how namespace packages work.  aaa.bbb participates in the 
>>aaa namespace, therefore it lists aaa as a namespace package.
>But what about 'aaa.bbb' that lists itself as a namespace package?

You are saying, "but what if I provide the lunch?"  You can't provide 
the lunch.  You can only *join* the lunch.

You are trying to solve a problem that doesn't exist.  Namespace 
packages are the names of a *group* of modules or packages.  There is 
no "main" package for a namespace, and no "extensions".  There is no 
single project that "provides" the namespace, just like there is no 
one person who "provides" the lunch.

If you persist in thinking that there is a provider, then you will 
continue to be confused, and trying to solve a problem that doesn't 
actually exist.


>Should it list itself or not? In case it should, the question is how to
>deal with __init__.py?

As it says in the setuptools documentation, you must provide an 
__init__.py in your project that ONLY contains the namespace 
registration.  In installation environments that do not require an 
__init__.py (e.g. rpm installs), this file will NOT be included -- an 
nspkg.pth file will be used instead.  For .egg files and directories, 
the __init__.py of every participating project is included, but only 
the first one found on sys.path will actually be used.



>That is why I tried to draw such model with providers and extenders.
>One should make reservation if lunch is planned in some popular place.

Setuptools handles the reservations.  The project simply says, "I'm 
with the aaa group", and setuptools says, "ah, then you're sitting 
over here".  ;-)  If there is nobody else arrived yet, then 
setuptools takes care of allocating the table, so to speak, and then 
seats all the newcomers there as well.

But, just because one person arrives first, doesn't make them the 
head of the group.  Members of the party may arrive in any order, and 
when others show up they will be seated in the same place.


From pje at telecommunity.com  Tue Feb  8 19:25:55 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 08 Feb 2011 13:25:55 -0500
Subject: [Distutils] [issue121] SVN credentials can't be provided to
 easy_install
In-Reply-To: <1297171954.5.0.420754562955.issue121@psf.upfronthosting.co .za>
References: <1297171954.5.0.420754562955.issue121@psf.upfronthosting.co.za>
	<1297171954.5.0.420754562955.issue121@psf.upfronthosting.co.za>
Message-ID: <20110208182611.BE1503A405C@sparrow.telecommunity.com>

If you do "svn co 
svn://user:secret at svn.example.com/repo/trunk/my-egg", does that work, 
or does it prompt you for the password?

My guess is that svn itself is the problem here, because easy_install 
does not remove password information from the URL, it just passes the 
URL as-is to the "svn" command.


From cool-rr at cool-rr.com  Tue Feb  8 19:37:17 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Tue, 8 Feb 2011 20:37:17 +0200
Subject: [Distutils] Reading in Universal Newline mode with pkg_resources
Message-ID: <AANLkTiny6egUijD71=rFZNu6XGit_QTMm3juW8Qxk6OR@mail.gmail.com>

Hello,

I'm accessing a text file using `pkg_resources`. I want to read it in
universal newline mode, i.e. to read newlines as '\n' regardless whether
they're actually '\r\n'. How do I do this?


Thanks,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110208/0d5d7f2e/attachment.html>

From rik at inse.ru  Tue Feb  8 20:29:42 2011
From: rik at inse.ru (Roman Kurakin)
Date: Tue, 08 Feb 2011 22:29:42 +0300
Subject: [Distutils] namespace_packages: include itself ot not include
In-Reply-To: <20110208151006.623B43A405C@sparrow.telecommunity.com>
References: <4D4BDF3B.3010104@inse.ru>
	<20110204152035.3217C3A405C@sparrow.telecommunity.com>
	<4D505ECB.1060404@inse.ru>
	<20110207231630.8AD8B3A405C@sparrow.telecommunity.com>
	<4D5115FE.3060206@inse.ru>
	<20110208151006.623B43A405C@sparrow.telecommunity.com>
Message-ID: <4D5199A6.9030906@inse.ru>

Sorry for top-posting. Since my model was braked, I'll try to explain the
problem from very beginning. I didn't expect that model is totally wrong :-)

There is a package 'aaa.bbb' that uses setuptool only if it is  installed on
the system. This is useful for development, but this breaks rpm build
process cause it expects __init__.py and doesn't expect egg and pth,
more over it ignores them. So in my case there is no egg & pth.

I started to dig if there is possibility to coexists development and 
rpmbuild
processes on the same system without very messy spec file. I didn't find
the strict requirements for the package to list itself in a 
namespace_package
even if I know that there would be 'aaa.bbb.ccc'. But if I not list it 
there, I
can ignore egg&pth files, and in my cases setuptool will behave compatible.

So probably question does it break something if package 'aaa.bbb'
wouldn't list itself in a namespace_package? And does it provide something
useful if package 'aaa.bbb' would?

Best regards,
    rik

P.J. Eby wrote:
> At 01:07 PM 2/8/2011 +0300, Roman Kurakin wrote:
>> P.J. Eby wrote:
>>> At 12:06 AM 2/8/2011 +0300, Roman Kurakin wrote:
>>>> but one is initial provider of 'aaa' share
>>>> and other consumer of 'aaa' share.
>>>
>>> This statement is why you're confused.  A namespace is not 
>>> "provided" by anyone, only participated in.
>> No I am confused by practice :-) . The problem I am thinking about is 
>> __init__.py.
>> So __init__.py is my namespace provider I thinking of beside the scene.
> There is no such thing as a namespace provider.  That's why you're 
> confused.  A namespace package is just a namespace for other modules 
> and packages.  It does not have any existence of its own.
>>  The
>> problem I hit was with rpm packages I was playing with. The package 
>> 'aaa.bbb'
>> list itself in namespace_packages and developer states that this is 
>> needed cause
>> there is 'aaa.bbb.ccc' package. In this case, installer drops 
>> __init__.py not only
>> for aaa/__init__.py but also for aaa/bbb/__init__.py. For 'aaa' this 
>> is correct
>> since some one should provide __init__.py for 'aaa' before us.
> You're still confused.  In the RPM case, there will be *no* 
> aaa/__init__.py.
>> But who will
>> provide __init__.py for 'aaa.bbb' if we pack it as setuptool provided 
>> it for us?
> It is not necessary.  Look for a file like 
> "mypackage-version-nspkg.pth" in the directory adjacent to aaa -- you 
> will see that it contains code to make the package exist despite the 
> nonexistence of the __init__.py
>>> Think of it this way.  You and I decide to have lunch together.  I 
>>> am not providing the lunch.  You are not providing the lunch.  But 
>>> we are both participating in the lunch.
>>>
>>> That is how namespace packages work.  aaa.bbb participates in the 
>>> aaa namespace, therefore it lists aaa as a namespace package.
>> But what about 'aaa.bbb' that lists itself as a namespace package?
> You are saying, "but what if I provide the lunch?"  You can't provide 
> the lunch.  You can only *join* the lunch.
>
> You are trying to solve a problem that doesn't exist.  Namespace 
> packages are the names of a *group* of modules or packages.  There is 
> no "main" package for a namespace, and no "extensions".  There is no 
> single project that "provides" the namespace, just like there is no 
> one person who "provides" the lunch.
>
> If you persist in thinking that there is a provider, then you will 
> continue to be confused, and trying to solve a problem that doesn't 
> actually exist.
>> Should it list itself or not? In case it should, the question is how to
>> deal with __init__.py?
> As it says in the setuptools documentation, you must provide an 
> __init__.py in your project that ONLY contains the namespace 
> registration.  In installation environments that do not require an 
> __init__.py (e.g. rpm installs), this file will NOT be included -- an 
> nspkg.pth file will be used instead.  For .egg files and directories, 
> the __init__.py of every participating project is included, but only 
> the first one found on sys.path will actually be used.
>> That is why I tried to draw such model with providers and extenders.
>> One should make reservation if lunch is planned in some popular place.
> Setuptools handles the reservations.  The project simply says, "I'm 
> with the aaa group", and setuptools says, "ah, then you're sitting 
> over here".  ;-)  If there is nobody else arrived yet, then setuptools 
> takes care of allocating the table, so to speak, and then seats all 
> the newcomers there as well.
>
> But, just because one person arrives first, doesn't make them the head 
> of the group.  Members of the party may arrive in any order, and when 
> others show up they will be seated in the same place.
>


From pje at telecommunity.com  Wed Feb  9 05:09:44 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 08 Feb 2011 23:09:44 -0500
Subject: [Distutils] namespace_packages: include itself ot not include
In-Reply-To: <4D5199A6.9030906@inse.ru>
References: <4D4BDF3B.3010104@inse.ru>
	<20110204152035.3217C3A405C@sparrow.telecommunity.com>
	<4D505ECB.1060404@inse.ru>
	<20110207231630.8AD8B3A405C@sparrow.telecommunity.com>
	<4D5115FE.3060206@inse.ru>
	<20110208151006.623B43A405C@sparrow.telecommunity.com>
	<4D5199A6.9030906@inse.ru>
Message-ID: <20110209041001.4FF453A405C@sparrow.telecommunity.com>

At 10:29 PM 2/8/2011 +0300, Roman Kurakin wrote:
>There is a package 'aaa.bbb' that uses setuptool only if it is  installed on
>the system.

In that case, it can't sensibly use setuptools namespace 
packages.  At all.  You need to either:

1. always use setuptools
2. use an alternate namespace package mechanism (such as 
pkgutil.extend_path()), and not declare the namespace
3. Not use namespace packages at all


>This is useful for development, but this breaks rpm build
>process cause it expects __init__.py and doesn't expect egg and pth,
>more over it ignores them. So in my case there is no egg & pth.

The nspkg.pth file is for non-egg installs.  If you have an egg, 
there is no nspkg.pth file for that package.


>I started to dig if there is possibility to coexists development and rpmbuild
>processes on the same system without very messy spec file. I didn't find
>the strict requirements for the package to list itself in a namespace_package
>even if I know that there would be 'aaa.bbb.ccc'.

It is a requirement for consistent and correct runtime behavior 
across all installation targets.  (The installation targets are .egg 
file, .egg-directory, and non-egg (e.g. rpm))


>So probably question does it break something if package 'aaa.bbb'
>wouldn't list itself in a namespace_package? And does it provide something
>useful if package 'aaa.bbb' would?

To make sure we're clear: if aaa.bbb is actually a namespace -- that 
is, if it has separately-installable contents -- then you MUST 
declare it if you want consistently correct runtime behavior.

If you do not declare it, then there are some environments where it 
will appear to work, and there will be other (superficially 
identical) environments where some part of the namespace will 
mysteriously fail to be importable.

In other words, the rules are there for a reason.  These limitations 
are the nature of Python 2.x's import machinery, which was not 
originally designed with namespace packages in mind.

There is a namespace package PEP that (in principle) provides a 
better mechanism than what setuptools does, but implementation 
progress is currently stalled, and the PEP has not been 
accepted.  So, your options at the present time for separately 
installed parts of a namespace package are as I have described.

There is a pure distutils approach you can use that allows partially 
installed packages to exist, but it is somewhat fragile and is not 
setuptools compatible.  It requires that there be a "provider" of a 
package, in the sense that exactly one project contains the 
__init__.py for the package.  But it is fragile because it may not be 
supported on all platforms and build targets, and it requires that 
aaa.bbb be always installed before aaa.bbb.ccc....  but of course the 
distutils by themselves have no dependency mechanism to enforce this.


From pje at telecommunity.com  Wed Feb  9 18:52:01 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 09 Feb 2011 12:52:01 -0500
Subject: [Distutils] Reading in Universal Newline mode with pkg_resources
In-Reply-To: <AANLkTiny6egUijD71=rFZNu6XGit_QTMm3juW8Qxk6OR@mail.gmail.c
 om>
References: <AANLkTiny6egUijD71=rFZNu6XGit_QTMm3juW8Qxk6OR@mail.gmail.com>
Message-ID: <20110209175416.BBF5D3A411A@sparrow.telecommunity.com>

At 08:37 PM 2/8/2011 +0200, cool-RR wrote:
>Hello,
>
>I'm accessing a text file using `pkg_resources`. I want to read it 
>in universal newline mode, i.e. to read newlines as '\n' regardless 
>whether they're actually '\r\n'. How do I do this?

Perhaps:

   StringIO(resource_string('whatever','resource').replace('\r\n','\n'))

?

Or, this might be better, since I believe splitlines uses a true 
Universal Newline approach:

   StringIO('\n'.join(resource_string('whatever','resource').splitlines()))

The pkg_resources APIs are binary, rather than text, so you have to 
do the necessary munging yourself, unless you use resource_filename() 
and open the file directly (which has its own issues).


From cool-rr at cool-rr.com  Wed Feb  9 21:08:06 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Wed, 9 Feb 2011 22:08:06 +0200
Subject: [Distutils] Reading in Universal Newline mode with pkg_resources
In-Reply-To: <20110209175416.BBF5D3A411A@sparrow.telecommunity.com>
References: <AANLkTiny6egUijD71=rFZNu6XGit_QTMm3juW8Qxk6OR@mail.gmail.com>
	<20110209175416.BBF5D3A411A@sparrow.telecommunity.com>
Message-ID: <AANLkTik18+o0e+hbGp42Fp6gpKd_+9FfoCmreOdDxYrj@mail.gmail.com>

On Wed, Feb 9, 2011 at 7:52 PM, P.J. Eby <pje at telecommunity.com> wrote:

> At 08:37 PM 2/8/2011 +0200, cool-RR wrote:
>
>> Hello,
>>
>> I'm accessing a text file using `pkg_resources`. I want to read it in
>> universal newline mode, i.e. to read newlines as '\n' regardless whether
>> they're actually '\r\n'. How do I do this?
>>
>
> Perhaps:
>
>  StringIO(resource_string('whatever','resource').replace('\r\n','\n'))
>
> ?
>
> Or, this might be better, since I believe splitlines uses a true Universal
> Newline approach:
>
>  StringIO('\n'.join(resource_string('whatever','resource').splitlines()))
>

Do you think that source_string.replace('\r', '') would work?



> The pkg_resources APIs are binary, rather than text, so you have to do the
> necessary munging yourself, unless you use resource_filename() and open the
> file directly (which has its own issues).
>

Maybe an option for text-mode reading should be added?


Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110209/a2b35303/attachment.html>

From animator333 at yahoo.com  Thu Feb 10 13:36:24 2011
From: animator333 at yahoo.com (Prashant Saxena)
Date: Thu, 10 Feb 2011 18:06:24 +0530 (IST)
Subject: [Distutils] distutils & OS X universal binaries
Message-ID: <52844.79629.qm@web94914.mail.in2.yahoo.com>

Hi,

I am new on Mac platform. I need to port an application from linux to mac. There 
are couple of custom c-extensions which I am building using cython on linux 
using distutils. It's pretty simple and straight forward there.
There are couple of things I need to know on Mac platform.

Q1. How do I create custom c-extension (cython & distutils) on mac so that they 
should run on both architecture (ppc & Intel)?

Q2. I am on 32 bit platform and I have to make sure that deployed package 
(py2app) should execute on 64-bit architecture also.

Q3. Mine is Leopard 10.5.5(intel) and default python is 2.5.1 but my app 
requires 2.6.6. How do I build python 2.6.6 in universal binary format?

Overall idea is to deploy a package on mac 10.5.5 leopard(intel 32 bit) using 
py2app in such a way so that it's compatible for both architecture (ppc & intel) 
and both platforms(32-bit & 64-bit)

Cheers

Prashant



From ekh.johan at gmail.com  Thu Feb 10 17:20:37 2011
From: ekh.johan at gmail.com (Johan Ekh)
Date: Thu, 10 Feb 2011 17:20:37 +0100
Subject: [Distutils] Including documentation in distribution?
Message-ID: <AANLkTikmbcaOfzBKMkoRrjbb25S7HGxEVN3eAJ27tZwL@mail.gmail.com>

Hi all,
I'm new to setuptools.

I have a directory structure like

setup.py
src/
    mypkg/
        __init__.py
        module1.py
        module2.py

doc/
    build/
        html/
            index.html
            intro.html
    source/
        intro.rst

and my setup.py looks like

#!/usr/bin/env python
from setuptools import setup, find_packages

setup(name='cabletlk',
      version='0.1',
      description='Cable Toolkit',
      author='Johan Ekh',
      author_email='johan.ekh at se.abb.com',
      packages=['mypkg',],
      )


I would like to include the content in "doc/built/html" in my distribution.

How can I do that?

BR / Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110210/78c79ecc/attachment.html>

From pje at telecommunity.com  Thu Feb 10 18:42:09 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 10 Feb 2011 12:42:09 -0500
Subject: [Distutils] Including documentation in distribution?
In-Reply-To: <AANLkTikmbcaOfzBKMkoRrjbb25S7HGxEVN3eAJ27tZwL@mail.gmail.c
 om>
References: <AANLkTikmbcaOfzBKMkoRrjbb25S7HGxEVN3eAJ27tZwL@mail.gmail.com>
Message-ID: <20110210174216.7655F3A4097@sparrow.telecommunity.com>

At 05:20 PM 2/10/2011 +0100, Johan Ekh wrote:
>my setup.py looks like
>
>#!/usr/bin/env python
>
>from setuptools import setup, find_packages
>
>setup(name='cabletlk',
>       version='0.1',
>       description='Cable Toolkit',
>       author='Johan Ekh',
>       author_email='<mailto:johan.ekh at se.abb.com>johan.ekh at se.abb.com',
>
>       packages=['mypkg',],
>       )

It looks like you're missing a:

    package_dir = {'':'src'}

from that.



>I would like to include the content in "doc/built/html" in my distribution.
>
>How can I do that?

If you mean your source distribution, you can do that by putting 
those files in revision control (w/appropriate plugin), or by adding 
appropriate directives to a MANIFEST.in file (see the distutils 
documentation for MANIFEST.in).

If you mean you want to install the docs as data in a certain path 
for specific platforms, see the distutils documentation for the 
"install_data" command.

If you want to include the docs in an .egg distribution or 
installation, you'll need to place them either under your .egg-info 
directory, or else put them inside mypkg/ and use 
include_package_data=True or the package_data={} directives.


From pje at telecommunity.com  Thu Feb 10 18:43:25 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 10 Feb 2011 12:43:25 -0500
Subject: [Distutils] Reading in Universal Newline mode with pkg_resources
In-Reply-To: <AANLkTik18+o0e+hbGp42Fp6gpKd_+9FfoCmreOdDxYrj@mail.gmail.c
 om>
References: <AANLkTiny6egUijD71=rFZNu6XGit_QTMm3juW8Qxk6OR@mail.gmail.com>
	<20110209175416.BBF5D3A411A@sparrow.telecommunity.com>
	<AANLkTik18+o0e+hbGp42Fp6gpKd_+9FfoCmreOdDxYrj@mail.gmail.com>
Message-ID: <20110210174328.8D5423A4097@sparrow.telecommunity.com>

At 10:08 PM 2/9/2011 +0200, cool-RR wrote:
>Do you think that source_string.replace('\r', '') would work?

If you know that it's all \r\n newlines, sure.  But then why not just 
.rstrip('\r') the lines you read?  Or .replace('\r\n', '\n')?




From cool-rr at cool-rr.com  Thu Feb 10 18:46:23 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Thu, 10 Feb 2011 19:46:23 +0200
Subject: [Distutils] Reading in Universal Newline mode with pkg_resources
In-Reply-To: <20110210174328.8D5423A4097@sparrow.telecommunity.com>
References: <AANLkTiny6egUijD71=rFZNu6XGit_QTMm3juW8Qxk6OR@mail.gmail.com>
	<20110209175416.BBF5D3A411A@sparrow.telecommunity.com>
	<AANLkTik18+o0e+hbGp42Fp6gpKd_+9FfoCmreOdDxYrj@mail.gmail.com>
	<20110210174328.8D5423A4097@sparrow.telecommunity.com>
Message-ID: <AANLkTik5SDTappfU0pNNS9NphiXqupbrtk_eFtwW7ad0@mail.gmail.com>

On Thu, Feb 10, 2011 at 7:43 PM, P.J. Eby <pje at telecommunity.com> wrote:

> At 10:08 PM 2/9/2011 +0200, cool-RR wrote:
>
>> Do you think that source_string.replace('\r', '') would work?
>>
>
> If you know that it's all \r\n newlines, sure.  But then why not just
> .rstrip('\r') the lines you read?  Or .replace('\r\n', '\n')?
>

Hm, I don't know. I'll just go with it and see if it causes any problems.


Thanks,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110210/f979363a/attachment.html>

From ekh.johan at gmail.com  Fri Feb 11 11:28:41 2011
From: ekh.johan at gmail.com (Johan Ekh)
Date: Fri, 11 Feb 2011 11:28:41 +0100
Subject: [Distutils] Including documentation in distribution?
In-Reply-To: <20110210174216.7655F3A4097@sparrow.telecommunity.com>
References: <AANLkTikmbcaOfzBKMkoRrjbb25S7HGxEVN3eAJ27tZwL@mail.gmail.com>
	<20110210174216.7655F3A4097@sparrow.telecommunity.com>
Message-ID: <AANLkTinMxFj4Xo5T8L6XwqAnmHV=Xjiw4ATskGc+s1_W@mail.gmail.com>

Thank you for your answer!

Sorry for not being clear. This is the first time I need to send my
developed software to other people.


So, let me explain what I want to do.
I have the directory structure above, and in addition my MANIFEST.in
contains one single row:

recursive-include doc/build/html *

I have added the "package_dir = {'':'src'}" to my setup.py as you suggested.

I am still working with my code under "src" and with the documentation under
"doc". I'm on a linux computer.

1.
I need to send my code to windows users. They have Python installed. They
need to run my program
from the commandline in windows. I also would like my html documentation to
be placed in some reasonable
place on their computers.

2.
I would like to easily make a system wide installation of my code and
documentation on my own linux machine.
I need a running version while I continue to develop the software.

What is the best strategy to do this?

Best regards,
Johan



On Thu, Feb 10, 2011 at 6:42 PM, P.J. Eby <pje at telecommunity.com> wrote:

> At 05:20 PM 2/10/2011 +0100, Johan Ekh wrote:
>
>> my setup.py looks like
>>
>> #!/usr/bin/env python
>>
>> from setuptools import setup, find_packages
>>
>> setup(name='cabletlk',
>>      version='0.1',
>>      description='Cable Toolkit',
>>      author='Johan Ekh',
>>      author_email='<mailto:johan.ekh at se.abb.com>johan.ekh at se.abb.com',
>>
>>      packages=['mypkg',],
>>      )
>>
>
> It looks like you're missing a:
>
>   package_dir = {'':'src'}
>
> from that.
>
>
>
>
>  I would like to include the content in "doc/built/html" in my
>> distribution.
>>
>> How can I do that?
>>
>
> If you mean your source distribution, you can do that by putting those
> files in revision control (w/appropriate plugin), or by adding appropriate
> directives to a MANIFEST.in file (see the distutils documentation for
> MANIFEST.in).
>
> If you mean you want to install the docs as data in a certain path for
> specific platforms, see the distutils documentation for the "install_data"
> command.
>
> If you want to include the docs in an .egg distribution or installation,
> you'll need to place them either under your .egg-info directory, or else put
> them inside mypkg/ and use include_package_data=True or the package_data={}
> directives.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110211/ab1fd911/attachment-0001.html>

From rafael at nexedi.com  Fri Feb 11 14:07:23 2011
From: rafael at nexedi.com (Rafael Monnerat)
Date: Fri, 11 Feb 2011 11:07:23 -0200
Subject: [Distutils] extends-cache
Message-ID: <4D55348B.705@nexedi.com>


Hi,

I would like to check a behaviour on zc.buildout when some URL is used 
in extends.

Here is my scenario:

-- buildout.cfg --
[buildout]
extends =
http://url/to/file.cfg
http://url/to/file2.cfg

-- http://url/to/file.cfg --
[buildout]
extends =
http://url/to/sample1.cfg

-- http://url/to/file2.cfg --
[buildout]
extends =
http://url/to/sample1.cfg

I found that the file http://url/to/sample1.cfg is downloaded twice in 
the same run when I use buildout or bootstrap.py, even if the file is 
already present into the extends-cache.

1) Is there a way to avoid download twice?

2) Is there a way to not update extends-cache all the time? I found 
"bin/buildout -N" still downloading extends.

PS.: If it looks like a bug, I'm volunteer to fix it.

Regards,
Rafael Monnerat

From rafael at tiolive.com  Fri Feb 11 13:18:34 2011
From: rafael at tiolive.com (Rafael Monnerat)
Date: Fri, 11 Feb 2011 10:18:34 -0200
Subject: [Distutils] extends-cache
Message-ID: <4D55291A.4040808@tiolive.com>


Hi,

I would like to check a behaviour on zc.buildout when some URL is used 
in extends.

Here is my scenario:

-- buildout.cfg --
[buildout]
extends =
http://url/to/file.cfg
http://url/to/file2.cfg

-- http://url/to/file.cfg --
[buildout]
extends =
http://url/to/sample1.cfg

-- http://url/to/file2.cfg --
[buildout]
extends =
http://url/to/sample1.cfg

I found that the file http://url/to/sample1.cfg is downloaded twice in 
the same run when I use buildout or bootstrap.py, even if the file is 
already present into the extends-cache.

1) Is there a way to avoid download twice?

2) Is there a way to not update extends-cache all the time? I found 
"bin/buildout -N" still downloading extends.

PS.: If it looks like a bug, I'm volunteer to fix it.

Regards,
Rafael Monnerat

From cool-rr at cool-rr.com  Sat Feb 12 14:19:46 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Sat, 12 Feb 2011 08:19:46 -0500
Subject: [Distutils] Testing modules from PyPI
Message-ID: <AANLkTim0RHbAtn5r9GQ-h0ccSr2qUGCQRXjYy+C0PzG5@mail.gmail.com>

Hello,

What would be a good workflow to do post-release testing of my PyPI
packages? That is, I make a new release on PyPI, and I want to install it on
a VM and run the tests on the installed version. What would be a good way to
do it?


Thanks,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110212/b3555472/attachment.html>

From thomas at thomas-lotze.de  Sun Feb 13 11:05:56 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Sun, 13 Feb 2011 11:05:56 +0100
Subject: [Distutils] extends-cache
References: <4D55291A.4040808@tiolive.com>
Message-ID: <pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>

Rafael Monnerat wrote:

> I found that the file http://url/to/sample1.cfg is downloaded twice in the
> same run when I use buildout or bootstrap.py, even if the file is already
> present into the extends-cache.

This is probably because the code that downloads that config file uses the
cache in fall-back mode, i.e. it always tries to get a fresh version of
the file (and update the cache with it) and uses a cached copy only when
offline.

> 1) Is there a way to avoid download twice?

Since the download utility doesn't know about the needs of the code
calling it (which is a good thing in terms of orthogonality), the part of
the buildout code which recursively evaluates the config files that extend
each other would have to be changed to remember which files it already
downloaded. It could then either reuse them instead of calling the
download utility again, or use the download utility's regular cache mode
for any further downloads of the same file.

> PS.: If it looks like a bug, I'm volunteer to fix it.

If you implement the above (or something better) on a branch, I'd be happy
to review it.

BTW, this raises the question whether the fall-back mode of the cache
should be made selectable with each call to a download utility. Currently,
fall-back mode can only be configured when first instantiating a download
utility (or by overriding its "fallback" attribute later, which would be
ugly as a usage pattern).

-- 
Thomas




From thomas at thomas-lotze.de  Sun Feb 13 11:06:35 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Sun, 13 Feb 2011 11:06:35 +0100
Subject: [Distutils] zc.buildout: download utility vs. local resources
Message-ID: <pan.2011.02.13.10.06.35.871680@ID-174572.user.uni-berlin.de>

Hi all,

I'm currently second-guessing a detail of the zc.buildout's
download utility I wrote last year (*) and I want to ask for
others' opinions.

What I question is how the settings for cache usage and download
destination end up determining whether the copy of the resource
that client code receives is private to the buildout, or shared.
The current logic involves an optimisation that tries to avoid
copying files in the file system by creating hard links instead
if possible. (**)

I'd like to make the decision about using a private or shared
copy more explicit and foreseeable. The obvious way to do this is
adding another keyword parameter to the download call that
expresses whether hard-linking should be attempted. I'm however
not at all clear on what would be a sensible default value:

Using a shared copy may not be desirable if client code is going
to modify the file after downloading, so attempting to create
hard links by default is the more dangerous behaviour. Always
copying, on the other hand, means that when using a cache (or
"downloading" a file-system resource) every download creates
multiple copies of potentially large files in the file system,
which is unnecessary in what I think is the majority of cases.

It would be very helpful if someone could offer some input.
Thank you.

Thomas


(*) The download utility is an API inside zc.buildout that can be
used by recipes or zc.buildout itself to download HTTP or
file-system resources. It can be configured to use a download
cache and to put the downloaded resource in a particular place.
In any case, it returns the file-system path of that copy of the
downloaded resource which is to be used by the client code.

(**) If an HTTP resource is downloaded,

* having neither a cache nor a download destination puts the
  resource at a temporary path unique to the current download
  call,

* using a cache but no download destination results in accessing
  the (shared) file inside the cache,

* if using a download destination but no cache, a private copy of
  the resource is put in the destination,

* if using both a cache and a download destination, the utility
  tries to hard-link the cached file to the destination and
  failing that, copies it, so the result may be either a private
  copy or a shared one.

If the resource comes from the file system,

* using no download destination results in shared access to
  either the original or cached resource,

* specifying a download destination results in accessing either a
  shared or private copy of the resource depending on whether
  hard links from its original or cached path to the download
  destination are possible.



From rafael at nexedi.com  Sun Feb 13 21:11:40 2011
From: rafael at nexedi.com (Rafael Monnerat)
Date: Sun, 13 Feb 2011 18:11:40 -0200
Subject: [Distutils] extends-cache
In-Reply-To: <pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>
References: <4D55291A.4040808@tiolive.com>
	<pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>
Message-ID: <4D583AFC.7090208@nexedi.com>


Hi,

I posted the bugs (I think are 2 diferent) into launchpad with my 
patches which I made on friday:

   - https://bugs.launchpad.net/zc.buildout/+bug/717730

   - https://bugs.launchpad.net/zc.buildout/+bug/717802

You are right about fall-back, I used the "ugly" way to not change 
download utility API.

Feel free to comment, I can update my patch.

Regards,
Rafael Monnerat



On 13-02-2011 08:05, Thomas Lotze wrote:
> Rafael Monnerat wrote:
>
>> I found that the file http://url/to/sample1.cfg is downloaded twice in the
>> same run when I use buildout or bootstrap.py, even if the file is already
>> present into the extends-cache.
> This is probably because the code that downloads that config file uses the
> cache in fall-back mode, i.e. it always tries to get a fresh version of
> the file (and update the cache with it) and uses a cached copy only when
> offline.
>
>> 1) Is there a way to avoid download twice?
> Since the download utility doesn't know about the needs of the code
> calling it (which is a good thing in terms of orthogonality), the part of
> the buildout code which recursively evaluates the config files that extend
> each other would have to be changed to remember which files it already
> downloaded. It could then either reuse them instead of calling the
> download utility again, or use the download utility's regular cache mode
> for any further downloads of the same file.
>
>> PS.: If it looks like a bug, I'm volunteer to fix it.
> If you implement the above (or something better) on a branch, I'd be happy
> to review it.
>
> BTW, this raises the question whether the fall-back mode of the cache
> should be made selectable with each call to a download utility. Currently,
> fall-back mode can only be configured when first instantiating a download
> utility (or by overriding its "fallback" attribute later, which would be
> ugly as a usage pattern).


From tseaver at palladion.com  Mon Feb 14 04:21:19 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Sun, 13 Feb 2011 22:21:19 -0500
Subject: [Distutils] Testing modules from PyPI
In-Reply-To: <AANLkTim0RHbAtn5r9GQ-h0ccSr2qUGCQRXjYy+C0PzG5@mail.gmail.com>
References: <AANLkTim0RHbAtn5r9GQ-h0ccSr2qUGCQRXjYy+C0PzG5@mail.gmail.com>
Message-ID: <ija73d$d9r$1@dough.gmane.org>

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

On 02/12/2011 08:19 AM, cool-RR wrote:

> What would be a good workflow to do post-release testing of my PyPI
> packages? That is, I make a new release on PyPI, and I want to install it on
> a VM and run the tests on the installed version. What would be a good way to
> do it?

I use virtualenv, something like this::

 $ export WHERE=/tmp/test-yourpackage
 $ /path/to/python/bin/virtualenv --no-site-packages $WHERE
 $ $WHERE/bin/easy_install nose coverage
 $ $WHERE/easy_install --always-unzip yourpackage
 $ export TARGET=$WHERE/lib/python2.x/site-packages
 $ $WHERE/bin/nosetests  --where=$TARGET/yourpackage-x.y-python2.x.egg


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/

iEYEARECAAYFAk1Yn68ACgkQ+gerLs4ltQ6iVQCg0SxbRTQMUMRJA9frxpZqqa6i
IWsAn0NyCeQDQs4sGupc/M7OKL6OeIzr
=kA8g
-----END PGP SIGNATURE-----


From thomas at thomas-lotze.de  Mon Feb 14 07:54:30 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Mon, 14 Feb 2011 07:54:30 +0100
Subject: [Distutils] extends-cache
References: <4D55291A.4040808@tiolive.com>
	<pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>
	<4D583AFC.7090208@nexedi.com>
Message-ID: <pan.2011.02.14.06.54.30.129199@ID-174572.user.uni-berlin.de>

Rafael Monnerat wrote:

> I posted the bugs (I think are 2 diferent) into launchpad with my patches
> which I made on friday:

Thank you.

>    - https://bugs.launchpad.net/zc.buildout/+bug/717730

As far as the cache issue is concerned, this patch looks fine by me, but
of course, there should be a test for the changed behaviour.

OTOH, the patch reminds me of a different issue which I've been running
into with buildout a couple of times now: there should be an API somewhere
in zc.buildout that helps resolve string values from config files into
boolean values. I'll remember to bring this up as a separate issue.

>    - https://bugs.launchpad.net/zc.buildout/+bug/717802

* A test for the changed behaviour would be in order in this case as well.

* A set might be a more appropriate data structure than a list for
  collecting the file names seen.

* The empty set of file names should be passed into the first call to
  _open to avoid a mutable object as the default value of downloaded_list.

* The whole logic of the nested if-else blocks might be refactored to get
  rid of code duplication (which has been there all along and becomes even
  more apparent by your patch). Maybe this also makes the appropriate
  fallback value known at the time of instantiating the download utility.

-- 
Thomas




From cool-rr at cool-rr.com  Mon Feb 14 13:51:54 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 14 Feb 2011 07:51:54 -0500
Subject: [Distutils] Testing modules from PyPI
In-Reply-To: <ija73d$d9r$1@dough.gmane.org>
References: <AANLkTim0RHbAtn5r9GQ-h0ccSr2qUGCQRXjYy+C0PzG5@mail.gmail.com>
	<ija73d$d9r$1@dough.gmane.org>
Message-ID: <AANLkTimcm9yGf85p9tB+xUA=G1THHQtpMjmr060B-Hoo@mail.gmail.com>

On Sun, Feb 13, 2011 at 10:21 PM, Tres Seaver <tseaver at palladion.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/12/2011 08:19 AM, cool-RR wrote:
>
> > What would be a good workflow to do post-release testing of my PyPI
> > packages? That is, I make a new release on PyPI, and I want to install it
> on
> > a VM and run the tests on the installed version. What would be a good way
> to
> > do it?
>
> I use virtualenv, something like this::
>
>  $ export WHERE=/tmp/test-yourpackage
>  $ /path/to/python/bin/virtualenv --no-site-packages $WHERE
>  $ $WHERE/bin/easy_install nose coverage
>  $ $WHERE/easy_install --always-unzip yourpackage
>  $ export TARGET=$WHERE/lib/python2.x/site-packages
>  $ $WHERE/bin/nosetests  --where=$TARGET/yourpackage-x.y-python2.x.egg
>
>
> Tres.


Thanks for the suggestion. I do find it to be a bit lengthy.

Eventually I went with installing the `test_garlicsim` package along with
`garlicsim`, and installing a `_test_garlicsim` script on the user's
computer which invokes Nose with the `test_garlicsim` package.


Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110214/d696104d/attachment.html>

From cool-rr at cool-rr.com  Mon Feb 14 14:47:07 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 14 Feb 2011 15:47:07 +0200
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <20110114010136.CA5D33A40F5@sparrow.telecommunity.com>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>
	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>
	<20110113151149.2C5113A48BF@sparrow.telecommunity.com>
	<AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>
	<4D2F6E1C.3050001@v.loewis.de>
	<AANLkTik01532D63NLhp9bVxKdLGrF=_Rxkt8qxThov=F@mail.gmail.com>
	<4D2F7287.9050309@v.loewis.de>
	<20110114010136.CA5D33A40F5@sparrow.telecommunity.com>
Message-ID: <AANLkTimBJOSFBc25hQ-eoUc5WxywFE9YHHt2HMHnC+W4@mail.gmail.com>

On Fri, Jan 14, 2011 at 3:01 AM, P.J. Eby <pje at telecommunity.com> wrote:

> At 10:45 PM 1/13/2011 +0100, Martin v. L?wis wrote:
>
>> How is that generated (i.e. what piece of code specifically generates it)?
>>
>
> See setuptools.command.install_scripts.run() - it makes .exe and -
> script.py/-script.pyw files.  It has some hackery to detect bdist_wininst
> and use a relative #! line in that case, but it doesn't have equivalent
> hackery for bdist_msi.
>
>
P.J., do you think it will suffice to patch Distribute here:

https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34

<https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34>To
detect bdist_msi as well?


Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110214/4cdae93a/attachment.html>

From rafael at nexedi.com  Mon Feb 14 15:45:58 2011
From: rafael at nexedi.com (Rafael Monnerat)
Date: Mon, 14 Feb 2011 12:45:58 -0200
Subject: [Distutils] extends-cache
In-Reply-To: <pan.2011.02.14.06.54.30.129199@ID-174572.user.uni-berlin.de>
References: <4D55291A.4040808@tiolive.com>	<pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>	<4D583AFC.7090208@nexedi.com>
	<pan.2011.02.14.06.54.30.129199@ID-174572.user.uni-berlin.de>
Message-ID: <4D594026.6030506@nexedi.com>


Thank you for review.

On 14-02-2011 04:54, Thomas Lotze wrote:
> Rafael Monnerat wrote:
>
>> I posted the bugs (I think are 2 diferent) into launchpad with my patches
>> which I made on friday:
> Thank you.
>
>>     - https://bugs.launchpad.net/zc.buildout/+bug/717730
> As far as the cache issue is concerned, this patch looks fine by me, but
> of course, there should be a test for the changed behaviour.
Ok, I will write it and update the patch.

> OTOH, the patch reminds me of a different issue which I've been running
> into with buildout a couple of times now: there should be an API somewhere
> in zc.buildout that helps resolve string values from config files into
> boolean values. I'll remember to bring this up as a separate issue.
After search a little bit I found the API:

"Options.get_bool" on buildout.py

So I think I should use "_dl_options.get_bool('newest')" instead.

>>     - https://bugs.launchpad.net/zc.buildout/+bug/717802
Ok, I agree with your recommendations. I will update the patch soon.
> * A test for the changed behaviour would be in order in this case as well.
>
> * A set might be a more appropriate data structure than a list for
>    collecting the file names seen.
>
> * The empty set of file names should be passed into the first call to
>    _open to avoid a mutable object as the default value of downloaded_list.
>
> * The whole logic of the nested if-else blocks might be refactored to get
>    rid of code duplication (which has been there all along and becomes even
>    more apparent by your patch). Maybe this also makes the appropriate
>    fallback value known at the time of instantiating the download utility.
>


From pje at telecommunity.com  Mon Feb 14 16:32:46 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 14 Feb 2011 10:32:46 -0500
Subject: [Distutils] .exe for script in Windows doesn't work
Message-ID: <20110214153259.A71493A406A@sparrow.telecommunity.com>

At 03:47 PM 2/14/2011 +0200, cool-RR wrote:
>On Fri, Jan 14, 2011 at 3:01 AM, P.J. Eby 
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>At 10:45 PM 1/13/2011 +0100, Martin v. L?wis wrote:
>How is that generated (i.e. what piece of code specifically generates it)?
>
>
>See setuptools.command.install_scripts.run() - it makes .exe and 
>-<http://script.py/-script.pyw>script.py/-script.pyw files.  It has 
>some hackery to detect bdist_wininst and use a relative #! line in 
>that case, but it doesn't have equivalent hackery for bdist_msi.
>
>
>P.J., do you think it will suffice to patch Distribute here:
>
><https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34>https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34
>
>To detect bdist_msi as well?

No.  If it were that simple, I'd already have done it.


From thomas at thomas-lotze.de  Mon Feb 14 16:34:35 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Mon, 14 Feb 2011 16:34:35 +0100
Subject: [Distutils] extends-cache
References: <4D55291A.4040808@tiolive.com>
	<pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>
	<4D583AFC.7090208@nexedi.com>
	<pan.2011.02.14.06.54.30.129199@ID-174572.user.uni-berlin.de>
	<4D594026.6030506@nexedi.com>
Message-ID: <pan.2011.02.14.15.34.34.140780@ID-174572.user.uni-berlin.de>

Rafael Monnerat wrote:

> After search a little bit I found the API:
> 
> "Options.get_bool" on buildout.py
> 
> So I think I should use "_dl_options.get_bool('newest')" instead.

Nice, somehow this has managed to escape me until now. I think I'll use it
in a couple places, then, including the download utility itself.

> Ok, I agree with your recommendations. I will update the patch soon.

Tell me when you're done, I'll have another look at it then.

-- 
Thomas




From cool-rr at cool-rr.com  Mon Feb 14 17:49:34 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 14 Feb 2011 18:49:34 +0200
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <20110214153223.6F3F03A406A@sparrow.telecommunity.com>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>
	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>
	<20110113151149.2C5113A48BF@sparrow.telecommunity.com>
	<AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>
	<4D2F6E1C.3050001@v.loewis.de>
	<AANLkTik01532D63NLhp9bVxKdLGrF=_Rxkt8qxThov=F@mail.gmail.com>
	<4D2F7287.9050309@v.loewis.de>
	<20110114010136.CA5D33A40F5@sparrow.telecommunity.com>
	<AANLkTimBJOSFBc25hQ-eoUc5WxywFE9YHHt2HMHnC+W4@mail.gmail.com>
	<20110214153223.6F3F03A406A@sparrow.telecommunity.com>
Message-ID: <AANLkTi=zhr75Od_6TxJjQwR4ekJmQEESoYA0h+gdmY+1@mail.gmail.com>

On Mon, Feb 14, 2011 at 5:32 PM, P.J. Eby <pje at telecommunity.com> wrote:

> At 03:47 PM 2/14/2011 +0200, cool-RR wrote:
>
>> On Fri, Jan 14, 2011 at 3:01 AM, P.J. Eby <<mailto:pje at telecommunity.com>
>> pje at telecommunity.com> wrote:
>> At 10:45 PM 1/13/2011 +0100, Martin v. L?wis wrote:
>> How is that generated (i.e. what piece of code specifically generates it)?
>>
>>
>> See setuptools.command.install_scripts.run() - it makes .exe and -<
>> http://script.py/-script.pyw>script.py/-script.pyw files.  It has some
>> hackery to detect bdist_wininst and use a relative #! line in that case, but
>> it doesn't have equivalent hackery for bdist_msi.
>>
>>
>>
>> P.J., do you think it will suffice to patch Distribute here:
>>
>> <
>> https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34
>> >
>> https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34
>>
>>
>> To detect bdist_msi as well?
>>
>
> No.  If it were that simple, I'd already have done it.
>

So... Should I open a ticket on the Distribute project?


Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110214/cbd9f34e/attachment-0001.html>

From pje at telecommunity.com  Mon Feb 14 20:47:38 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 14 Feb 2011 14:47:38 -0500
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <AANLkTi=zhr75Od_6TxJjQwR4ekJmQEESoYA0h+gdmY+1@mail.gmail.c
 om>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>
	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>
	<20110113151149.2C5113A48BF@sparrow.telecommunity.com>
	<AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>
	<4D2F6E1C.3050001@v.loewis.de>
	<AANLkTik01532D63NLhp9bVxKdLGrF=_Rxkt8qxThov=F@mail.gmail.com>
	<4D2F7287.9050309@v.loewis.de>
	<20110114010136.CA5D33A40F5@sparrow.telecommunity.com>
	<AANLkTimBJOSFBc25hQ-eoUc5WxywFE9YHHt2HMHnC+W4@mail.gmail.com>
	<20110214153223.6F3F03A406A@sparrow.telecommunity.com>
	<AANLkTi=zhr75Od_6TxJjQwR4ekJmQEESoYA0h+gdmY+1@mail.gmail.com>
Message-ID: <20110214194759.9C8743A406A@sparrow.telecommunity.com>

At 06:49 PM 2/14/2011 +0200, cool-RR wrote:
>So... Should I open a ticket on the Distribute project?

If you like.  But http://bugs.python.org/setuptools/issue112 already 
exists, and I believe the Distribute project still shadows 
setuptools' bug tracker.  (I could be wrong about that.)


From ronaldoussoren at mac.com  Tue Feb 15 13:42:02 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 15 Feb 2011 13:42:02 +0100
Subject: [Distutils] distutils & OS X universal binaries
In-Reply-To: <52844.79629.qm@web94914.mail.in2.yahoo.com>
References: <52844.79629.qm@web94914.mail.in2.yahoo.com>
Message-ID: <B5849DE1-8DCC-429F-BF89-47538CC2D8C2@mac.com>


On 10 Feb, 2011, at 13:36, Prashant Saxena wrote:

> Hi,
> 
> I am new on Mac platform. I need to port an application from linux to mac. There 
> are couple of custom c-extensions which I am building using cython on linux 
> using distutils. It's pretty simple and straight forward there.
> There are couple of things I need to know on Mac platform.
> 
> Q1. How do I create custom c-extension (cython & distutils) on mac so that they 
> should run on both architecture (ppc & Intel)?

If cython doesn't do anything special: just use a universal build of python to build the extension.

> 
> Q2. I am on 32 bit platform and I have to make sure that deployed package 
> (py2app) should execute on 64-bit architecture also.

What is your question?

32-bit binaries will work just fine on system that is 64-bit capable. If you cannot test 64-bit binaries on your machine I'd only ship a 32-bit binary.

> 
> Q3. Mine is Leopard 10.5.5(intel) and default python is 2.5.1 but my app 
> requires 2.6.6. How do I build python 2.6.6 in universal binary format?

There are two options:

1) Download the 2.6.6 installer from the python.org website

2) Built it yourself using 'configure --enable-universalsdk=/  MACOSX_DEPLOYMENT_TARGET=10.5'
     (replace 10.5 by the earliest OSX version you want to support)

Ronald


> 
> Overall idea is to deploy a package on mac 10.5.5 leopard(intel 32 bit) using 
> py2app in such a way so that it's compatible for both architecture (ppc & intel) 
> and both platforms(32-bit & 64-bit)
> 
> Cheers
> 
> Prashant
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From lukas.hetzenecker at gmail.com  Tue Feb 15 17:43:07 2011
From: lukas.hetzenecker at gmail.com (Lukas Hetzenecker)
Date: Tue, 15 Feb 2011 17:43:07 +0100
Subject: [Distutils] distutils extension for dbus service files
Message-ID: <4d5aad1d.0918cd0a.47c9.1d20@mx.google.com>

Hello,

I've created an extension for distutils which reads D-Bus *.service.in files, 
replaces macros in these files (e.g. @bindir@) and copies them to the 
appropriate location (e. g. /usr/share/dbus-1/services/ or 
$HOME/.local/share/dbus-1/services in user-mode). 

I couldn't find much useful information for this task in the distutils 
documentation, so I tried to accomplish this by reading through the source 
code of the distutils commands.

Is the attached python script the right way to handle this situation or could 
this be achieved easier?
If this is the correct way to do this I'll also write similar methods for 
handling PyQt4 ui and translation files.

This is an example for a setup.py script

from oms_distutils import setup
setup(name='example',
      version='1.0',
      package_dir={'example': 'src'},
      packages=['example.lib'],
      dbus_files=['data/com.example.test.service.in'],
      )

And this is the com.example.test.service.in file:
[D-BUS Service]
Name=com.example.test
Exec=@bindir@/example-wrapper


Thanks for your comments,
Lukas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oms_distutils.py
Type: text/x-python
Size: 6237 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110215/0d73ac88/attachment.py>

From fdrake at acm.org  Tue Feb 15 17:57:47 2011
From: fdrake at acm.org (Fred Drake)
Date: Tue, 15 Feb 2011 11:57:47 -0500
Subject: [Distutils] distutils extension for dbus service files
In-Reply-To: <4d5aad1d.0918cd0a.47c9.1d20@mx.google.com>
References: <4d5aad1d.0918cd0a.47c9.1d20@mx.google.com>
Message-ID: <AANLkTi=V_K+tZ0n-M2QJ+aj08E=sNunAVEe_1GSvyBqM@mail.gmail.com>

Bare distutils characterizes these as "data" files (*not* "package
data").  There's some documentation on that, but I'm not sure that any
sort of transformation is supported for them.

Specialized commands may need to be inserted to handle those cases cleanly.


? -Fred

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

From rafael at nexedi.com  Tue Feb 15 21:59:18 2011
From: rafael at nexedi.com (Rafael Monnerat)
Date: Tue, 15 Feb 2011 18:59:18 -0200
Subject: [Distutils] extends-cache
In-Reply-To: <pan.2011.02.14.06.54.30.129199@ID-174572.user.uni-berlin.de>
References: <4D55291A.4040808@tiolive.com>	<pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>	<4D583AFC.7090208@nexedi.com>
	<pan.2011.02.14.06.54.30.129199@ID-174572.user.uni-berlin.de>
Message-ID: <4D5AE926.1090609@nexedi.com>


Hi,

I updated my pacth following Thomas recommendations (Attached).

I merged the 2 patches because it was connected and it was good to make 
it cleaner.

Feel free to review (and apply/branch if ok),

Regards,
Rafael Monnerat

PS.: My english is not so good, so few free to improve my text on doctest :)


On 14-02-2011 04:54, Thomas Lotze wrote:
> Rafael Monnerat wrote:
>
>> I posted the bugs (I think are 2 diferent) into launchpad with my patches
>> which I made on friday:
> Thank you.
>
>>     - https://bugs.launchpad.net/zc.buildout/+bug/717730
> As far as the cache issue is concerned, this patch looks fine by me, but
> of course, there should be a test for the changed behaviour.
>
> OTOH, the patch reminds me of a different issue which I've been running
> into with buildout a couple of times now: there should be an API somewhere
> in zc.buildout that helps resolve string values from config files into
> boolean values. I'll remember to bring this up as a separate issue.
>
>>     - https://bugs.launchpad.net/zc.buildout/+bug/717802
> * A test for the changed behaviour would be in order in this case as well.
>
> * A set might be a more appropriate data structure than a list for
>    collecting the file names seen.
>
> * The empty set of file names should be passed into the first call to
>    _open to avoid a mutable object as the default value of downloaded_list.
>
> * The whole logic of the nested if-else blocks might be refactored to get
>    rid of code duplication (which has been there all along and becomes even
>    more apparent by your patch). Maybe this also makes the appropriate
>    fallback value known at the time of instantiating the download utility.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildout_fixForBugs717802And717730.patch
Type: text/x-diff
Size: 3069 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110215/31a44360/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: extends-cache_testForBugs717802And717730.patch
Type: text/x-diff
Size: 3172 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110215/31a44360/attachment-0003.patch>

From ekh.johan at gmail.com  Tue Feb 15 22:46:04 2011
From: ekh.johan at gmail.com (Johan Ekh)
Date: Tue, 15 Feb 2011 22:46:04 +0100
Subject: [Distutils] Including documentation in distribution?
In-Reply-To: <AANLkTinMxFj4Xo5T8L6XwqAnmHV=Xjiw4ATskGc+s1_W@mail.gmail.com>
References: <AANLkTikmbcaOfzBKMkoRrjbb25S7HGxEVN3eAJ27tZwL@mail.gmail.com>
	<20110210174216.7655F3A4097@sparrow.telecommunity.com>
	<AANLkTinMxFj4Xo5T8L6XwqAnmHV=Xjiw4ATskGc+s1_W@mail.gmail.com>
Message-ID: <AANLkTik=A++-+HOJAZ3yrtYecM26Q_zGh78DB55svG0+@mail.gmail.com>

Can someone please help a poor newbie in trouble?

BR / Johan

On Fri, Feb 11, 2011 at 11:28 AM, Johan Ekh <ekh.johan at gmail.com> wrote:

> Thank you for your answer!
>
> Sorry for not being clear. This is the first time I need to send my
> developed software to other people.
>
>
> So, let me explain what I want to do.
> I have the directory structure above, and in addition my MANIFEST.in
> contains one single row:
>
> recursive-include doc/build/html *
>
> I have added the "package_dir = {'':'src'}" to my setup.py as you
> suggested.
>
> I am still working with my code under "src" and with the documentation
> under "doc". I'm on a linux computer.
>
> 1.
> I need to send my code to windows users. They have Python installed. They
> need to run my program
> from the commandline in windows. I also would like my html documentation to
> be placed in some reasonable
> place on their computers.
>
> 2.
> I would like to easily make a system wide installation of my code and
> documentation on my own linux machine.
> I need a running version while I continue to develop the software.
>
> What is the best strategy to do this?
>
> Best regards,
> Johan
>
>
>
>
> On Thu, Feb 10, 2011 at 6:42 PM, P.J. Eby <pje at telecommunity.com> wrote:
>
>> At 05:20 PM 2/10/2011 +0100, Johan Ekh wrote:
>>
>>> my setup.py looks like
>>>
>>> #!/usr/bin/env python
>>>
>>> from setuptools import setup, find_packages
>>>
>>> setup(name='cabletlk',
>>>      version='0.1',
>>>      description='Cable Toolkit',
>>>      author='Johan Ekh',
>>>      author_email='<mailto:johan.ekh at se.abb.com>johan.ekh at se.abb.com',
>>>
>>>      packages=['mypkg',],
>>>      )
>>>
>>
>> It looks like you're missing a:
>>
>>   package_dir = {'':'src'}
>>
>> from that.
>>
>>
>>
>>
>>  I would like to include the content in "doc/built/html" in my
>>> distribution.
>>>
>>> How can I do that?
>>>
>>
>> If you mean your source distribution, you can do that by putting those
>> files in revision control (w/appropriate plugin), or by adding appropriate
>> directives to a MANIFEST.in file (see the distutils documentation for
>> MANIFEST.in).
>>
>> If you mean you want to install the docs as data in a certain path for
>> specific platforms, see the distutils documentation for the "install_data"
>> command.
>>
>> If you want to include the docs in an .egg distribution or installation,
>> you'll need to place them either under your .egg-info directory, or else put
>> them inside mypkg/ and use include_package_data=True or the package_data={}
>> directives.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110215/dc6bd9f0/attachment.html>

From daniele.varrazzo at gmail.com  Wed Feb 16 11:35:48 2011
From: daniele.varrazzo at gmail.com (Daniele Varrazzo)
Date: Wed, 16 Feb 2011 10:35:48 +0000
Subject: [Distutils] easy_install installing beta version of psycopg2
Message-ID: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>

Hello,

trying to install psycopg2 via easy_install (distribute 0.6.14), the
user received the version 2.4 beta2 instead of the latest stable
2.3.1.

2.4 beta2 has never been uploaded on PyPI and is not even listed in
the http://pypi.python.org/simple/psycopg2/

I think this is a serious issue. Any solution? Thanks.

-- Daniele

From thomas at thomas-lotze.de  Wed Feb 16 16:54:01 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Wed, 16 Feb 2011 16:54:01 +0100
Subject: [Distutils] extends-cache
References: <4D55291A.4040808@tiolive.com>
	<pan.2011.02.13.10.05.56.539201@ID-174572.user.uni-berlin.de>
	<4D583AFC.7090208@nexedi.com>
	<pan.2011.02.14.06.54.30.129199@ID-174572.user.uni-berlin.de>
	<4D5AE926.1090609@nexedi.com>
Message-ID: <pan.2011.02.16.15.53.59.519558@ID-174572.user.uni-berlin.de>

Rafael Monnerat wrote:

> Feel free to review (and apply/branch if ok),

I've made some small adjustments and applied the patch to the zc.buildout
trunk.

> PS.: My english is not so good, so few free to improve my text on doctest
> :)

I rewrote most of the text to turn it more into documentation with
examples rather than a series of tests with some added comments. Also, the
patch to the download utility should actually not be necessary, that's
what logging is there for. Since I couldn't get logging to do what the
test needs at first try, I at least rewrote the patch to not rely on the
fallback option which is an implementation detail, and added a line that
removes the patch after the one test it was meant for.

Thank you for bringing up and fixing this issue!

-- 
Thomas




From thomas at thomas-lotze.de  Wed Feb 16 17:09:03 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Wed, 16 Feb 2011 17:09:03 +0100
Subject: [Distutils] zc.buildout: the extended-by option
Message-ID: <pan.2011.02.16.16.08.53.187064@ID-174572.user.uni-berlin.de>

Hi,

the buildout section used to have an option named "extended-by" that has
been deprecated for quite a while. The option is not (no longer?) present
in documentation and tests and the only thing left of it is the
implementation and a check that is supposed to result in a deprecation
warning. However, there's a bug in the implementation that looks as if it
was caused by some refactoring, which would cause a NameError to be raised
instead of the deprecation warning being printed.

To me, this looks as if it was safe to just remove any traces of the
option, including the buggy implementation. The only downside would be
that configurations which still use the option would fail silently
instead of raising the NameError. I don't consider this to be of much
importance in practice, but before going ahead and removing code, I wanted
to give people a chance to disagree. Thank you.

-- 
Thomas




From jim at zope.com  Wed Feb 16 17:30:42 2011
From: jim at zope.com (Jim Fulton)
Date: Wed, 16 Feb 2011 11:30:42 -0500
Subject: [Distutils] zc.buildout: the extended-by option
In-Reply-To: <pan.2011.02.16.16.08.53.187064@ID-174572.user.uni-berlin.de>
References: <pan.2011.02.16.16.08.53.187064@ID-174572.user.uni-berlin.de>
Message-ID: <AANLkTind1urTr7ym9C9FN=J2Vra=m9xeSX=98MLJTAGp@mail.gmail.com>

On Wed, Feb 16, 2011 at 11:09 AM, Thomas Lotze <thomas at thomas-lotze.de> wrote:
> Hi,
>
> the buildout section used to have an option named "extended-by" that has
> been deprecated for quite a while. The option is not (no longer?) present
> in documentation and tests and the only thing left of it is the
> implementation and a check that is supposed to result in a deprecation
> warning. However, there's a bug in the implementation that looks as if it
> was caused by some refactoring, which would cause a NameError to be raised
> instead of the deprecation warning being printed.
>
> To me, this looks as if it was safe to just remove any traces of the
> option, including the buggy implementation. The only downside would be
> that configurations which still use the option would fail silently
> instead of raising the NameError. I don't consider this to be of much
> importance in practice, but before going ahead and removing code, I wanted
> to give people a chance to disagree. Thank you.

+1

Perhaps add a check and raise an error if the option is present.

Jim

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

From tseaver at palladion.com  Wed Feb 16 17:37:07 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 16 Feb 2011 11:37:07 -0500
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
Message-ID: <ijgufi$rcp$1@dough.gmane.org>

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

On 02/16/2011 05:35 AM, Daniele Varrazzo wrote:
> Hello,
> 
> trying to install psycopg2 via easy_install (distribute 0.6.14), the
> user received the version 2.4 beta2 instead of the latest stable
> 2.3.1.
> 
> 2.4 beta2 has never been uploaded on PyPI and is not even listed in
> the http://pypi.python.org/simple/psycopg2/
> 
> I think this is a serious issue. Any solution? Thanks.

easy_install is finding the link to 2.4 beta2 on the homepage
(http://initd.org/psycopg/) listed for the 2.3.2 release.  This is
documented behavior, FWIW:

 http://peak.telecommunity.com/DevCenter/EasyInstall#id6

You could work around that issue using '--allow-hosts' to restrict
downloads to those actually on PyPI:

 http://peak.telecommunity.com/DevCenter/EasyInstall#id13


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/

iEYEARECAAYFAk1b/TMACgkQ+gerLs4ltQ6LWACfVlH84UIFfQl4durQZdpvEVBl
JPcAn0m2GjSIzg4gbi47jxJix+dihuxn
=mvL8
-----END PGP SIGNATURE-----


From daniele.varrazzo at gmail.com  Wed Feb 16 18:47:35 2011
From: daniele.varrazzo at gmail.com (Daniele Varrazzo)
Date: Wed, 16 Feb 2011 17:47:35 +0000
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
Message-ID: <AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>

> On Wed, Feb 16, 2011 at 10:35 AM, Daniele Varrazzo <daniele.varrazzo at gmail.com> wrote:
>> Hello,
>>
>> trying to install psycopg2 via easy_install (distribute 0.6.14), the
>> user received the version 2.4 beta2 instead of the latest stable
>> 2.3.1.
>>
>> 2.4 beta2 has never been uploaded on PyPI and is not even listed in
>> the http://pypi.python.org/simple/psycopg2/
>>
>> I think this is a serious issue. Any solution? Thanks.

Tres Seave Wrote:
> easy_install is finding the link to 2.4 beta2 on the homepage
> (http://initd.org/psycopg/) listed for the 2.3.2 release.  This is
> documented behavior, FWIW:
>
> http://peak.telecommunity.com/DevCenter/EasyInstall#id6

What I read is that "easy_install <name>" "Install a package by name,
searching PyPI for the latest version, and automatically downloading,
building, and installing it." PyPI has unambiguous specification that
the latest stable release is "2.3.2": parsing the download page is a
type of intelligence I don't expect to work. Otherwise what is the
point of avoiding uploading beta releases on PyPI?

> You could work around that issue using '--allow-hosts' to restrict
> downloads to those actually on PyPI:
>
> http://peak.telecommunity.com/DevCenter/EasyInstall#id13

This solution is for the easy_install user installing the module, as
much as explicitly specifying a revision. This implies that the user
knows there is a problem with easy_install and he may not get what
expected (i.e. a production-ready release), which is a possibility
that I honestly didn't even consider until yesterday.

I am not a module user instead: I am the packager of the module, and I
know what the users want in case they don't ask for a specific release
in the past or in the future, so I took care to specify it on PyPI. Do
I, as a packager, have the possibility to say "what I have specified
on PyPI as stable release is exactly what I mean"?

On PyPI there is *a single* version not hidden of psycopg. On
http://pypi.python.org/pypi/psycopg2 there is a big fat link to a
"psycopg2-2.3.2.tar.gz" package. There is really *no temptation to
guess*. Why does easy_install follow a page meant for human,
containing more than one link, and then download one of them at
random? Sorry but I am really not getting the point of this effort.

Is there a tool I can suggest to the users instead of easy_install to
install the correct version from pypi, and possibly not requiring a
writable egg cache (see
http://stackoverflow.com/questions/4212240/importerror-cannot-import-name-tz-psycopg2)
to further complicate their lives?

Thank you.

-- Daniele

From martin at v.loewis.de  Wed Feb 16 21:09:28 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 16 Feb 2011 21:09:28 +0100
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
Message-ID: <4D5C2EF8.60505@v.loewis.de>

> On PyPI there is *a single* version not hidden of psycopg. On
> http://pypi.python.org/pypi/psycopg2 there is a big fat link to a
> "psycopg2-2.3.2.tar.gz" package.

easy_install doesn't consider this page at all (anymore). Instead,
it considers the "simple" API, which lists the files uploaded to
PyPI and the download urls alike.

> There is really *no temptation to
> guess*. Why does easy_install follow a page meant for human,
> containing more than one link, and then download one of them at
> random?

It doesn't download at random. If no version is specified, it downloads
the most recent version.

> Is there a tool I can suggest to the users instead of easy_install to
> install the correct version from pypi

I normally use aptitude to install Python packages. In order to install
from PyPI specifically, I use Google Chrome.

Regards,
Martin

From pje at telecommunity.com  Wed Feb 16 21:40:35 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 16 Feb 2011 15:40:35 -0500
Subject: [Distutils] easy_install installing beta version of  psycopg2
In-Reply-To: <AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.c
 om>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
Message-ID: <20110216204049.4D6383A406A@sparrow.telecommunity.com>

At 05:47 PM 2/16/2011 +0000, Daniele Varrazzo wrote:
>Do I, as a packager, have the possibility to say "what I have specified
>on PyPI as stable release is exactly what I mean"?

If you don't want easy_install to find it, don't list it on the pages 
referred to in your "Home Page" or "Download URL" on 
PyPI.  Easy_install reads those pages because many package authors do 
not provide directly usable URLs or packages on PyPI.


>possibly not requiring a writable egg cache (see

You can prevent this as a package author, by specifying 
zip_safe=False in your setup() script.


From daniele.varrazzo at gmail.com  Thu Feb 17 01:01:13 2011
From: daniele.varrazzo at gmail.com (Daniele Varrazzo)
Date: Thu, 17 Feb 2011 00:01:13 +0000
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <20110216204049.4D6383A406A@sparrow.telecommunity.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
Message-ID: <AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>

On Wed, Feb 16, 2011 at 8:40 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 05:47 PM 2/16/2011 +0000, Daniele Varrazzo wrote:
>>
>> Do I, as a packager, have the possibility to say "what I have specified
>> on PyPI as stable release is exactly what I mean"?
>
> If you don't want easy_install to find it, don't list it on the pages
> referred to in your "Home Page" or "Download URL" on PyPI. ?Easy_install
> reads those pages because many package authors do not provide directly
> usable URLs or packages on PyPI.

I'm sorry, it is obvious that I have not spent so much time into this
problem as the designer of this feature. But it still don't get the
rationale behind discarding available, non-ambiguous metadata in
favour of screen scraping.

I don't think it is fair to ask to stop listing the beta from the
homepage and the download page of the 2-pages website of the module:
how should I advertise there is a beta around and testing is welcome?
It won't happen that the shortcomings of a package manager will
dictate the content of a website: I find more viable the option to
tell users to stay away from easy_install and install from the sdist,
or to suggest an alternative package manager with a more robust
behaviour - if I found any.

>> possibly not requiring a writable egg cache (see
>
> You can prevent this as a package author, by specifying zip_safe=False in
> your setup() script.

psycopg2 is not zip_safe, as it contains a C extension. Yes, sounds
fishy, but I've not stumbled in the issue myself to debug it. I only
see people reporting the problem and the solution. Will ask further
info to the author of the article quoted.

-- Daniele

From thomas at thomas-lotze.de  Thu Feb 17 07:29:07 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Thu, 17 Feb 2011 07:29:07 +0100
Subject: [Distutils] zc.buildout: the extended-by option
References: <pan.2011.02.16.16.08.53.187064@ID-174572.user.uni-berlin.de>
	<AANLkTind1urTr7ym9C9FN=J2Vra=m9xeSX=98MLJTAGp@mail.gmail.com>
Message-ID: <pan.2011.02.17.06.29.06.635564@ID-174572.user.uni-berlin.de>

Jim Fulton wrote:

>> To me, this looks as if it was safe to just remove any traces of the
>> option, including the buggy implementation. The only downside would be
>> that configurations which still use the option would fail silently
>> instead of raising the NameError. I don't consider this to be of much
>> importance in practice, but before going ahead and removing code, I
>> wanted to give people a chance to disagree. Thank you.
> 
> +1
> 
> Perhaps add a check and raise an error if the option is present.

I've just removed the remains of the option's implementation and added a
check that raises a UserError if an extended-by option is still
encountered in some buildout section.

-- 
Thomas




From thomas at thomas-lotze.de  Thu Feb 17 07:43:18 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Thu, 17 Feb 2011 07:43:18 +0100
Subject: [Distutils] zc.buildout: download utility vs. local resources
References: <pan.2011.02.13.10.06.35.871680@ID-174572.user.uni-berlin.de>
Message-ID: <pan.2011.02.17.06.43.08.395812@ID-174572.user.uni-berlin.de>

Thomas Lotze wrote:

> I'd like to make the decision about using a private or shared copy more
> explicit and foreseeable. The obvious way to do this is adding another
> keyword parameter to the download call that expresses whether hard-linking
> should be attempted. I'm however not at all clear on what would be a
> sensible default value:
> 
> Using a shared copy may not be desirable if client code is going to modify
> the file after downloading, so attempting to create hard links by default
> is the more dangerous behaviour. Always copying, on the other hand, means
> that when using a cache (or "downloading" a file-system resource) every
> download creates multiple copies of potentially large files in the file
> system, which is unnecessary in what I think is the majority of cases.

Since nobody seems to have a strong opinion on the matter, I'm going to go
ahead and use a default value that means creating copies. This feels like
the cleaner solution as it creates no surprises and puts optimisation at
the user's descretion.

-- 
Thomas




From kiorky at cryptelium.net  Thu Feb 17 11:13:35 2011
From: kiorky at cryptelium.net (kiorky)
Date: Thu, 17 Feb 2011 11:13:35 +0100
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
Message-ID: <4D5CF4CF.2040807@cryptelium.net>

You can try zc.buildout :

a simple buildout.cfg like :

[buildout]
parts=scripts
versions=versions
[versions]
psycopg2 = 2.3.1
[scripts]
recipe=minitage.recipe.scripts
interpreter = mypy
eggs = psycopg2
	whateverelse

and you will have a bin/mypy wrapper with psycopg2 in its dependencies


Le 17/02/2011 01:01, Daniele Varrazzo a ?crit :
> On Wed, Feb 16, 2011 at 8:40 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 05:47 PM 2/16/2011 +0000, Daniele Varrazzo wrote:
>>>
>>> Do I, as a packager, have the possibility to say "what I have specified
>>> on PyPI as stable release is exactly what I mean"?
>>
>> If you don't want easy_install to find it, don't list it on the pages
>> referred to in your "Home Page" or "Download URL" on PyPI.  Easy_install
>> reads those pages because many package authors do not provide directly
>> usable URLs or packages on PyPI.
> 
> I'm sorry, it is obvious that I have not spent so much time into this
> problem as the designer of this feature. But it still don't get the
> rationale behind discarding available, non-ambiguous metadata in
> favour of screen scraping.
> 
> I don't think it is fair to ask to stop listing the beta from the
> homepage and the download page of the 2-pages website of the module:
> how should I advertise there is a beta around and testing is welcome?
> It won't happen that the shortcomings of a package manager will
> dictate the content of a website: I find more viable the option to
> tell users to stay away from easy_install and install from the sdist,
> or to suggest an alternative package manager with a more robust
> behaviour - if I found any.
> 
>>> possibly not requiring a writable egg cache (see
>>
>> You can prevent this as a package author, by specifying zip_safe=False in
>> your setup() script.
> 
> psycopg2 is not zip_safe, as it contains a C extension. Yes, sounds
> fishy, but I've not stumbled in the issue myself to debug it. I only
> see people reporting the problem and the solution. Will ask further
> info to the author of the article quoted.
> 
> -- Daniele
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF
Pensez ? l?environnement.
N?imprimez ce courriel que si vous en avez vraiment besoin.



From pje at telecommunity.com  Thu Feb 17 19:57:57 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 17 Feb 2011 13:57:57 -0500
Subject: [Distutils] easy_install installing beta version of  psycopg2
In-Reply-To: <AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.c
 om>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
Message-ID: <20110217185755.F3D933A405C@sparrow.telecommunity.com>

At 12:01 AM 2/17/2011 +0000, Daniele Varrazzo wrote:
>On Wed, Feb 16, 2011 at 8:40 PM, P.J. Eby <pje at telecommunity.com> wrote:
> > At 05:47 PM 2/16/2011 +0000, Daniele Varrazzo wrote:
> >>
> >> Do I, as a packager, have the possibility to say "what I have specified
> >> on PyPI as stable release is exactly what I mean"?
> >
> > If you don't want easy_install to find it, don't list it on the pages
> > referred to in your "Home Page" or "Download URL" on PyPI.  Easy_install
> > reads those pages because many package authors do not provide directly
> > usable URLs or packages on PyPI.
>
>I'm sorry, it is obvious that I have not spent so much time into this
>problem as the designer of this feature. But it still don't get the
>rationale behind discarding available, non-ambiguous metadata in
>favour of screen scraping.

When easy_install was first written, PyPI didn't even support 
*uploading*.  And the quality of available metadata on PyPI is still 
quite sketchy -- many packages will have only one file uploaded for 
an outdated version, but still  have good downloads on their home 
pages or download URLs.

While I realize this can be an inconvenience for the people who DO 
have good metadata, the truth is that there are many packages for 
which "unstable" version numbers are in fact the *best* download 
choice for many users.  Without a uniform versioning system that 
*every* package adheres to (and PEP 386 isn't actually sufficient for 
this yet -- something more like "semantic versioning" is needed), 
there's no way to easily set a policy across projects for "how stable 
a version do you want to download?"

In general, the practice for most projects is to simply publish 
unstable, "don't download this unless you really mean it" versions 
via "development" links, such as links to svn or other 
repositories.  These links don't look like downloads to easy_install, 
except for the #egg=project-version tag that tells it how to 
interpret them, and saying '#egg=myproject-beta' suffices to ensure 
that only a specific installation request for 'myproject==beta' will 
follow the link.

(Unfortunately, this tag does *not* currently override easy_install's 
native interpretation of the link, so tacking '#egg=psycopg-beta' on 
the end of your download links won't stop them being detected as 
future versions.  See below for other workarounds.)


>I don't think it is fair to ask to stop listing the beta from the
>homepage and the download page of the 2-pages website of the module:
>how should I advertise there is a beta around and testing is welcome?

You can make a direct download link, or make the filename not one 
that easy_install will recognize.  For example, if you rename the 
downloads to "beta-psycopg-whatever.*", or use a URL that redirects, 
like /beta-download, that's then redirected by the web server to the 
appropriate file location.  easy_install only looks at links that 
*appear* to be distutils-or-setuptools-generated archives for the 
desired project.

Another alternative is to block easy_install from parsing your home 
page or download links, by simply providing those links inline in 
your PyPI project description, and *removing* the specific fields 
from the current release and all previous releases stored on 
PyPI.  Still another would be to block the 'setuptools' and 
'distribute' user agents from your website, returning 404s.


>the shortcomings of a package manager

Well, technically, this'd be a feature.  Granted, it's only a feature 
for users of projects whose maintainers are *not* keeping a 
well-groomed PyPI page.  ;-)  I guess it is a shortcoming in the 
sense that there ought to be a way to stop it from using this 
feature.  In retrospect, the #egg=proj-ver feature should override 
easy_install's native interpretation of a URL, rather than just 
adding to it, and I think I would be justified in considering this a 
bug worthy of fixing.

Unfortunately, even if I fixed that today, it wouldn't have ANY 
effect on 99% of the field installations of any Python package 
management tools: there are still people using 4 or 5 year old 
versions of easy_install, and a lot of people use Distribute (via 
their OS install), which is a year behind the setuptools trunk on 
various things.  Most other Python package management solutions are 
based on top of easy_install in one way or another, as well.

Pip is the main package manager that uses its own link-finding 
algorithm, but it only supports source installation 
AFAIK.  Distutils2 uses a link-finding algorithm that was lifted 
pretty much verbatim from easy_install, though I think there may have 
been some additions to it since I last looked at it.


> > You can prevent this as a package author, by specifying zip_safe=False in
> > your setup() script.
>
>psycopg2 is not zip_safe, as it contains a C extension.

C extensions don't make a package not-zip-safe - they just mean that 
if you install it zipped, there has to be an egg cache.  The cache is 
used to unzip the C extension.  If you want to force easy_install to 
unzip your package from the get-go, then specifying zip_safe=False 
explicitly is required.  (Of course, a user can still download the 
egg manually or override this on the command line, but that's their 
problem in that case.)


From sienkiew at stsci.edu  Fri Feb 18 00:13:28 2011
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Thu, 17 Feb 2011 18:13:28 -0500
Subject: [Distutils] easy_install installing beta version of  psycopg2
In-Reply-To: <20110217185755.F3D933A405C@sparrow.telecommunity.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>	<20110216204049.4D6383A406A@sparrow.telecommunity.com>	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
	<20110217185755.F3D933A405C@sparrow.telecommunity.com>
Message-ID: <4D5DAB98.1020604@stsci.edu>

P.J. Eby wrote:
>> the shortcomings of a package manager
>
> Well, technically, this'd be a feature.  Granted, it's only a feature 
> for users of projects whose maintainers are *not* keeping a 
> well-groomed PyPI page.  ;-)


easy_install has significant market penetration.  If you make 
easy_install believe the meta-data, then you give the project 
maintainers some incentive to get their meta-data right.  That seems 
more desirable than the current scenario, where a well-behaved project 
is inconvenienced.

I understand that easy_install has to do a balancing act between 
enabling bad behaviour by the project maintainers (i.e. it has to work 
with poorly maintained projects for the benefit of the users) and 
encouraging good behaviour by the project maintainers (again for the 
benefit of the users).  I just think it is acceptable to give the 
projects a little incentive to get it right.


>
> Unfortunately, even if I fixed that today, it wouldn't have ANY effect 
> on 99% of the field installations of any Python package management 
> tools: there are still people using 4 or 5 year old versions of 
> easy_install, and a lot of people use Distribute (via their OS 
> install), which is a year behind the setuptools trunk on various 
> things.  Most other Python package management solutions are based on 
> top of easy_install in one way or another, as well.

If you fix it now, the fixed version might well displace the earlier 
versions in another 4 or 5 years.  If not, you might be having this same 
discussion again in 4 or 5 years.



From daniele.varrazzo at gmail.com  Fri Feb 18 02:22:55 2011
From: daniele.varrazzo at gmail.com (Daniele Varrazzo)
Date: Fri, 18 Feb 2011 01:22:55 +0000
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <20110217185755.F3D933A405C@sparrow.telecommunity.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
	<20110217185755.F3D933A405C@sparrow.telecommunity.com>
Message-ID: <AANLkTi=R4nfxKq=Y69gm_8v0rz8=CgNCRpV7j91S5Bor@mail.gmail.com>

On Thu, Feb 17, 2011 at 6:57 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 12:01 AM 2/17/2011 +0000, Daniele Varrazzo wrote:

>> I'm sorry, it is obvious that I have not spent so much time into this
>> problem as the designer of this feature. But it still don't get the
>> rationale behind discarding available, non-ambiguous metadata in
>> favour of screen scraping.
>
> When easy_install was first written, PyPI didn't even support *uploading*.
> ?And the quality of available metadata on PyPI is still quite sketchy --
> many packages will have only one file uploaded for an outdated version, but
> still ?have good downloads on their home pages or download URLs.

>> the shortcomings of a package manager
>
> Well, technically, this'd be a feature. ?Granted, it's only a feature for
> users of projects whose maintainers are *not* keeping a well-groomed PyPI
> page. ?;-) ?I guess it is a shortcoming in the sense that there ought to be
> a way to stop it from using this feature.

What I understand here is that setuptools/pip/distutils2 had to grow
in intelligence because of the limitation of the data available on
PyPI, in quantity and in quality. I see that this could have been the
situation in the infancy of PyPI, but I don't think this is the case
anymore. PyPI is now the only package repository, people know about
its existence and is willing to have their module there. The quantity
is a solved problem.

But from the picture you describe, it seems to me that the
"intelligence" of the package managers is now an hinder to the
quality. Because setuptools is relatively good at screenscraping
people has little incentive in improving the quality of the metadata
describing their package. I don't think in the long term it will be a
win: in my experience the programs have a limited lifespan, whereas
the databases largely outlive them and end up being the real
*resource*. Good data + ok program: win. Bad data + too good program:
random outcome.

I don't see the need of semantic tagging, nor improved algorithms for
a better packaging system: this is only complexity increasing, maybe
some hack value, but no robustness. Because PyPI is now largely
credited as a good idea, I believe that a *stupid* package manager,
one that only follows the directive made available by the packager on
PyPI would make people *run* to fix their bloody metadata. If they
release foo-1.0.1 and a test shows that "easy_install foo" still
installs 1.0 they will *spring* to move the fat fingers and type
"python setup.py upload". An improvement would be providing a command
"python setup.py test-upload" that would download the package from
PyPI and check that the version matches the one in setup.py.

Of course the disclaimer holds: I haven't spent my hack time after the
reasoning that have led to the birth of pip, zc.buildout, distribute2
after setuptools, so my position is probably naive. But I see a run to
have the most spiffy setup program to work on a pile of trash instead
of using the privileged position you have to encourage a better
environment. If in this very moment setuptools n+1 was released, and
it had the *feature* to install by default the current PyPI version of
the packages, then it would be a bug in pip the fact that it installs
instead the wrong version. At the same moment people would see their
program not being installed anymore by easy_install so they will rush
to update their metadata.

It wouldn't even be difficult to have a list of the "problematic
packages", ones for which the version installed by easy_install is
different from the current PyPI, either for a shortcoming in the
search algorithm as for psycopg2 or because the maintainer has
forgotten to upload. They could receive a mail explaining the
discrepancy and suggesting to fix it, or the metadata may be fixed
once by a PyPI maintainer. I don't expect these packages to be a large
percentage of the current 13365.

End of rambling :) Thank you for the effort, don't think I don't
appreciate it. Have a nice day.

-- Daniele

From chris at simplistix.co.uk  Fri Feb 18 10:00:11 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Feb 2011 09:00:11 +0000
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
Message-ID: <4D5E351B.4020608@simplistix.co.uk>

On 17/02/2011 00:01, Daniele Varrazzo wrote:
>
> I don't think it is fair to ask to stop listing the beta from the
> homepage and the download page of the 2-pages website of the module:

Indeed, but I think it's totally fair to expect users to pin to the 
version they require using whatever package management policy they choose.

Of course, sure, it would be nice if easy_install had a sane default of 
installing only final releases, but what're the chances of PJE 
implementing that? ;-)

What's the "distribute" take on this?

cheers,

Chris

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

From chris at simplistix.co.uk  Fri Feb 18 10:07:35 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Feb 2011 09:07:35 +0000
Subject: [Distutils] [buildout] including optional python packages for
	testing
Message-ID: <4D5E36D7.8050906@simplistix.co.uk>

Hi All,

I'm using buildout to develop a package that uses sqlalchemy and 
sqlalchemy-migrate.

As a result, I'd like to test with various real database drivers; mysql, 
postgres, etc.

However, I don't want to force anyone who wants to check out and run the 
tests to have all supported database drivers available and compiled.

So, I'm looking for some way of specifying "optional eggs" when running 
the buildout, and not in buildout.cfg so they don't accidentally get 
checked in.

How can I achieve this?

cheers,

Chris

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

From ziade.tarek at gmail.com  Fri Feb 18 11:29:55 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 18 Feb 2011 11:29:55 +0100
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <4D5E351B.4020608@simplistix.co.uk>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
	<4D5E351B.4020608@simplistix.co.uk>
Message-ID: <AANLkTi=Ft7LDTgnaO9vaAnOxqkPYUQcoNvvy=PW4pkQF@mail.gmail.com>

On Fri, Feb 18, 2011 at 10:00 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> On 17/02/2011 00:01, Daniele Varrazzo wrote:
>>
>> I don't think it is fair to ask to stop listing the beta from the
>> homepage and the download page of the 2-pages website of the module:
>
> Indeed, but I think it's totally fair to expect users to pin to the version
> they require using whatever package management policy they choose.
>
> Of course, sure, it would be nice if easy_install had a sane default of
> installing only final releases, but what're the chances of PJE implementing
> that? ;-)
>
> What's the "distribute" take on this?

If someone wants to contribute a "--prefer-final" option to Distribute
--extracted from zc.buildout-- I am fine adding it, and even
activating this behavior by default, so people opt in to get the non
final releases.

I think it would be a good way to let the user control the behavior of
the installer better, and that's what zc.buildout wants to do next
AFAIK.

I cannot spend time on Distribute anymore because I am spending all my
free time on Distutils2 -- but contributions are welcome

Cheers
Tarek

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



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

From ziade.tarek at gmail.com  Fri Feb 18 12:30:27 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 18 Feb 2011 12:30:27 +0100
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <20110217185755.F3D933A405C@sparrow.telecommunity.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
	<20110217185755.F3D933A405C@sparrow.telecommunity.com>
Message-ID: <AANLkTi=WR_XtGT-JvvC9yiPdhWg0jjXQ3zC1F60nv+u-@mail.gmail.com>

On Thu, Feb 17, 2011 at 7:57 PM, P.J. Eby <pje at telecommunity.com> wrote:
...
>
> Unfortunately, even if I fixed that today, it wouldn't have ANY effect on
> 99% of the field installations of any Python package management tools: there
> are still people using 4 or 5 year old versions of easy_install,

That's not a good argument imo. If we stop doing any enhancements to
installers because some people use old versions, we will never do
anything. The people that complain about a behavior in a 4 years-old
installer, that was changed/fixed since then, know they can update.

> and a lot
> of people use Distribute (via their OS install), which is a year behind the
> setuptools trunk on various things.

If you really believe this statement is true, let us know what are the
"various things" so we can fix them for everyone's benefit.

As a reminder, the current situation in packaging tools is as follows :

- Setuptools development is stalled -- see the attached diagram
- Distribute development is now also stalled.
- People that used to work on Distribute are now working on Distutils2

I think there are a few things we should all do today to make things better:

1. make sure anything that gets fixed in Setuptools is backported in Distribute
2. stop adding new features in Distribute, or minimal things. I think
the py3 support by itself justifies that Distribute should be
preferred to Setuptools in OSes.
3. focusing on consolidating the first version of Distutils2

Could you help on 1. ?

..
>
> Pip is the main package manager that uses its own link-finding algorithm,
> but it only supports source installation AFAIK. ?Distutils2 uses a
> link-finding algorithm that was lifted pretty much verbatim from
> easy_install, though I think there may have been some additions to it since
> I last looked at it.

We plan to prefer the final versions, and let the user decides if she
wants to use betas, devs etc. Contributions/Feedback/Advices are
welcome.

Cheers
Tarek

-- 
Tarek Ziad? | http://ziade.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setuptools.png
Type: image/png
Size: 10358 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110218/93ff4cf7/attachment.png>

From wichert at wiggy.net  Fri Feb 18 13:03:54 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Fri, 18 Feb 2011 13:03:54 +0100
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <AANLkTi=WR_XtGT-JvvC9yiPdhWg0jjXQ3zC1F60nv+u-@mail.gmail.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>	<20110216204049.4D6383A406A@sparrow.telecommunity.com>	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>	<20110217185755.F3D933A405C@sparrow.telecommunity.com>
	<AANLkTi=WR_XtGT-JvvC9yiPdhWg0jjXQ3zC1F60nv+u-@mail.gmail.com>
Message-ID: <4D5E602A.5000103@wiggy.net>

On 2/18/11 12:30 , Tarek Ziad? wrote:
> As a reminder, the current situation in packaging tools is as follows :
>
> - Setuptools development is stalled -- see the attached diagram
> - Distribute development is now also stalled.
> - People that used to work on Distribute are now working on Distutils2

My recent experience has been that setuptools is actively maintained, 
and PJE is quickly fixing errors where distribute is ignoring 
bugreports. My only gripe with setuptools at the moment is that long 
time between releases; often there are fixes ready in svn waiting for 
many months before a release is made.

Wichert.

From ziade.tarek at gmail.com  Fri Feb 18 13:37:16 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 18 Feb 2011 13:37:16 +0100
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <4D5E602A.5000103@wiggy.net>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTimiS-kW3hSxmg5FWVmXxK=gZQxAnqp8M5YLOEpk@mail.gmail.com>
	<20110217185755.F3D933A405C@sparrow.telecommunity.com>
	<AANLkTi=WR_XtGT-JvvC9yiPdhWg0jjXQ3zC1F60nv+u-@mail.gmail.com>
	<4D5E602A.5000103@wiggy.net>
Message-ID: <AANLkTinDeFth-4uWVX7DaPi+E00YriqfkMQ_g4twEjos@mail.gmail.com>

On Fri, Feb 18, 2011 at 1:03 PM, Wichert Akkerman <wichert at wiggy.net> wrote:
> On 2/18/11 12:30 , Tarek Ziad? wrote:
>>
>> As a reminder, the current situation in packaging tools is as follows :
>>
>> - Setuptools development is stalled -- see the attached diagram
>> - Distribute development is now also stalled.
>> - People that used to work on Distribute are now working on Distutils2
>
> My recent experience has been that setuptools is actively maintained, and
> PJE is quickly fixing errors where distribute is ignoring bugreports.

By "development" I mean adding new features to the project, making it evolve.

Now, the rare commits that are done in the two projects are just bug fixes.

And stating that "distribute is a year behind setuptools" is a false statement,

Maybe this is a more accurate statement:

1 - some rare bugs fixes were not backported from setuptools to
Distribute, because missed
2 - the few recents bugfixes were not backported

While we can fix 2 -- we cannot fix 1 without some expertise from PJE,
because some changes done in giant commits hard to decrypt.


> My
> only gripe with setuptools at the moment is that long time between releases;
> often there are fixes ready in svn waiting for many months before a release
> is made.
>
> Wichert.
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



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

From jim at zope.com  Fri Feb 18 14:53:09 2011
From: jim at zope.com (Jim Fulton)
Date: Fri, 18 Feb 2011 08:53:09 -0500
Subject: [Distutils] Tools should (at least optionally) prefer final
 releases. (was Re: easy_install installing beta version of psycopg2)
Message-ID: <AANLkTinK13H1epQU=uRZ+XaX-vMHCaDUCbEmnt-gNyj_@mail.gmail.com>

On Fri, Feb 18, 2011 at 5:29 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Feb 18, 2011 at 10:00 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> On 17/02/2011 00:01, Daniele Varrazzo wrote:
>>>
>>> I don't think it is fair to ask to stop listing the beta from the
>>> homepage and the download page of the 2-pages website of the module:
>>
>> Indeed, but I think it's totally fair to expect users to pin to the version
>> they require using whatever package management policy they choose.
>>
>> Of course, sure, it would be nice if easy_install had a sane default of
>> installing only final releases, but what're the chances of PJE implementing
>> that? ;-)
>>
>> What's the "distribute" take on this?
>
> If someone wants to contribute a "--prefer-final" option to Distribute
> --extracted from zc.buildout-- I am fine adding it, and even
> activating this behavior by default, so people opt in to get the non
> final releases.

Thank you for noting the buildout feature, which has been around since 2007. :)

I really think tools should support this feature.  I also think the default
should be to prefer final. I think this is much better than maintaining separate
indexes.

>
> I think it would be a good way to let the user control the behavior of
> the installer better, and that's what zc.buildout wants to do next
> AFAIK.

Yes. buildout2 will prefer final by default.

Jim

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

From pje at telecommunity.com  Fri Feb 18 16:04:12 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 18 Feb 2011 10:04:12 -0500
Subject: [Distutils] easy_install installing beta version of  psycopg2
In-Reply-To: <AANLkTi=dWyLUSL4RueVGCAD3Mka7JikALCVVys1ux+86@mail.gmail.c
 om>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTi=dWyLUSL4RueVGCAD3Mka7JikALCVVys1ux+86@mail.gmail.com>
Message-ID: <20110218150416.593743A405C@sparrow.telecommunity.com>

At 12:41 PM 2/18/2011 +0000, Daniele Varrazzo wrote:
>I've tried to be good and replace the download_url, which used to
>refer to a directory containing all the packages, to a direct link to
>the package to download (see
>http://pypi.python.org/pypi/psycopg2/2.3.2). It wasn't enough as
>probably previous versions listed in /simple/ still refer to the
>directory (see http://pypi.python.org/simple/psycopg2/).
>
>Is there a way to clean the list in /simple/, apart from deleting all
>the previous releases from PyPI, which would be a net loss for PyPI as
>a repository?

Yes.  Just edit those releases.  Log in to PyPI, go to your package 
page, then click on "Releases".  There will be an "edit" link for each release.


From daniele.varrazzo at gmail.com  Fri Feb 18 16:20:29 2011
From: daniele.varrazzo at gmail.com (Daniele Varrazzo)
Date: Fri, 18 Feb 2011 15:20:29 +0000
Subject: [Distutils] easy_install installing beta version of psycopg2
In-Reply-To: <20110218150416.593743A405C@sparrow.telecommunity.com>
References: <AANLkTinEdpO5LnmwYHEXd_n83PPgiab8q8bFyLvizqsf@mail.gmail.com>
	<AANLkTin3_H+PZDDPJMOpxvBSN_hVZZ2pMDCgV+DaNprs@mail.gmail.com>
	<20110216204049.4D6383A406A@sparrow.telecommunity.com>
	<AANLkTi=dWyLUSL4RueVGCAD3Mka7JikALCVVys1ux+86@mail.gmail.com>
	<20110218150416.593743A405C@sparrow.telecommunity.com>
Message-ID: <AANLkTinGgZU=SDac3jCzr6cbwyfPm8+HVTL-E7qGtW3t@mail.gmail.com>

On Fri, Feb 18, 2011 at 3:04 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 12:41 PM 2/18/2011 +0000, Daniele Varrazzo wrote:
>>
>> I've tried to be good and replace the download_url, which used to
>> refer to a directory containing all the packages, to a direct link to
>> the package to download (see
>> http://pypi.python.org/pypi/psycopg2/2.3.2). It wasn't enough as
>> probably previous versions listed in /simple/ still refer to the
>> directory (see http://pypi.python.org/simple/psycopg2/).
>>
>> Is there a way to clean the list in /simple/, apart from deleting all
>> the previous releases from PyPI, which would be a net loss for PyPI as
>> a repository?
>
> Yes. ?Just edit those releases. ?Log in to PyPI, go to your package page,
> then click on "Releases". ?There will be an "edit" link for each release.

It didn't work. The url for the beta is probably taken from the home page.

    Searching for psycopg2
    Reading http://pypi.python.org/simple/psycopg2/
    Reading http://initd.org/psycopg/
    Reading http://initd.org/tracker/psycopg
    Reading http://initd.org/projects/psycopg2
    Best match: psycopg2 2.4-beta2

On the plus side, this means we will have more tests than expected.

-- Daniele

From m.van.rees at zestsoftware.nl  Fri Feb 18 16:28:08 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Fri, 18 Feb 2011 16:28:08 +0100
Subject: [Distutils] [buildout] including optional python packages for
	testing
In-Reply-To: <4D5E36D7.8050906@simplistix.co.uk>
References: <4D5E36D7.8050906@simplistix.co.uk>
Message-ID: <ijm368$vme$1@dough.gmane.org>

Op 18-02-11 10:07, Chris Withers schreef:
> Hi All,
>
> I'm using buildout to develop a package that uses sqlalchemy and
> sqlalchemy-migrate.
>
> As a result, I'd like to test with various real database drivers; mysql,
> postgres, etc.
>
> However, I don't want to force anyone who wants to check out and run the
> tests to have all supported database drivers available and compiled.
>
> So, I'm looking for some way of specifying "optional eggs" when running
> the buildout, and not in buildout.cfg so they don't accidentally get
> checked in.
>
> How can I achieve this?

Next to the install_requires in setup.py you add an extras_requires; 
here is an example from the plone.app.discussion package:

       extras_require = {
           'test': [
               'plone.app.testing',
               'interlude',
           ]
       },

If you want to install these extra dependencies in e.g. a buildout 
config, you specify plone.app.discussion[test] as an egg.


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


From chris at simplistix.co.uk  Fri Feb 18 16:37:52 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Feb 2011 15:37:52 +0000
Subject: [Distutils] [buildout] including optional python packages for
 testing
In-Reply-To: <ijm368$vme$1@dough.gmane.org>
References: <4D5E36D7.8050906@simplistix.co.uk> <ijm368$vme$1@dough.gmane.org>
Message-ID: <4D5E9250.6030602@simplistix.co.uk>

On 18/02/2011 15:28, Maurits van Rees wrote:
>> So, I'm looking for some way of specifying "optional eggs" when running
>> the buildout, and not in buildout.cfg so they don't accidentally get
>> checked in.
>>
>> How can I achieve this?
>
> Next to the install_requires in setup.py you add an extras_requires;
> here is an example from the plone.app.discussion package:
>
> extras_require = {
> 'test': [
> 'plone.app.testing',
> 'interlude',
> ]
> },
>
> If you want to install these extra dependencies in e.g. a buildout
> config, you specify plone.app.discussion[test] as an egg.

Hmm, this isn't quite what I'm talking about.

If I did it this way, I'd need to define an extras_require section for 
each type of database, so about 4-6 sections.

These also aren't really dependencies of my package, since they're never 
imported by my package code, so it feels wrong to declare them as 
dependencies...

Chris

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

From benji at benjiyork.com  Fri Feb 18 16:56:50 2011
From: benji at benjiyork.com (Benji York)
Date: Fri, 18 Feb 2011 10:56:50 -0500
Subject: [Distutils] [buildout] including optional python packages for
	testing
In-Reply-To: <4D5E36D7.8050906@simplistix.co.uk>
References: <4D5E36D7.8050906@simplistix.co.uk>
Message-ID: <AANLkTikcwnTfYA8RCPVXw838uZUoazJvT4gYDg5v1wCF@mail.gmail.com>

On Fri, Feb 18, 2011 at 4:07 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> I'm using buildout to develop a package that uses sqlalchemy and
> sqlalchemy-migrate.
>
> As a result, I'd like to test with various real database drivers; mysql,
> postgres, etc.
>
> However, I don't want to force anyone who wants to check out and run the
> tests to have all supported database drivers available and compiled.
>
> So, I'm looking for some way of specifying "optional eggs" when running the
> buildout, and not in buildout.cfg so they don't accidentally get checked in.

If I'm understanding you correctly, buildout's "install" command might
help you.

You can run bin/buildout install foo, where "foo" is a part to install.
It is not required that "foo" be listed in the [buildout] "parts ="
line.  Therefore you can have buildout actions that aren't run by
default but that you can trigger as needed.
-- 
Benji York

From m.van.rees at zestsoftware.nl  Fri Feb 18 17:04:18 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Fri, 18 Feb 2011 17:04:18 +0100
Subject: [Distutils] [buildout] including optional python packages for
	testing
In-Reply-To: <4D5E9250.6030602@simplistix.co.uk>
References: <4D5E36D7.8050906@simplistix.co.uk> <ijm368$vme$1@dough.gmane.org>
	<4D5E9250.6030602@simplistix.co.uk>
Message-ID: <ijm5a2$ca2$1@dough.gmane.org>

Op 18-02-11 16:37, Chris Withers schreef:
> On 18/02/2011 15:28, Maurits van Rees wrote:
>>> So, I'm looking for some way of specifying "optional eggs" when running
>>> the buildout, and not in buildout.cfg so they don't accidentally get
>>> checked in.
>>>
>>> How can I achieve this?
>>
>> Next to the install_requires in setup.py you add an extras_requires;
>> here is an example from the plone.app.discussion package:
>>
>> extras_require = {
>> 'test': [
>> 'plone.app.testing',
>> 'interlude',
>> ]
>> },
>>
>> If you want to install these extra dependencies in e.g. a buildout
>> config, you specify plone.app.discussion[test] as an egg.
>
> Hmm, this isn't quite what I'm talking about.
>
> If I did it this way, I'd need to define an extras_require section for
> each type of database, so about 4-6 sections.
>
> These also aren't really dependencies of my package, since they're never
> imported by my package code, so it feels wrong to declare them as
> dependencies...

Ah, I misunderstood you.

Perhaps you could add an extra.cfg that extends buildout.cfg and adds 
the optional eggs.  Then you need to remember that you have to run 
'bin/buildout -c extra.cfg' when you want to test with those extra eggs.

Or maybe let buildout.cfg extend a local.cfg that adds the extra eggs. 
Do not add local.cfg in subversion (or whatever VCS you use) but instead 
let it ignore that file.  Add an instruction in the readme that people 
should manually add such a local.cfg and that it can remain empty.

I sometimes have only an almost empty buildout.cfg.in file in a project 
that extends a base.cfg file, with instructions to copy it to 
buildout.cfg and adapt to your local needs/wishes.

Cheers,

-- 
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  Fri Feb 18 17:18:24 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Fri, 18 Feb 2011 17:18:24 +0100
Subject: [Distutils] zc.buildout/zc,
	recipe.egg: passing extra options for build_ext
Message-ID: <ijm64h$hhg$1@dough.gmane.org>

Hi,

I see that you can add specify some custom build settings for packages 
with C-extensions:
http://pypi.python.org/pypi/zc.recipe.egg#creating-eggs-with-extensions-needing-custom-build-settings

The options you can pass are limited though.  In my case for the 
InformixDB package I want to pass '--esql-threadlib = posix' to the 
build process.  Currently this is not possible.

Is there a reason why only the current hardcoded options (like 
include-dirs) are available for customizing?  It looks like it should be 
possible to change the zc.recipe.egg code to look for other options and 
pass them to the build_ext call.  The only thing that might be tricky is 
to make a difference between options in the buildout part that should be 
passed to build_ext and options that have a totally different meaning 
and should be ignored by build_ext.

Would this be a good addition to zc.recipe egg?  I could create a branch 
and try it.  That should be a branch of zc.buildout, right?


Or are there other ways that currently already work?


My workaround for now will likely be to make a copy of the original 
source dist tarball of InformixDB and add a setup.cfg in there with this 
contents:

[build_ext]
--esql-threadlib = posix

 From a local test this seems to be working.

BTW, I did not know that you could specify these options in setup.cfg; I 
found that out today by looking through the zc.buildout code. :-)


Cheers,

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


From chris at simplistix.co.uk  Fri Feb 18 17:22:15 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 18 Feb 2011 16:22:15 +0000
Subject: [Distutils] [buildout] including optional python packages for
 testing
In-Reply-To: <AANLkTikcwnTfYA8RCPVXw838uZUoazJvT4gYDg5v1wCF@mail.gmail.com>
References: <4D5E36D7.8050906@simplistix.co.uk>
	<AANLkTikcwnTfYA8RCPVXw838uZUoazJvT4gYDg5v1wCF@mail.gmail.com>
Message-ID: <4D5E9CB7.6050409@simplistix.co.uk>

On 18/02/2011 15:56, Benji York wrote:
> You can run bin/buildout install foo, where "foo" is a part to install.
> It is not required that "foo" be listed in the [buildout] "parts ="
> line.  Therefore you can have buildout actions that aren't run by
> default but that you can trigger as needed.

Ah, now that sounds like what I'm after!

thanks,

Chris

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

From jim at zope.com  Fri Feb 18 17:23:17 2011
From: jim at zope.com (Jim Fulton)
Date: Fri, 18 Feb 2011 11:23:17 -0500
Subject: [Distutils] zc.buildout/zc,
	recipe.egg: passing extra options for build_ext
In-Reply-To: <ijm64h$hhg$1@dough.gmane.org>
References: <ijm64h$hhg$1@dough.gmane.org>
Message-ID: <AANLkTi=HXgjGfUiVW9DSWDZgEFwkHaU1eGabTy8WYTBq@mail.gmail.com>

On Fri, Feb 18, 2011 at 11:18 AM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> Hi,
>
> I see that you can add specify some custom build settings for packages with
> C-extensions:
> http://pypi.python.org/pypi/zc.recipe.egg#creating-eggs-with-extensions-needing-custom-build-settings
>
> The options you can pass are limited though. ?In my case for the InformixDB
> package I want to pass '--esql-threadlib = posix' to the build process.
> ?Currently this is not possible.
>
> Is there a reason why only the current hardcoded options (like include-dirs)
> are available for customizing? ?It looks like it should be possible to
> change the zc.recipe.egg code to look for other options and pass them to the
> build_ext call. ?The only thing that might be tricky is to make a difference
> between options in the buildout part that should be passed to build_ext and
> options that have a totally different meaning and should be ignored by
> build_ext.
>
> Would this be a good addition to zc.recipe egg?

Probably.

>?I could create a branch and
> try it. ?That should be a branch of zc.buildout, right?

Yes.

Jim

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

From merwok at netwok.org  Sat Feb 19 00:57:15 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 19 Feb 2011 00:57:15 +0100
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <20100928090353.0f12c077@mission>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>	<20100921075715.632933f7@snowdog>	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>	<20100921103424.745016d4@mission>	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>	<AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
	<20100928090353.0f12c077@mission>
Message-ID: <4D5F075B.8030609@netwok.org>

Hi,

Old thread revival!  I was going through my archive and noticed this
unanswered message from late September which prompted me to do a bit of
research.

>>>> However, upload_docs
>>>> never quite works out of the box for me anyway.  First, it insists
>>>> on an index.html file, which my Sphinx builds never seem to write,
>>>> so I always have to add a symlink.
>> Barry, do you mean that you have all files generated by Sphinx but not
>> index.html ? That's weird, Sphinx should generate it like the others.
> Except that I don't have an index.txt file.  It kind of doesn't make sense.  I
> use buildout and have this in my buildout.cfg:
> 
> [docs]
> recipe = z3c.recipe.sphinxdoc
> eggs = mailman [docs]
> index-doc = docs/README
> default.css =
> layout.html =
> extensions = sphinxconf
> 
> So what I end up doing is symlinking index.html to README.html before I
> upload.

I don?t know the recipe, but the ?index-doc? settings clearly looks like
something that controls what the master page is called.  I guess it?s
because you want your README file to serve double duty as Sphinx front
page.  Now for the good news: I found you a way to make Sphinx use that
file as index.html:
http://osdir.com/ml/sphinx-dev/2010-10/msg00082.html

One may argue that upload_docs should just bundle *.html files, without
imposing the existence of index.html; I think the check is useful.

>>>  Second, it doesn't seem to play nicely with the location
>>>> that my buildout-based builds puts the docs, so I always also have
>>>> to use --upload-dir.  Yes, it would be nice if both of these
>>>> problems were fixed too. Yes, I should report them as bugs (or just
>>>> fix 'em ;).
>> How would you fix the second issue ? e.g. if the docs is not in docs/
>> or doc/
> That's a good question!  Maybe it's a buildout or recipe issue?

You can make the upload-dir setting persistent by putting it in your
setup.cfg.  Or if the recipe is used by a large part of the community,
open a feature request to have this directory automatically found if
neither docs nor doc exist.  What is the directory path, btw?

Regards

From email at lnowak.com  Sat Feb 19 18:50:55 2011
From: email at lnowak.com (=?utf-8?b?xYF1a2Fzeg==?= Nowak)
Date: Sat, 19 Feb 2011 17:50:55 +0000 (UTC)
Subject: [Distutils]
	=?utf-8?q?buildout_download_utility_and_failed_checks?=
	=?utf-8?q?ums_in=09cache?=
References: <AANLkTimTd1PwYL0oE_w+H1zZJSUmRkO29N6RajBo3-yL@mail.gmail.com>
	<AANLkTi=WNk_nRqPwdPApPqHSkbNF=xXkrLzsG97cL1d8@mail.gmail.com>
	<AANLkTinLgL=6Km0OL+uw_nC6pk7KUw8LSE_a7sovqLFZ@mail.gmail.com>
Message-ID: <loom.20110219T184929-558@post.gmane.org>

Hello,

?ukasz Nowak <email <at> lnowak.com> writes:

> 
> Hello,
> 
> W dniu 20 grudnia 2010 16:24 u?ytkownik Jim Fulton <jim <at> zope.com> napisa?:
> > 2010/12/20 ?ukasz Nowak <email <at> lnowak.com>:
> (...)
> >> Is it ok to have such change of buildout download cache behaviour?
> >
> > Sound like a good idea to me.
> 
> Thank you for confirmation.
> 
> > I suggest reporting a bug:
> >
> > ?https://bugs.launchpad.net/zc.buildout/+bugs
> 
> Done: https://bugs.launchpad.net/zc.buildout/+bug/692600

I updated the patch to trunk version of buildout and added a test -- all in bug 
report.

Feel free to review and commit.

Regards,
Luke


From kiorky at cryptelium.net  Sat Feb 19 20:04:08 2011
From: kiorky at cryptelium.net (kiorky)
Date: Sat, 19 Feb 2011 20:04:08 +0100
Subject: [Distutils] zc.buildout/zc,
 recipe.egg: passing extra options for build_ext
In-Reply-To: <4D5F129F.4020300@zestsoftware.nl>
References: <ijm64h$hhg$1@dough.gmane.org> <4D5EBA8A.2070900@cryptelium.net>
	<4D5F129F.4020300@zestsoftware.nl>
Message-ID: <4D601428.8070107@cryptelium.net>



Le 19/02/2011 01:45, Maurits van Rees a ?crit :
> Op 18-02-11 19:29, kiorky schreef:
>>
>> Le 18/02/2011 17:18, Maurits van Rees a ?crit :
>>> Hi,
>>>
>>> I see that you can add specify some custom build settings for packages with
>>> C-extensions:
>>> http://pypi.python.org/pypi/zc.recipe.egg#creating-eggs-with-extensions-needing-custom-build-settings
>>>
>>>
>> You can with minitage.recipe.scripts :
>>     - http://pypi.python.org/pypi/minitage.recipe.egg#specific-options
>>     -
>> http://pypi.python.org/pypi/minitage.recipe.egg#installing-eggs-with-custom-build-ext-options
>>
> 
> Thanks for the info.  I had a look at these.  I saw that this recipe pulls in
> some other minitage packages as well and in the end even pulls in mercurial,
> which failed for me on Ubuntu due to a missing bzip2 library.

Well... mercurial is an historical dependency from minitage.core.
I'm thinking about to remove it or not for years.

> 
> But I'll have a look at how this recipe does its stuff. Prefixing the extra
> options with 'bdistext' to avoid confusion with other options at least seems a
> good idea.

This is also a bit historical but yes i found also that it is more
straightforward like that...
Think that minitage.recipe.* are mostly 'compatible' with zc.recipe.* stuff. You
can even replace them on the fly on your buildout without touching anything but
adding 'buildout.minitagificator' to your extensions (it will just monkey patch
the recipes and entry points).



> 
> Cheers,
> 

-- 
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF
Pensez ? l?environnement.
N?imprimez ce courriel que si vous en avez vraiment besoin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110219/5b54e9ce/attachment.pgp>

From m.van.rees at zestsoftware.nl  Tue Feb 22 18:35:37 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 22 Feb 2011 18:35:37 +0100
Subject: [Distutils] zc.buildout test failures
Message-ID: <ik0s59$9oc$1@dough.gmane.org>

Hi,

I may want to create a branch of zc.buildout.  It would be handy if I 
get the current tests to pass first though, which for me they don't.  I 
have read the DEVELOPERS.txt on trunk.

This is zc.buildout trunk.  I ran dev.py with a clean python 2.6.6 
(freshly downloaded and compiled, no setuptools).  Mac OS X 10.6.6.
I have removed my ~/.buildout/default.cfg and ~/.pythonrc.py for good 
measure.

I ran the tests but in the end I have to interrupt them as they wait 
forever:

$ time bin/test
Running zope.testrunner.layer.UnitTests tests:
   Set up zope.testrunner.layer.UnitTests in 0.000 seconds.
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
Unused options for buildout: 'bar' 'foo'.
(... wait a long time...)
^CThe following test left new threads behind:
allowed_eggs_from_site_packages_bug_592524 (zc.buildout.tests)
New thread(s): 
[<Thread(/private/var/folders/KA/KAXdMSFEHom0r8QU1jW-Jk+++TI/-Tmp-/tmpbj_z9CbuildoutSetUp/_TEST_/sample_eggs, 
started daemon 4338487296)>]
Traceback (most recent call last):
   File "bin/test", line 26, in <module>
     '--test-path', 
'/Users/mauritsvanrees/buildout/zc.buildout/trunk/z3c.recipe.scripts_/src',
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/eggs/zope.testrunner-4.0.1-py2.6.egg/zope/testrunner/__init__.py", 
line 30, in run
     failed = run_internal(defaults, args, script_parts=script_parts)
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/eggs/zope.testrunner-4.0.1-py2.6.egg/zope/testrunner/__init__.py", 
line 43, in run_internal
     runner.run()
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/eggs/zope.testrunner-4.0.1-py2.6.egg/zope/testrunner/runner.py", 
line 139, in run
     self.run_tests()
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/eggs/zope.testrunner-4.0.1-py2.6.egg/zope/testrunner/runner.py", 
line 220, in run_tests
     setup_layers, self.failures, self.errors)
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/eggs/zope.testrunner-4.0.1-py2.6.egg/zope/testrunner/runner.py", 
line 377, in run_layer
     return run_tests(options, tests, layer_name, failures, errors)
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/eggs/zope.testrunner-4.0.1-py2.6.egg/zope/testrunner/runner.py", 
line 309, in run_tests
     test(result)
   File 
"/Users/mauritsvanrees/py/clean/py266/lib/python2.6/unittest.py", line 
300, in __call__
     return self.run(*args, **kwds)
   File 
"/Users/mauritsvanrees/py/clean/py266/lib/python2.6/unittest.py", line 
279, in run
     testMethod()
   File "/Users/mauritsvanrees/py/clean/py266/lib/python2.6/doctest.py", 
line 2158, in runTest
     test, out=new.write, clear_globs=False)
   File "/Users/mauritsvanrees/py/clean/py266/lib/python2.6/doctest.py", 
line 1391, in run
     return self.__run(test, compileflags, out)
   File "/Users/mauritsvanrees/py/clean/py266/lib/python2.6/doctest.py", 
line 1253, in __run
     compileflags, 1) in test.globs
   File "<doctest 
zc.buildout.tests.allowed_eggs_from_site_packages_bug_592524[12]>", line 
1, in <module>
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/src/zc/buildout/testing.py", 
line 121, in call_py
     ' '.join(arg for arg in (interpreter, flags, '-c', cmd) if arg))
   File 
"/Users/mauritsvanrees/buildout/zc.buildout/trunk/src/zc/buildout/testing.py", 
line 108, in system
     result = o.read() + e.read()
KeyboardInterrupt

real	54m10.648s
user	1m4.413s
sys	0m29.749s

I think the times show that I have been patient enough. :-)

The result is the same when I call it with:
env PYTHON2.6=/Users/mauritsvanrees/py/clean/py266/bin/python bin/test

The z3c.recipe.scripts tests on zc.buildout trunk have to be interrupted 
as well.

Going in with a pdb I see that it waits for completion of:

   .../_TEST_/interpreter/bin/py -c 'import pprint, sys; 
pprint.pprint(sys.path[-4:])'

When I try that command myself in a separate terminal it also waits 
forever.  Even just calling that bin/py with -h, -V, -E or -S just 
results in a process appearing to wait for input.

The interpreter/bin/py looks like this:

-----------------------------------------------------
#!/private/var/folders/KA/KAXdMSFEHom0r8QU1jW-Jk+++TI/-Tmp-/tmpcsUDSybuildoutSetUp/_TEST_/executable_buildout/bin/py 
-S
import os
import sys

argv = [sys.executable] + sys.argv[1:]
environ = os.environ.copy()
path = 
'/private/var/folders/KA/KAXdMSFEHom0r8QU1jW-Jk+++TI/-Tmp-/tmpcsUDSybuildoutSetUp/_TEST_/interpreter/parts/interpreter'
if environ.get('PYTHONPATH'):
     path = os.pathsep.join([path, environ['PYTHONPATH']])
environ['PYTHONPATH'] = path
os.execve(sys.executable, argv, environ)
-----------------------------------------------------

This is somehow wrong: even adding a print statement on line 2 gives:
line 2: print: command not found

The .../_TEST_/executable_buildout/bin/py that is called by the above 
script works fine:

-----------------------------------------------------
#!/Users/mauritsvanrees/py/clean/py266/bin/python -S
import os
import sys

argv = [sys.executable] + sys.argv[1:]
environ = os.environ.copy()
path = 
'/private/var/folders/KA/KAXdMSFEHom0r8QU1jW-Jk+++TI/-Tmp-/tmpcsUDSybuildoutSetUp/_TEST_/executable_buildout/parts/py'
if environ.get('PYTHONPATH'):
     path = os.pathsep.join([path, environ['PYTHONPATH']])
environ['PYTHONPATH'] = path
os.execve(sys.executable, argv, environ)
-----------------------------------------------------


BTW, when I run the zc.recipe.egg tests on their own, the 5 tests pass.


On zc.buildout branch 1.4 the tests do finish, but with 3 failures, the 
first of which are these:

----------------------------------------------------------------------
File 
"/Users/mauritsvanrees/buildout/zc.buildout/1.4/src/zc/buildout/buildout.txt", 
line 578, in buildout.txt
Failed example:
     wait_until("foo goes away", lambda : not os.path.exists('foo'),
                timeout=100)
Exception raised:
     Traceback (most recent call last):
       File 
"/Users/mauritsvanrees/buildout/zc.buildout/1.4/eggs/zope.testing-3.10.2-py2.6.egg/zope/testing/doctest/__init__.py", 
line 1355, in __run
         compileflags, 1) in test.globs
       File "<doctest buildout.txt[line 578, example 34]>", line 2, in 
<module>
         timeout=100)
       File 
"/Users/mauritsvanrees/buildout/zc.buildout/1.4/src/zc/buildout/testing.py", 
line 203, in wait_until
         raise ValueError('Timed out waiting for: '+label)
     ValueError: Timed out waiting for: foo goes away
----------------------------------------------------------------------
File 
"/Users/mauritsvanrees/buildout/zc.buildout/1.4/src/zc/buildout/buildout.txt", 
line 583, in buildout.txt
Failed example:
     os.path.exists('foo')
Expected:
     False
Got:
     True
----------------------------------------------------------------------

The other failures seem related.

The zc.recipe.egg (1.2.2) tests fail with some minor differences in 
generated scripts:

Expected:
     base = os.path.dirname(__file__)
Got:
     base = os.path.dirname(os.path.abspath(os.path.realpath(__file__)))

BTW, somehow the zc.recipe.egg_ directory is not used as a development 
egg, but the official 1.2.2 egg is used, even though 
develop-eggs/zc.recipe.egg.egg-link seems fine.


Are others getting these failures too?

If not, any idea what could cause them on my machine?


Sorry for the long post.  If possible, please avoid quoting the complete 
post when answering.


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


From chris at simplistix.co.uk  Wed Feb 23 00:12:33 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 22 Feb 2011 23:12:33 +0000
Subject: [Distutils] [buildout] bad handling of stuff specified in
	setup_requires
Message-ID: <4D6442E1.2010504@simplistix.co.uk>

Hi All,

I've experiences problems when my package specifies a 
setup_requires="PasteScript" in it's call to setuptools' setup function 
when using buildout and my package is specified as a develop egg in the 
buildout.

I was doing this to avoid the following:

/usr/local/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown 
distribution option: 'paster_plugins'

..but specifying setup_requires as above seems to:

- install the PasteScript and Paste eggs directory in the checkout of my 
package under development (not ideal)

- trip up buildout into thinking that those packages are globally 
available and so not install them (really bad...)

- cause zc.recipe.egg, as a result, to not install scripts from those 
packages even when dependent-scripts is specified as true.

Worse still, because buildout doesn't seem to know much about those 
packages, even when the setup_requires line is removed, the .egg folders 
in the development checkout of my package still cause the above buildout 
problems.

Has anyone else experienced this?
Where's best to report this?

cheers,

Chris

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

From wichert at wiggy.net  Wed Feb 23 09:50:41 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Wed, 23 Feb 2011 09:50:41 +0100
Subject: [Distutils] [buildout] bad handling of stuff specified
	in	setup_requires
In-Reply-To: <4D6442E1.2010504@simplistix.co.uk>
References: <4D6442E1.2010504@simplistix.co.uk>
Message-ID: <4D64CA61.2080500@wiggy.net>

On 2/23/11 00:12 , Chris Withers wrote:
> Hi All,
>
> I've experiences problems when my package specifies a
> setup_requires="PasteScript" in it's call to setuptools' setup function
> when using buildout and my package is specified as a develop egg in the
> buildout.
>
> I was doing this to avoid the following:
>
> /usr/local/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown
> distribution option: 'paster_plugins'
>
> ..but specifying setup_requires as above seems to:
>
> - install the PasteScript and Paste eggs directory in the checkout of my
> package under development (not ideal)
>
> - trip up buildout into thinking that those packages are globally
> available and so not install them (really bad...)
>
> - cause zc.recipe.egg, as a result, to not install scripts from those
> packages even when dependent-scripts is specified as true.
>
> Worse still, because buildout doesn't seem to know much about those
> packages, even when the setup_requires line is removed, the .egg folders
> in the development checkout of my package still cause the above buildout
> problems.
>
> Has anyone else experienced this?

As far as I know zc.buildout is not capable of handling setup_requires 
and test_requires (and hence the abuse of extra_requires for test 
requirements).

> Where's best to report this?

I suspect this has been in the zc.buildout for a long time already.

Wichert.

From chris at simplistix.co.uk  Wed Feb 23 11:34:52 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 23 Feb 2011 10:34:52 +0000
Subject: [Distutils] [buildout] bad handling of stuff
	specified	in	setup_requires
In-Reply-To: <4D64CA61.2080500@wiggy.net>
References: <4D6442E1.2010504@simplistix.co.uk> <4D64CA61.2080500@wiggy.net>
Message-ID: <4D64E2CC.5070201@simplistix.co.uk>

On 23/02/2011 08:50, Wichert Akkerman wrote:
> As far as I know zc.buildout is not capable of handling setup_requires
> and test_requires (and hence the abuse of extra_requires for test
> requirements).
>
>> Where's best to report this?
>
> I suspect this has been in the zc.buildout for a long time already.

I guess we wait for Jim to comment...

Chris

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

From jim at zope.com  Wed Feb 23 19:08:12 2011
From: jim at zope.com (Jim Fulton)
Date: Wed, 23 Feb 2011 13:08:12 -0500
Subject: [Distutils] [buildout] bad handling of stuff specified in
	setup_requires
In-Reply-To: <4D64CA61.2080500@wiggy.net>
References: <4D6442E1.2010504@simplistix.co.uk> <4D64CA61.2080500@wiggy.net>
Message-ID: <AANLkTinyUTVXJY1b=PLYGy52a5VW8D45ax-8H3Ep=bq2@mail.gmail.com>

On Wed, Feb 23, 2011 at 3:50 AM, Wichert Akkerman <wichert at wiggy.net> wrote:
> On 2/23/11 00:12 , Chris Withers wrote:
>>
>> Hi All,
>>
>> I've experiences problems when my package specifies a
>> setup_requires="PasteScript" in it's call to setuptools' setup function
>> when using buildout and my package is specified as a develop egg in the
>> buildout.
>>
>> I was doing this to avoid the following:
>>
>> /usr/local/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown
>> distribution option: 'paster_plugins'
>>
>> ..but specifying setup_requires as above seems to:
>>
>> - install the PasteScript and Paste eggs directory in the checkout of my
>> package under development (not ideal)
>>
>> - trip up buildout into thinking that those packages are globally
>> available and so not install them (really bad...)
>>
>> - cause zc.recipe.egg, as a result, to not install scripts from those
>> packages even when dependent-scripts is specified as true.
>>
>> Worse still, because buildout doesn't seem to know much about those
>> packages, even when the setup_requires line is removed, the .egg folders
>> in the development checkout of my package still cause the above buildout
>> problems.
>>
>> Has anyone else experienced this?
>
> As far as I know zc.buildout is not capable of handling setup_requires and
> test_requires (and hence the abuse of extra_requires for test requirements).

I'd like buildout to support setup_requires.  I've heard at times that
it works and at others that it doesn't.  I doubt there are tests for
it.

tests_requires can't be supported by buildout (testrunner recipes)
because it's invisible to buildout.  It's not included in the meta
data that buildout can see. (Or at least it wasn't before. Perhaps
distribute fixes this.)

>> Where's best to report this?

The obvious place is the buildout bug tracker:

  https://bugs.launchpad.net/zc.buildout/+filebug

I can't say when it would be acted on, but at least it would be recorded.

Jim

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

From barry at python.org  Wed Feb 23 21:46:25 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Feb 2011 15:46:25 -0500
Subject: [Distutils] Preventing downloading for package requirements
Message-ID: <20110223154625.1d02f8d8@python.org>

Something that's come up recently in the Debian Python mailing list is
setuptools/distribute's habit of downloading *_requires packages
(e.g. install_requires) when they are not available locally.

This causes us problems because dependencies are defined in two places.  They
are defined in setup.py by the upstream package author, and in the
debian/control file by the OS packager.  Generally, this is okay because we
can generate debian/control from setup.py -- though it does take some manual
intervention to keep things in sync.

This came up in the context of always enabling tests when we build the OS
package.  The problem arises if the two dependency lists are out of sync.  For
example, your setup.py depends on 'foo' but the Debian 'python-foo' package is
not installed.  In this case, during the build process, 'foo' would get
downloaded from the Cheeseshop and this would mask a bug in the debian/control
file (since any listed in debian/control would get installed from the archive
and thus be available by the time setuptools/distribute runs).

The question is: what's the best way for us Debian packagers to absolutely
prevent download from Cheeseshop?  We would much rather have
setuptools/distribute spew an error and stop, because then we'd fix
debian/control and ensure that all the package's dependencies came from the OS
archive instead of external resources.

One way that seems to work is to add this to setup.cfg:

[easy_install]
allow_hosts: www.example.com

This will break the download by limiting acceptable hosts to bogus ones that
can't possibly satisfy the requirement.  But it's unsatisfying for several
reasons:

* It's obscure and doesn't really describe what we're trying to do ('fixable'
  I suppose by a comment)
* Requires the Debian packager to add a setup.cfg or modify an existing one in
  the upstream package.

Note that I thought this might also work, but it does not afaict:

[easy_install]
no_deps: true

So, do you have any suggestions for a better way to say "never download
dependencies" for a particular package, or class of packages.  Ideally,
there'd be one file we could modify, e.g. /etc/distribute.cfg that would allow
us to prevent downloading globally for all system provided packages, but would
still allow downloading for local development packages, e.g. via virtualenv.

Thoughts are welcome, but also perhaps we can discuss further at the Pycon
sprint.

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/20110223/8f8b33bb/attachment.pgp>

From ziade.tarek at gmail.com  Wed Feb 23 22:04:24 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Feb 2011 22:04:24 +0100
Subject: [Distutils] Preventing downloading for package requirements
In-Reply-To: <20110223154625.1d02f8d8@python.org>
References: <20110223154625.1d02f8d8@python.org>
Message-ID: <AANLkTi=86PQXWhSLrjEFn-OKzmUiL7LnUd8y38bZa-rv@mail.gmail.com>

On Wed, Feb 23, 2011 at 9:46 PM, Barry Warsaw <barry at python.org> wrote:
> Something that's come up recently in the Debian Python mailing list is
> setuptools/distribute's habit of downloading *_requires packages
> (e.g. install_requires) when they are not available locally.
>
> This causes us problems because dependencies are defined in two places. ?They
> are defined in setup.py by the upstream package author, and in the
> debian/control file by the OS packager. ?Generally, this is okay because we
> can generate debian/control from setup.py -- though it does take some manual
> intervention to keep things in sync.
>
> This came up in the context of always enabling tests when we build the OS
> package. ?The problem arises if the two dependency lists are out of sync. ?For
> example, your setup.py depends on 'foo' but the Debian 'python-foo' package is
> not installed. ?In this case, during the build process, 'foo' would get
> downloaded from the Cheeseshop and this would mask a bug in the debian/control
> file (since any listed in debian/control would get installed from the archive
> and thus be available by the time setuptools/distribute runs).
>
> The question is: what's the best way for us Debian packagers to absolutely
> prevent download from Cheeseshop? ?We would much rather have
> setuptools/distribute spew an error and stop, because then we'd fix
> debian/control and ensure that all the package's dependencies came from the OS
> archive instead of external resources.
>
> One way that seems to work is to add this to setup.cfg:
>
> [easy_install]
> allow_hosts: www.example.com
>
> This will break the download by limiting acceptable hosts to bogus ones that
> can't possibly satisfy the requirement. ?But it's unsatisfying for several
> reasons:
>
> * It's obscure and doesn't really describe what we're trying to do ('fixable'
> ?I suppose by a comment)
> * Requires the Debian packager to add a setup.cfg or modify an existing one in
> ?the upstream package.
>
> Note that I thought this might also work, but it does not afaict:
>
> [easy_install]
> no_deps: true

Well, if you want to handle all the dependencies for a project
yourself, you can shortcut distribute or setuptools by using the
--single-version-externaly managed option.

When using this option, the project will be installed by the vanilla
distutils install command.

Then it's up to you to handle dependencies. That's how pip does, and Fedora IIRC

HTH

Cheers
Tarek

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

From a.badger at gmail.com  Wed Feb 23 23:25:36 2011
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 23 Feb 2011 14:25:36 -0800
Subject: [Distutils] Preventing downloading for package requirements
In-Reply-To: <AANLkTi=86PQXWhSLrjEFn-OKzmUiL7LnUd8y38bZa-rv@mail.gmail.com>
References: <20110223154625.1d02f8d8@python.org>
	<AANLkTi=86PQXWhSLrjEFn-OKzmUiL7LnUd8y38bZa-rv@mail.gmail.com>
Message-ID: <20110223222536.GI19342@unaka.lan>

On Wed, Feb 23, 2011 at 10:04:24PM +0100, Tarek Ziad? wrote:
> >
> > One way that seems to work is to add this to setup.cfg:
> >
> > [easy_install]
> > allow_hosts: www.example.com
> >
> > This will break the download by limiting acceptable hosts to bogus ones that
> > can't possibly satisfy the requirement. ?But it's unsatisfying for several
> > reasons:
> >
> > * It's obscure and doesn't really describe what we're trying to do ('fixable'
> > ?I suppose by a comment)
> > * Requires the Debian packager to add a setup.cfg or modify an existing one in
> > ?the upstream package.
> >
> > Note that I thought this might also work, but it does not afaict:
> >
> > [easy_install]
> > no_deps: true
> 
> Well, if you want to handle all the dependencies for a project
> yourself, you can shortcut distribute or setuptools by using the
> --single-version-externaly managed option.
> 
> When using this option, the project will be installed by the vanilla
> distutils install command.
> 
> Then it's up to you to handle dependencies. That's how pip does, and Fedora IIRC
> 
What Barry's talking about is slightly different I think.  When running
python setup.py test, setup.py may download additional modules that should
have been specified in the system package (thus the download should never be
tried).  This occurs before the software is installed anywhere.

For Fedora we deal with this by preventing processes related to the build
from making any non-localhost network connnections.  That doesn't catch
things when a packager is building on their local machine but it does catch
things when the package is built on the builders

There's two pieces that work on that:
1) The build hosts themselves are configured with a firewall that prevents
   a lot of packets from leaving the box, and prevent any packets from going
   to a non-local network.
2) We build in a chroot and part of chroot construction is to create an
   empty resolv.conf.  This prevents DNS lookups from succeeding and
   controls the automatic downloading among other things.

Neither of these are especially well adapted to being run by a casual
packager but the second (a chroot with empty resolv.conf) could be done
without too much trouble (we have a tool called mock that creates chroots,
it was based on a tool called mach which can use apt and might be better for
a Debian usage).  Both 1 and 2 could be performed on a VM if you can get
your packagers to go that far or are dealing with a build system rather than
individual packagers.

-Toshio

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

From barry at python.org  Thu Feb 24 00:10:06 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Feb 2011 18:10:06 -0500
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <4D5F075B.8030609@netwok.org>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
	<AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
	<20100928090353.0f12c077@mission> <4D5F075B.8030609@netwok.org>
Message-ID: <20110223181006.70f9b1c9@python.org>

On Feb 19, 2011, at 12:57 AM, ?ric Araujo wrote:

>Old thread revival!  I was going through my archive and noticed this
>unanswered message from late September which prompted me to do a bit of
>research.

\o/

>>>>> However, upload_docs
>>>>> never quite works out of the box for me anyway.  First, it insists
>>>>> on an index.html file, which my Sphinx builds never seem to write,
>>>>> so I always have to add a symlink.
>>> Barry, do you mean that you have all files generated by Sphinx but not
>>> index.html ? That's weird, Sphinx should generate it like the others.
>> Except that I don't have an index.txt file.  It kind of doesn't make sense.  I
>> use buildout and have this in my buildout.cfg:
>> 
>> [docs]
>> recipe = z3c.recipe.sphinxdoc
>> eggs = mailman [docs]
>> index-doc = docs/README
>> default.css =
>> layout.html =
>> extensions = sphinxconf
>> 
>> So what I end up doing is symlinking index.html to README.html before I
>> upload.
>
>I don?t know the recipe, but the ?index-doc? settings clearly looks like
>something that controls what the master page is called.  I guess it?s
>because you want your README file to serve double duty as Sphinx front
>page.  Now for the good news: I found you a way to make Sphinx use that
>file as index.html:
>http://osdir.com/ml/sphinx-dev/2010-10/msg00082.html

Thanks, but I tried this and couldn't get it working.  Actually, from Georg's
response, it sounds like html_index isn't even supported any more.

My own crappy workaround is this bit of ugliness in my conf.py file:

def index_html():
    cwd = os.getcwd()
    try:
        os.chdir('build/sphinx/html')
        os.symlink('README.html', 'index.html')
        print 'index.html -> README.html'
    finally:
        os.chdir(cwd)

import atexit
atexit.register(index_html)

The interesting thing is that this works with 'python setup.py build_sphinx'
but not with 'make html' (using Sphinx's generated Makefile) because of the
different build path defaults.  OTOH, the Makefile does have this nice target:

pypi: html
	(cd _build/html; \
	 rm -f index.html; \
	 ln -s README.html index.html; \
	 zip -r ../pypi .)

So 'make html && make pypi' leaves you with _build/pypi.zip that should be
directly uploadable.

>One may argue that upload_docs should just bundle *.html files, without
>imposing the existence of index.html; I think the check is useful.
>
>>>>  Second, it doesn't seem to play nicely with the location
>>>>> that my buildout-based builds puts the docs, so I always also have
>>>>> to use --upload-dir.  Yes, it would be nice if both of these
>>>>> problems were fixed too. Yes, I should report them as bugs (or just
>>>>> fix 'em ;).
>>> How would you fix the second issue ? e.g. if the docs is not in docs/
>>> or doc/
>> That's a good question!  Maybe it's a buildout or recipe issue?
>
>You can make the upload-dir setting persistent by putting it in your
>setup.cfg.  Or if the recipe is used by a large part of the community,
>open a feature request to have this directory automatically found if
>neither docs nor doc exist.  What is the directory path, btw?

Yep, I found the upload-dir setting for setup.cfg.  So after 'make pypi' a
'python setup.py upload_docs' DTRT.

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/20110223/ffb4ceae/attachment-0001.pgp>

From barry at python.org  Thu Feb 24 00:25:31 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 23 Feb 2011 18:25:31 -0500
Subject: [Distutils] Preventing downloading for package requirements
In-Reply-To: <20110223222536.GI19342@unaka.lan>
References: <20110223154625.1d02f8d8@python.org>
	<AANLkTi=86PQXWhSLrjEFn-OKzmUiL7LnUd8y38bZa-rv@mail.gmail.com>
	<20110223222536.GI19342@unaka.lan>
Message-ID: <20110223182531.0cf69103@python.org>

On Feb 23, 2011, at 02:25 PM, Toshio Kuratomi wrote:

>What Barry's talking about is slightly different I think.  When running
>python setup.py test, setup.py may download additional modules that should
>have been specified in the system package (thus the download should never be
>tried).  This occurs before the software is installed anywhere.

Right on, Toshio.

>For Fedora we deal with this by preventing processes related to the build
>from making any non-localhost network connnections.  That doesn't catch
>things when a packager is building on their local machine but it does catch
>things when the package is built on the builders
>
>There's two pieces that work on that:
>1) The build hosts themselves are configured with a firewall that prevents
>   a lot of packets from leaving the box, and prevent any packets from going
>   to a non-local network.
>2) We build in a chroot and part of chroot construction is to create an
>   empty resolv.conf.  This prevents DNS lookups from succeeding and
>   controls the automatic downloading among other things.
>
>Neither of these are especially well adapted to being run by a casual
>packager but the second (a chroot with empty resolv.conf) could be done
>without too much trouble (we have a tool called mock that creates chroots,
>it was based on a tool called mach which can use apt and might be better for
>a Debian usage).  Both 1 and 2 could be performed on a VM if you can get
>your packagers to go that far or are dealing with a build system rather than
>individual packagers.

I believe our builders prevent external connections too.  I'm not positive
about it but it wouldn't be too difficult to test.  Still, as you point out,
it's more difficult to enforce with local builders, and that's where packagers
are going to be more able to quickly fix any such problems.  One difficultly
for Debian/Ubuntu local build environments (aside from the fact that there are
several ways people do it ;), is that at least with some of the local
builders, they *have* to do external connections, e.g. to download build
dependencies into the chroot the build is done from.  You could of course
tightly control that, but given the geographical archive mirroring, it just
makes things more complicated.

-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/20110223/4060ec09/attachment.pgp>

From sienkiew at stsci.edu  Fri Feb 25 16:27:39 2011
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Fri, 25 Feb 2011 10:27:39 -0500
Subject: [Distutils] Preventing downloading for package requirements
In-Reply-To: <20110223154625.1d02f8d8@python.org>
References: <20110223154625.1d02f8d8@python.org>
Message-ID: <4D67CA6B.8090800@stsci.edu>

Barry Warsaw wrote:
> So, do you have any suggestions for a better way to say "never download
> dependencies" for a particular package, or class of packages.  


easy_install has (at least in distribute) a documented feature that 
makes it use only locally stored files.

http://packages.python.org/distribute/easy_install.html#installing-on-un-networked-machines

If it works (I never tried it), that is a nice feature for configuration 
management; it can't possibly get the wrong version if it can only use 
what you have provided.

In your case, anything that is not already installed (from another 
debian package) is "wrong".  You might provide a directory containing 
only the single package that you want to install.  Anything else would 
be not found, and that would be your clue that something was wrong.  You 
either need to install another debian package to provide the missing 
python package, or you need another python package as part of the debian 
package that you are presently creating.


> Ideally,
> there'd be one file we could modify, e.g. /etc/distribute.cfg that would allow
> us to prevent downloading globally for all system provided packages, but would
> still allow downloading for local development packages, e.g. via virtualenv.
>   

Here, it sounds like you want it to go to the network for some packages, 
but not others.  I'm not real clear on what you have in mind, though.  
Does it work to pass the parameters on the command line to indicate that 
you do/don't want to go to the network during this run of easy_install?

Mark


From barry at python.org  Fri Feb 25 16:51:52 2011
From: barry at python.org (Barry Warsaw)
Date: Fri, 25 Feb 2011 10:51:52 -0500
Subject: [Distutils] Preventing downloading for package requirements
In-Reply-To: <4D67CA6B.8090800@stsci.edu>
References: <20110223154625.1d02f8d8@python.org> <4D67CA6B.8090800@stsci.edu>
Message-ID: <20110225105152.03c38a1f@limelight.wooz.org>

On Feb 25, 2011, at 10:27 AM, Mark Sienkiewicz wrote:

>Barry Warsaw wrote:
>> So, do you have any suggestions for a better way to say "never download
>> dependencies" for a particular package, or class of packages.  easy_install has (at least in distribute) a documented feature that makes it use only locally stored files.
>
>http://packages.python.org/distribute/easy_install.html#installing-on-un-networked-machines
>
>If it works (I never tried it), that is a nice feature for configuration
>management; it can't possibly get the wrong version if it can only use what
>you have provided.
>
>In your case, anything that is not already installed (from another debian
>package) is "wrong".  You might provide a directory containing only the
>single package that you want to install.  Anything else would be not found,
>and that would be your clue that something was wrong.  You either need to
>install another debian package to provide the missing python package, or you
>need another python package as part of the debian package that you are
>presently creating.

Ah, this link just turned on the light.  I can add this to setup.cfg:

[easy_install]
allow_hosts: None

It's moderately better than my previous take which was to set allow_hosts to
www.example.com.  Sounds like the best way forward is for us to recommend
adding this entry to prevent unwanted downloads.

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/20110225/dcc9ed2d/attachment.pgp>