From setuptools at bugs.python.org  Mon Jun  2 22:29:54 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 02 Jun 2008 20:29:54 +0000
Subject: [Distutils] [issue18] can't install pywin32
In-Reply-To: <1212438594.76.0.230250692043.issue18@psf.upfronthosting.co.za>
Message-ID: <1212438594.76.0.230250692043.issue18@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

http://sourceforge.net/tracker/index.php?func=detail&aid=1799934&group_id=78018&atid=551954

Tells how {{{easy_install pywin32}}} fails.  I believe that this has been fixed
in setuptools trunk by PJE:

http://mail.python.org/pipermail/distutils-sig/2007-July/007823.html

but that fix (if it is a fix) isn't in a released version of setuptools yet.

I'm making the status of this ticket be "in-progress" in order to indicate that
a fix has been created but not yet released.

----------
messages: 31
nosy: zooko
priority: bug
status: in-progress
title: can't install pywin32

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

From setuptools at bugs.python.org  Tue Jun  3 01:50:12 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 02 Jun 2008 23:50:12 +0000
Subject: [Distutils] [issue19] Will setuptools on Mac Python accept fat eggs?
In-Reply-To: <1212450611.1.0.774353636038.issue19@psf.upfronthosting.co.za>
Message-ID: <1212450611.1.0.774353636038.issue19@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

There was a time, last November, when, if I understand it correctly, setuptools
on the standard Python that comes with Mac OS X wouldn't accept fat eggs for Mac
OS X 10.4 or higher.

Here is the pythonmac-sig discussion:

http://www.nabble.com/does-pkg_resources-think-that-%22macosx-10.3%22-is-incompatible-with-10.5--to13865060.html#a13865060

Ronald Oussoren has committed the fix for the comparison of Mac OS X version
numbers from '<' to '>=', so as of Python 2.5.2 that problem is fixed.  However,
he mentioned other problems which I didn't understand:

"""the config/Makefile in  
Apple's Python.framework isn't configured for building universal  
binaries.

And to make matters even worse: I'm pretty sure that setuptools used  
to know that 'fat' builds are compatible with 'i386' and 'ppc'  
architectures (at least on OSX), but that code no longer seems to be  
there.
"""

What is the status of this issue now?

----------
messages: 33
nosy: zooko
priority: bug
status: unread
title: Will setuptools on Mac Python accept fat eggs?

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

From setuptools at bugs.python.org  Tue Jun  3 03:42:38 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 03 Jun 2008 01:42:38 +0000
Subject: [Distutils] [issue20] package required at build time seems to be
	not fully present at install time?
In-Reply-To: <1212457358.71.0.0245112397755.issue20@psf.upfronthosting.co.za>
Message-ID: <1212457358.71.0.0245112397755.issue20@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

If you try to install this minimal project:

"""
import setuptools
setuptools.setup(name="minproj_that_needs_nevow", install_requires=["Nevow"]
"""

You'll get a reasonable-looking traceback that ends with an ImportError in which
Nevow tried to import Twisted at install time.  (Note that Nevow does not
declare its install-time dependency on Twisted -- see
http://divmod.org/trac/ticket/2629 .)

"""
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 427, in easy_install
    return self.install_item(None, spec, tmpdir, deps, True)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 478, in install_item
    self.process_distribution(spec, dist, deps)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 519, in process_distribution
    [requirement], self.local_index, self.easy_install
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 522, in resolve
    dist = best[req.key] = env.best_match(req, self, installer)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 758, in best_match
    return self.obtain(req, installer) # try and download/install
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 770, in obtain
    return installer(requirement)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 446, in easy_install
    return self.install_item(spec, dist.location, tmpdir, deps)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 476, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 655, in install_eggs
    return self.build_and_install(setup_script, setup_base)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 930, in build_and_install 
    self.run_setup(setup_script, setup_base, args)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 919, in run_setup
    run_setup(setup_script, args)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 27, in run_setup
    lambda: execfile(
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 63, in run
    return func()
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 29, in <lambda>
    {'__file__':setup_script, '__name__':'__main__'}
  File "setup.py", line 8, in <module>

  File "/tmp/easy_install-1aI_wu/Nevow-0.9.31/setupcommon.py", line 2, in <module>
  File "/tmp/easy_install-1aI_wu/Nevow-0.9.31/nevow/__init__.py", line 5, in
<module>
  File "/tmp/easy_install-1aI_wu/Nevow-0.9.31/nevow/_version.py", line 2, in
<module>
ImportError: No module named twisted.python
"""

This is the same behavior as if you had simply executed "easy_install Nevow".

The _version.py file in question is visible here:

http://divmod.org/trac/browser/trunk/Nevow/nevow/_version.py?rev=14968

However, if you try to install this minimal project:

"""
import setuptools
setuptools.setup(name="minproj_that_needs_nevow", setup_requires=["Twisted"],
install_requires=["Nevow"]
"""

You'll get a slightly strange error message which suggests that Nevow got
further in its attempt to use Twisted, but not far enough:

"""
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 478, in install_item
    self.process_distribution(spec, dist, deps)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 519, in process_distribution
    [requirement], self.local_index, self.easy_install
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 522, in resolve
    dist = best[req.key] = env.best_match(req, self, installer)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 758, in best_match
    return self.obtain(req, installer) # try and download/install
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 770, in obtain
    return installer(requirement)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 446, in easy_install
    return self.install_item(spec, dist.location, tmpdir, deps)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 476, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 655, in install_eggs
    return self.build_and_install(setup_script, setup_base)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 930, in build_and_install
    self.run_setup(setup_script, setup_base, args)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 919, in run_setup
    run_setup(setup_script, args)
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 27, in run_setup   
    lambda: execfile(
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 63, in run
    return func()
  File
"/usr/local/stow/python-release25-maint-2008-05-30/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 29, in <lambda>
    {'__file__':setup_script, '__name__':'__main__'}
  File "setup.py", line 8, in <module>

  File "/tmp/easy_install-Nib-SJ/Nevow-0.9.31/setupcommon.py", line 2, in <module>
  File "/tmp/easy_install-Nib-SJ/Nevow-0.9.31/nevow/__init__.py", line 10, in
<module>
ImportError: No module named components
"""

The __init__.py file in question is here:

http://divmod.org/trac/browser/trunk/Nevow/nevow/__init__.py?rev=14968

Now if you try to install the actual project -- allmydata.org Tahoe -- from
which this minimal project was extracted:

http://allmydata.org/trac/tahoe/browser/setup.py

You'll get a bizarre error message that takes the name of PIL in vain:

"""
 File
"/home/agl/src/allmydata-tahoe-1.0.0-r2613/setuptools-0.6c8.egg/setuptools/sandbox.py",
line 27, in run_setup
 File
"/home/agl/src/allmydata-tahoe-1.0.0-r2613/setuptools-0.6c8.egg/setuptools/sandbox.py",
line 63, in run
 File
"/home/agl/src/allmydata-tahoe-1.0.0-r2613/setuptools-0.6c8.egg/setuptools/sandbox.py",
line 29, in <lambda>
 File "setup.py", line 8, in <module>
   #
 File "/tmp/easy_install-fqJkNC/Nevow-0.9.18/setupcommon.py", line 2,
in <module>
 File "/usr/lib/python2.5/site-packages/PIL/__init__.py", line 10, in <module>
   #
ImportError: No module named components
"""

Note that allmydata.org Tahoe does not use PIL in any way.  There are no hits
for "grep -r PIL ." in the Tahoe source tree.

Going back to the minimal projects, we can tell that this effect has something
to do with the presence or absence of a Twisted*.egg in the current working
directory when "./setup.py install" is invoked.  That is:

If this minimal project is invoked in an empty directory (and also when no
Twisted, Nevow, or zope.interface installed in the system), then we get the
weird error about failure to import components even though the earlier "from
twisted.python import versions" succeeded.  This will leave a Twisted .egg in
the CWD.

If it is invoked in an otherwise empty directory that has a Twisted egg, then it
will succeed (and leave a Twisted .egg in the CWD).  (Hm.  Actually now that I
look in the target install directory, I see that it installed Nevow into there
but not Twisted or zope.interface (which Twisted requires).  It seems like that
is a problem, but it is probably a separate problem from this ticket.)

----------
messages: 35
nosy: zooko
priority: bug
status: unread
title: package required at build time seems to be not fully present at install time?

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

From jcea at jcea.es  Tue Jun  3 18:48:36 2008
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 03 Jun 2008 18:48:36 +0200
Subject: [Distutils] PYPI and packages for Python 2.x and 3.x
In-Reply-To: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za>
References: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za>
Message-ID: <484575E4.2000001@jcea.es>

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

Sorry if this is already answered, but I have no found any reference
about this issue.

Suppose I have a package indexed in PYPI. I have two versions: python
2.x and 3.x. The code has C inside, so it is distributed as a tar.gz,
not an egg.

How is setuptools/easy_install to download the right version for my
python installation? :-??

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSEV13Zlgi5GaxT1NAQKfgQP/YNgOiXNJbZ7A9MT3yaNwPU6bsQeHAy3F
d+iPf3waAfTVouIsrs7l9nw8EC6vpp6353XlqaEPMwJnrBKB7sIew58z1g2ipveB
I7vp8oIsmkKZ6gtmkpys9a1mU507TVuwrHSSrNyOlAcsVMF5203tzRvFM8CK4SWz
7H3RNBUuMdI=
=sn6g
-----END PGP SIGNATURE-----

From ziade.tarek at gmail.com  Tue Jun  3 19:22:43 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 3 Jun 2008 19:22:43 +0200
Subject: [Distutils] PYPI and packages for Python 2.x and 3.x
In-Reply-To: <484575E4.2000001@jcea.es>
References: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za>
	<484575E4.2000001@jcea.es>
Message-ID: <94bdd2610806031022l67a045fbj5e5c1f74d6ea9734@mail.gmail.com>

On Tue, Jun 3, 2008 at 6:48 PM, Jesus Cea <jcea at jcea.es> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sorry if this is already answered, but I have no found any reference
> about this issue.
>
> Suppose I have a package indexed in PYPI. I have two versions: python
> 2.x and 3.x. The code has C inside, so it is distributed as a tar.gz,
> not an egg.
>
> How is setuptools/easy_install to download the right version for my
> python installation? :-??


Binary distributions have the name of the platform it was built on in the
filename.

See setuptools for instance: http://pypi.python.org/pypi/setuptools



>
>
> - --
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> jabber / xmpp:jcea at jabber.org <xmpp%3Ajcea at jabber.org>         _/_/
>  _/_/          _/_/_/_/_/
> .                              _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBSEV13Zlgi5GaxT1NAQKfgQP/YNgOiXNJbZ7A9MT3yaNwPU6bsQeHAy3F
> d+iPf3waAfTVouIsrs7l9nw8EC6vpp6353XlqaEPMwJnrBKB7sIew58z1g2ipveB
> I7vp8oIsmkKZ6gtmkpys9a1mU507TVuwrHSSrNyOlAcsVMF5203tzRvFM8CK4SWz
> 7H3RNBUuMdI=
> =sn6g
> -----END PGP SIGNATURE-----
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080603/4e946975/attachment.htm>

From ziade.tarek at gmail.com  Tue Jun  3 19:24:12 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 3 Jun 2008 19:24:12 +0200
Subject: [Distutils] PYPI and packages for Python 2.x and 3.x
In-Reply-To: <94bdd2610806031022l67a045fbj5e5c1f74d6ea9734@mail.gmail.com>
References: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za>
	<484575E4.2000001@jcea.es>
	<94bdd2610806031022l67a045fbj5e5c1f74d6ea9734@mail.gmail.com>
Message-ID: <94bdd2610806031024k161c60c5y624a783a0c2aa284@mail.gmail.com>

On Tue, Jun 3, 2008 at 7:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

>
>
> On Tue, Jun 3, 2008 at 6:48 PM, Jesus Cea <jcea at jcea.es> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Sorry if this is already answered, but I have no found any reference
>> about this issue.
>>
>> Suppose I have a package indexed in PYPI. I have two versions: python
>> 2.x and 3.x. The code has C inside, so it is distributed as a tar.gz,
>> not an egg.
>>
>> How is setuptools/easy_install to download the right version for my
>> python installation? :-??
>
>
> Binary distributions have the name of the platform it was built on in the
> filename.
>

and the python version


>
> See setuptools for instance: http://pypi.python.org/pypi/setuptools
>
>
>
>>
>>
>> - --
>> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
>> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
>> jabber / xmpp:jcea at jabber.org <xmpp%3Ajcea at jabber.org>         _/_/
>>  _/_/          _/_/_/_/_/
>> .                              _/_/  _/_/    _/_/          _/_/  _/_/
>> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
>> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
>> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.8 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iQCVAwUBSEV13Zlgi5GaxT1NAQKfgQP/YNgOiXNJbZ7A9MT3yaNwPU6bsQeHAy3F
>> d+iPf3waAfTVouIsrs7l9nw8EC6vpp6353XlqaEPMwJnrBKB7sIew58z1g2ipveB
>> I7vp8oIsmkKZ6gtmkpys9a1mU507TVuwrHSSrNyOlAcsVMF5203tzRvFM8CK4SWz
>> 7H3RNBUuMdI=
>> =sn6g
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
>
> --
> Tarek Ziad? | Association AfPy | www.afpy.org
> Blog FR | http://programmation-python.org
> Blog EN | http://tarekziade.wordpress.com/




-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080603/5dcb3ec9/attachment.htm>

From jcea at jcea.es  Tue Jun  3 19:43:19 2008
From: jcea at jcea.es (Jesus Cea)
Date: Tue, 03 Jun 2008 19:43:19 +0200
Subject: [Distutils] PYPI and packages for Python 2.x and 3.x
In-Reply-To: <94bdd2610806031022l67a045fbj5e5c1f74d6ea9734@mail.gmail.com>
References: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za>	
	<484575E4.2000001@jcea.es>
	<94bdd2610806031022l67a045fbj5e5c1f74d6ea9734@mail.gmail.com>
Message-ID: <484582B7.1040309@jcea.es>

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

Tarek Ziad? wrote:
|> Binary distributions have the name of the platform it was built on in
|> the filename.

I know. But I want to distribute a tar.gz source package. I can't
distribute binaries for 20 different platforms/python versions.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSEWCt5lgi5GaxT1NAQJW9gP/QU29rpuWCi275Ff+d0GkWksOOvfu90Qc
t13I9B8Hj4oRU/brjPJ5JtHel7l55HK7Dxlp0xOpGDuysMJUpf06u4d6K163ugqg
Xt87xlZz0ercOmJBjyJOI77zukK03Za/uMpi0pjUvTvDq+C15AX757nEVftFpQVC
lFEvCjQ2V/E=
=OG1r
-----END PGP SIGNATURE-----

From pje at telecommunity.com  Tue Jun  3 19:53:20 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 03 Jun 2008 13:53:20 -0400
Subject: [Distutils] PYPI and packages for Python 2.x and 3.x
In-Reply-To: <484582B7.1040309@jcea.es>
References: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za>
	<484575E4.2000001@jcea.es>
	<94bdd2610806031022l67a045fbj5e5c1f74d6ea9734@mail.gmail.com>
	<484582B7.1040309@jcea.es>
Message-ID: <20080603175305.624583A407F@sparrow.telecommunity.com>

At 07:43 PM 6/3/2008 +0200, Jesus Cea wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Tarek Ziad? wrote:
>|> Binary distributions have the name of the platform it was built on in
>|> the filename.
>
>I know. But I want to distribute a tar.gz source package. I can't
>distribute binaries for 20 different platforms/python versions.

My suggestion: make a setup.py that simply checks the running version 
of Python, and then execfiles 'setup2.py' or 'setup3.py' 
accordingly.  That should be relatively future-proof.

Personally, I'm not aware that anyone has successfully run setuptools 
on Python 3 anyway, so it's likely moot.  (In truth, I'm not sure how 
much *distutils* has been tested on Python 3.)


From ziade.tarek at gmail.com  Tue Jun  3 19:55:50 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 3 Jun 2008 19:55:50 +0200
Subject: [Distutils] PYPI and packages for Python 2.x and 3.x
In-Reply-To: <484582B7.1040309@jcea.es>
References: <1212163758.13.0.0315232428985.issue14@psf.upfronthosting.co.za>
	<484575E4.2000001@jcea.es>
	<94bdd2610806031022l67a045fbj5e5c1f74d6ea9734@mail.gmail.com>
	<484582B7.1040309@jcea.es>
Message-ID: <94bdd2610806031055s7a9d54acvc9ea22ac72761520@mail.gmail.com>

On Tue, Jun 3, 2008 at 7:43 PM, Jesus Cea <jcea at jcea.es> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
> |> Binary distributions have the name of the platform it was built on in
> |> the filename.
>
> I know. But I want to distribute a tar.gz source package. I can't
> distribute binaries for 20 different platforms/python versions.


You can have one source distribution but not for different versions of
Python.
I would deal with Python versions inside the package itself, in the setup.py
script
and hav both version in it.




>
>
> - --
> Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
> jabber / xmpp:jcea at jabber.org <xmpp%3Ajcea at jabber.org>         _/_/
>  _/_/          _/_/_/_/_/
> .                              _/_/  _/_/    _/_/          _/_/  _/_/
> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBSEWCt5lgi5GaxT1NAQJW9gP/QU29rpuWCi275Ff+d0GkWksOOvfu90Qc
> t13I9B8Hj4oRU/brjPJ5JtHel7l55HK7Dxlp0xOpGDuysMJUpf06u4d6K163ugqg
> Xt87xlZz0ercOmJBjyJOI77zukK03Za/uMpi0pjUvTvDq+C15AX757nEVftFpQVC
> lFEvCjQ2V/E=
> =OG1r
>
> -----END PGP SIGNATURE-----
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080603/66109591/attachment-0001.htm>

From setuptools at bugs.python.org  Tue Jun  3 22:15:50 2008
From: setuptools at bugs.python.org (chris)
Date: Tue, 03 Jun 2008 20:15:50 +0000
Subject: [Distutils] [issue21] adding uninstall feature to easy_install
In-Reply-To: <1212524150.82.0.866399669719.issue21@psf.upfronthosting.co.za>
Message-ID: <1212524150.82.0.866399669719.issue21@psf.upfronthosting.co.za>


New submission from chris <cdcasey at gmail.com>:

There is currently no uninstall feature in setuptools. Here is a proposed
implementation:

 * By default, use easy_install's --record option and place the resulting file
list in the project's EGG-INFO directory, whether the project is zip-safe or
not. Use the list for determining which files should be uninstalled.

 * Do a back-check of dependencies on all currently installed projects, and warn
the user how uninstalling a project could affect other projects. 

 * Provide option of uninstalling dependencies that are no longer needed by the
project being uninstalled (or other installed projects).

 * Remove entry from easy_install.pth

----------
messages: 38
nosy: ccasey
priority: feature
status: chatting
title: adding uninstall feature to easy_install

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

From ziade.tarek at gmail.com  Wed Jun  4 13:43:50 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 4 Jun 2008 13:43:50 +0200
Subject: [Distutils] [buildout] testing framework - avoiding os.popen calls
Message-ID: <94bdd2610806040443k5ef78c5ev47cc63f9d85dd435@mail.gmail.com>

Hello

Right now when people write tests with zc.buildout, to try out their
buildout they roughly do:

>>> from zc.buildout.testing import system
>>> system('bin/buildout -c my-config.cfg')
...
usual output
...

The problem is, the system() function uses os.popen to call the buildout
script, making it hard to debug.
For instance, you are not able to put a pdb and trace as you would do in the
same program, which is painful

What about adding in zc.buildout.testing a new function called "buildout"
that could be used to run
a buildout in the tests/doctests the same way :

>>> from zc.buildout.testing import buildout
>>> buildout('my-config.cfg')
...
usual output
...

I could do a branch for that but if everyone agrees, I guess I can push that
extra function into the trunk

++
Tarek

-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080604/257258fc/attachment.htm>

From jim at zope.com  Wed Jun  4 16:43:20 2008
From: jim at zope.com (Jim Fulton)
Date: Wed, 4 Jun 2008 10:43:20 -0400
Subject: [Distutils] [buildout] testing framework - avoiding os.popen
	calls
In-Reply-To: <94bdd2610806040443k5ef78c5ev47cc63f9d85dd435@mail.gmail.com>
References: <94bdd2610806040443k5ef78c5ev47cc63f9d85dd435@mail.gmail.com>
Message-ID: <81AAC931-EF28-4A2F-B4CD-782C3E18CD88@zope.com>


On Jun 4, 2008, at 7:43 AM, Tarek Ziad? wrote:

> Hello
>
> Right now when people write tests with zc.buildout, to try out their  
> buildout they roughly do:
>
> >>> from zc.buildout.testing import system
> >>> system('bin/buildout -c my-config.cfg')
> ...
> usual output
> ...
>
> The problem is, the system() function uses os.popen to call the  
> buildout script, making it hard to debug.
> For instance, you are not able to put a pdb and trace as you would  
> do in the same program, which is painful
>
> What about adding in zc.buildout.testing a new function called  
> "buildout" that could be used to run
> a buildout in the tests/doctests the same way :
>
> >>> from zc.buildout.testing import buildout
> >>> buildout('my-config.cfg')
> ...
> usual output
> ...
>
> I could do a branch for that but if everyone agrees, I guess I can  
> push that extra function into the trunk


I think it would be very hard to get this right.  A better solution  
might be to add a Python API to buildout and use that.  Buildout isn't  
currently designed to be used that way, but a Python API would be a  
nice enhancement.

Jim

--
Jim Fulton
Zope Corporation



From setuptools at bugs.python.org  Wed Jun  4 18:56:49 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 04 Jun 2008 16:56:49 +0000
Subject: [Distutils] [issue22] wish: more expressive requirements
In-Reply-To: <1212598606.8.0.961934519496.issue22@psf.upfronthosting.co.za>
Message-ID: <1212598606.8.0.961934519496.issue22@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

There is a bug which manifests itself if you combine Twisted v8.1.0 with
pyOpenSSL v0.7.  It doesn't happen with pyOpenSSL v0.6.  However, the bug is a
bug in Twisted, not in pyOpenSSL.  Future releases of Twisted will probably fix
the bug.  Future releases of pyOpenSSL will probably be unchanged with respect
to this issue.

So the right way for the foolscap project to express its dependency on Twisted
and pyOpenSSL should probably be something like:

(Twisted < 8.2 && pyOpenSSL == 0.6) || (Twisted >= 8.2 && pyOpenSSL >= 0.7)

Since setuptools doesn't currently support expression of such requirements, the
foolscap author is going to write:

['Twisted', 'pyOpenSSL == 0.6']

Thus preventing people from using a newer version of pyOpenSSL with foolscap
until Twisted is fixed, then the author of foolscap learns that Twisted is
fixed, then he changes his requirements to ['Twisted >= $FIXED_VER', 'pyOpenSSL
>= 0.6'], then he releases a new release of foolscap, then people upgrade to it.

So this wishlist item is for setuptools to develop the ability to express
requirements on combinations of packages so that the correct dependency (the
first one listed above) can be expressed.

----------
messages: 39
nosy: zooko
priority: wish
status: unread
title: wish: more expressive requirements

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

From ronaldoussoren at mac.com  Tue Jun  3 10:12:18 2008
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Jun 2008 10:12:18 +0200
Subject: [Distutils] [issue19] Will setuptools on Mac Python accept fat
 eggs?
In-Reply-To: <1212450611.1.0.774353636038.issue19@psf.upfronthosting.co.za>
References: <1212450611.1.0.774353636038.issue19@psf.upfronthosting.co.za>
Message-ID: <8CA4E7F5-743A-4C46-9EDD-7E7D0044B78A@mac.com>


On 3 Jun, 2008, at 1:50, Zooko O'Whielacronx wrote:

>
> New submission from Zooko O'Whielacronx <zooko at zooko.com>:
>
> There was a time, last November, when, if I understand it correctly,  
> setuptools
> on the standard Python that comes with Mac OS X wouldn't accept fat  
> eggs for Mac
> OS X 10.4 or higher.
>
> Here is the pythonmac-sig discussion:
>
> http://www.nabble.com/does-pkg_resources-think-that-%22macosx-10.3%22-is-incompatible-with-10.5--to13865060.html#a13865060
>
> Ronald Oussoren has committed the fix for the comparison of Mac OS X  
> version
> numbers from '<' to '>=', so as of Python 2.5.2 that problem is  
> fixed.  However,
> he mentioned other problems which I didn't understand:
>
> """the config/Makefile in
> Apple's Python.framework isn't configured for building universal
> binaries.
>
> And to make matters even worse: I'm pretty sure that setuptools used
> to know that 'fat' builds are compatible with 'i386' and 'ppc'
> architectures (at least on OSX), but that code no longer seems to be
> there.
> """
>
> What is the status of this issue now?

That's an issue in Apple's build of Python and not something we can fix.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080603/5554c736/attachment.bin>

From zooko at zooko.com  Sat Jun  7 23:08:44 2008
From: zooko at zooko.com (zooko)
Date: Sat, 7 Jun 2008 14:08:44 -0700
Subject: [Distutils] [issue19] Will setuptools on Mac Python accept fat
	eggs?
In-Reply-To: <8CA4E7F5-743A-4C46-9EDD-7E7D0044B78A@mac.com>
References: <1212450611.1.0.774353636038.issue19@psf.upfronthosting.co.za>
	<8CA4E7F5-743A-4C46-9EDD-7E7D0044B78A@mac.com>
Message-ID: <36C53309-47A8-4D14-96BA-F56403A0FCC9@zooko.com>

On Jun 3, 2008, at 1:12 AM, Ronald Oussoren wrote:

> That's an issue in Apple's build of Python and not something we can  
> fix.

So what is the status of this issue now, from the perspective of a user?

Do we have to avoid building binary distributions on certain versions  
of Mac OS X, or certain CPU architectures?  Do we need to build  
separate "PPC" and "x86" binary distributions?

Or is everything going to work fine and, as a user of Python and  
distutils and setuptools, I can ignore this issue?

Regards,

Zooko


From eliben at gmail.com  Mon Jun  9 07:42:41 2008
From: eliben at gmail.com (Eli Bendersky)
Date: Mon, 9 Jun 2008 07:42:41 +0200
Subject: [Distutils] libcollect - collecting all the libraries used by a
	script
Message-ID: <95cf475a0806082242v451922cfw2da00b5945c69dfc@mail.gmail.com>

Hello,

Motivation:

Imagine that you've written a script that uses several libraries, some of
which you've written and some you've downloaded and installed (for example
PyYAML). You want to distribute the script to your friends and co-workers,
who already have Python installed with all the standard library. But your
script won't run on their machines, because they have neither your personal
libraries, nor PyYAML installed. So what can you do ?
* You can ask them to install PyYAML and other libraries your script uses,
  and send them your own libraries. This is a lengthy and inconvenient
  process.
* You can use a tool like py2exe to package your delivery. This has a
  downside, however. py2exe produces large files (several MBs) and you may
  not want that.
* You can painstakingly collect the libraries into a directory where your
  script can find them, and package the directory together with the script.

I've written libcollect - a module that allows you to easily do the
third option. The full docstring of libcollect is pasted in the bottom
of this email. The module is downloadable from
http://eli.thegreenplace.net/files/prog_code/libcollect.py.txt

I wanted to ask this list:

1) Is there something similar already and I've reimplemented the wheel ?
2) If not, then am I the only one who finds such a utility useful ?
3) If it looks useful to others, doesn't it belong with distutils ?
Its operation is in many ways similar to py2exe - it does a subset of
py2exe's work, really.

Thanks in advance
Eli




"""
libcollect.py

Provides the LibCollect class, used for collecting the various libraries
your script uses for delivery as a self-contained distribution package.

Author: Eli Bendersky (http://eli.thegreenplace.net)
License: Same as Python

Motivation:

Imagine that you've written a script that uses several libraries, some of
which you've written and some you've downloaded and installed (for example
PyYAML). You want to distribute the script to your friends and co-workers,
who already have Python installed with all the standard library. But your
script won't run on their machines, because they have neither your personal
libraries, nor PyYAML installed. So what can you do ?
* You can ask them to install PyYAML and other libraries your script uses,
  and send them your own libraries. This is a lengthy and inconvenient
  process.
* You can use a tool like py2exe to package your delivery. This has a
  downside, however. py2exe produces large files (several MBs) and you may
  not want that.
* You can painstakingly collect the libraries into a directory where your
  script can find them, and package the directory together with the script.

LibCollect makes the third option trivial, by doing all the dirty work
for you.

Example:

Suppose your script is named script.py, and is located in directory $DIR
(although I'm using Unix-y notation here, it is for convenience only.
LibCollect works similarly well on Windows platforms). Follow these steps
to prepare a self-contained distribution with LibCollect:

Create a distribution setup script in the same directory. Lets assume
you call it distrib_script.py. You can easily place it in any directory
you like, I'm using the same one to make the example simpler.

Add the following to distrib_script.py (assuming that libcollect.py is
in your sys.path):

**************************************************************

import libcollect

# Create a LibCollect object
lc = libcollect.LibCollect()

# Prepare arguments for do_collect
#

# Path to the script (can be absolute or relative)
scriptname = 'script.py'

# Ask the resulting distribution to be placed in
# directory distrib
targetdir = 'distrib'

# Specify which libraries to exclude from the
# distribution (because you know they're installed
# on the target machine)
excludes = ["wx",
            "pywin",
            "win32api",
            "win32com"]

# Zip the libraries used by the script to reduce
# clutter and save space
zip_lib = True

# This does the actual work
lc.do_collect(  scriptname,
                targetdir,
                excludes,
                zip_lib=zip_lib)

**************************************************************

Now run distrib_script.py.
When it finishes running, you will see that the distrib directory
has been created in $DIR. In $DIR/distrib you will see two files,
script.py and distlib.zip

* script.py is a loader that replaces your original script.py - this
  is the program your users should run. All it does (look at the
  code, it's short!) is prepare the sys.path to include the
  packaged libraries, and runs your own script.py that was also
  packaged into the .zip file
* distlib.zip is the distribution library, containing all the code
  your script needs to run on any machine with Python installed,
  and nothing else (except the modules you specified in the exclusion
  list). You may choose to pass on the zip file creation and leave
  your distribution library as a directory by providing False
  to the zip_lib argument of LibCollect.do_collect (take a look at
  its documentation, there are some other options there)

How to use LibCollect:

* It is most convenient to use LibCollect in the way demonstrated
  in the example above. You may want to update your application from
  time to time, and having a distribution script handy will turn
  the preparation of a new distribution into a 5-second process.
* If you don't want to create a distribution script, you can use
  a more direct method of invoking libcollect.py as a program on
  your script. Call it without arguments and it will print
  a usage string that will explain what you need to do.

How it works:

* LibCollect uses the standard modulefinder module to find out which
  libraries are used by your script. It categorizes them into two
  types: standard libraries that came with Python, and non-standard
  libraries you've installed or written.
* Only libraries of the second type are included in the distribution
  (bar the libraries you've explicitly asked to exclude).
* It then builds a directory with all the included libraries, in a
  way that your script will be able to find them. The script itself
  is also packaged into the same place.
* On request, this directory can be zipped into a single file, to
  employ Python's built-in zip import facility.
* In the distribution directory, a new file with the name of your
  script is created. It is a simple loader that uses the runpy module
  to transparently load your script from the distribution library.
  This way your script is not being modified (sys.path is rigged
  from the loader).

Compatibility:
    Python 2.5
    Tested on Windows and Linux, but should work on other platforms
    where the standard Python distribution works.

Version history:

    1.0  (2008.06.07): initial release

"""

From zooko at zooko.com  Tue Jun 10 00:49:46 2008
From: zooko at zooko.com (zooko)
Date: Mon, 9 Jun 2008 15:49:46 -0700
Subject: [Distutils] a leak in the setuptools sandbox
Message-ID: <ACEEC093-B087-4166-8192-1D90C2BD3B34@zooko.com>

Folks:

I just added this note to the bug tracker, but I'm not sure if anyone  
who has the ability to commit fixes to setuptools is reading all  
updates to all tickets on that tracker, so I wanted to draw attention  
to it here:

http://bugs.python.org/setuptools/issue20 # package required at build  
time seems to be not fully present at install time?

"""
Okay Brian Warner and I just tracked this issue down a bit, since it  
is blocking
the release of the next version of the Tahoe Least-Authority Filesystem.

It turns out that when setuptools builds Twisted from source in a  
"setuptools
sandbox", that this causes the import of a few things including  
"twisted" and
"twisted._version".  These get added to sys.modules, and then this  
side-effect
on sys.modules is not undone after Twisted has been built and  
installed, so in a
sense changes to sys.modules can "leak" out of the sandbox.

Nevow's build process then tries to import twisted.components, which  
was not
imported by Twisted's build process, so it isn't already in  
sys.modules, but
also cannot be imported from the newly installed Twisted, because  
"twisted" is
already in sys.modules (with a directory location of ".", which  
refers to a
temporary directory when it was being built which has since been  
deleted).

This is why Nevow cannot be installed in the same setuptools process  
as Twisted was.

A good way to improve this would be to make the setuptools sandbox  
"tighter" --
make it so that the act of building and installing one distribution  
doesn't have
side-effects on the sys.modules which effect the attempt to later  
build another
distribution.  A good way to do this is to use a subprocess.  If you  
don't want
the code that you are about to execute to have side-effects on your  
Python
state, then execute that code in a subprocess.  Another way to fix  
this would be
to figure out which names had been added to sys.modules during the  
"build in a
sandbox" and clean them out afterward.
"""

From pfein at pobox.com  Tue Jun 10 06:12:09 2008
From: pfein at pobox.com (Pete)
Date: Tue, 10 Jun 2008 00:12:09 -0400
Subject: [Distutils] a leak in the setuptools sandbox
In-Reply-To: <ACEEC093-B087-4166-8192-1D90C2BD3B34@zooko.com>
References: <ACEEC093-B087-4166-8192-1D90C2BD3B34@zooko.com>
Message-ID: <A15CD534-163D-46B1-95CA-528A93228032@pobox.com>

On Jun 9, 2008, at 6:49 PM, zooko wrote:

> Folks:
>
> I just added this note to the bug tracker, but I'm not sure if  
> anyone who has the ability to commit fixes to setuptools is reading  
> all updates to all tickets on that tracker, so I wanted to draw  
> attention to it here:

*Is* anyone with setuptools commit privileges using the bug tracker or  
are we all just wasting our time?

From pje at telecommunity.com  Tue Jun 10 17:15:51 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 10 Jun 2008 11:15:51 -0400
Subject: [Distutils] a leak in the setuptools sandbox
In-Reply-To: <A15CD534-163D-46B1-95CA-528A93228032@pobox.com>
References: <ACEEC093-B087-4166-8192-1D90C2BD3B34@zooko.com>
	<A15CD534-163D-46B1-95CA-528A93228032@pobox.com>
Message-ID: <20080610151523.8A4303A405F@sparrow.telecommunity.com>

At 12:12 AM 6/10/2008 -0400, Pete wrote:
>On Jun 9, 2008, at 6:49 PM, zooko wrote:
>
>>Folks:
>>
>>I just added this note to the bug tracker, but I'm not sure if
>>anyone who has the ability to commit fixes to setuptools is reading
>>all updates to all tickets on that tracker, so I wanted to draw
>>attention to it here:
>
>*Is* anyone with setuptools commit privileges using the bug tracker or
>are we all just wasting our time?

I'm using it; I just don't have very much free time.


From zooko at zooko.com  Tue Jun 10 19:31:41 2008
From: zooko at zooko.com (zooko)
Date: Tue, 10 Jun 2008 10:31:41 -0700
Subject: [Distutils] a leak in the setuptools sandbox
In-Reply-To: <20080610151523.8A4303A405F@sparrow.telecommunity.com>
References: <ACEEC093-B087-4166-8192-1D90C2BD3B34@zooko.com>
	<A15CD534-163D-46B1-95CA-528A93228032@pobox.com>
	<20080610151523.8A4303A405F@sparrow.telecommunity.com>
Message-ID: <1BAD9A4B-C075-42D4-B51C-F726679D20D3@zooko.com>

On Jun 10, 2008, at 8:15 AM, Phillip J. Eby wrote:

> At 12:12 AM 6/10/2008 -0400, Pete wrote:
>>
>> *Is* anyone with setuptools commit privileges using the bug  
>> tracker or
>> are we all just wasting our time?
>
> I'm using it; I just don't have very much free time.

Is there anyone other than PJE who has commit privs for setuptools?

Maybe setuptools would benefit from having some more folks whose job  
is mainly to fix bugs on the stable branch and make releases.

Regards,

Zooko


From setuptools at bugs.python.org  Wed Jun 11 00:32:35 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 10 Jun 2008 22:32:35 +0000
Subject: [Distutils] [issue23] SandboxViolation:
	mkdir('/Users/zooko/.python-eggs', 511) {}
In-Reply-To: <1213137154.81.0.225964708566.issue23@psf.upfronthosting.co.za>
Message-ID: <1213137154.81.0.225964708566.issue23@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

When I do "easy_install Nevow" on my Mac OS 10.4 on PowerPC, I get the following:

Searching for Nevow
Reading http://pypi.python.org/simple/Nevow/
Reading http://divmod.org/trac/wiki/DivmodNevow
Reading http://divmod.org/projects/nevow
Reading http://www.divmod.org/
Best match: Nevow 0.9.31
Downloading
http://divmod.org/trac/attachment/wiki/SoftwareReleases/Nevow-0.9.31.tar.gz?format=raw
Processing Nevow-0.9.31.tar.gz
Running Nevow-0.9.31/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-_xanA9/Nevow-0.9.31/egg-dist-tmp-3qYEDS
/tmp/easy_install-_xanA9/Nevow-0.9.31/nevow/context.py:37: Warning: 'with' will
become a reserved keyword in Python 2.6
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.5/bin/easy_install",
line 8, in <module>
    load_entry_point('setuptools==0.6c8', 'console_scripts', 'easy_install')()
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 1671, in main
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 1659, in with_ei_usage
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 1675, in <lambda>
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py",
line 151, in setup
    dist.run_commands()
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 974, in run_commands
    self.run_command(cmd)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/dist.py",
line 994, in run_command
    cmd_obj.run()
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 211, in run
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 446, in easy_install
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 476, in install_item
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 655, in install_eggs
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 930, in build_and_install
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/command/easy_install.py",
line 919, in run_setup
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 27, in run_setup
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 63, in run
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/setuptools/sandbox.py",
line 29, in <lambda>
  File "setup.py", line 8, in <module>
    # 
  File "/tmp/easy_install-_xanA9/Nevow-0.9.31/setupcommon.py", line 2, in <module>
  File "/tmp/easy_install-_xanA9/Nevow-0.9.31/nevow/__init__.py", line 143, in
<module>
  File "/tmp/easy_install-_xanA9/Nevow-0.9.31/nevow/__init__.py", line 29, in load
  File "/tmp/easy_install-_xanA9/Nevow-0.9.31/nevow/util.py", line 183, in
_namedAnyWithBuiltinTranslation
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/python/reflect.py",
line 426, in namedAny
    topLevelPackage = _importAndCheckStack(trialname)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/python/reflect.py",
line 377, in _importAndCheckStack
    return __import__(importName)
  File "/tmp/easy_install-_xanA9/Nevow-0.9.31/formless/webform.py", line 24, in
<module>
  File "/tmp/easy_install-_xanA9/Nevow-0.9.31/nevow/static.py", line 18, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/web/error.py",
line 11, in <module>
    from twisted.web import http
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/web/http.py",
line 36, in <module>
    from twisted.internet import interfaces, reactor, protocol, address
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/internet/reactor.py",
line 11, in <module>
    from twisted.internet import selectreactor
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/internet/selectreactor.py",
line 21, in <module>
    from twisted.internet import posixbase
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/internet/posixbase.py",
line 25, in <module>
    from twisted.internet import tcp, udp
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Twisted-8.1.0-py2.5-macosx-10.3-fat.egg/twisted/internet/tcp.py",
line 29, in <module>
    from OpenSSL import SSL
  File "build/bdist.macosx-10.3-fat/egg/OpenSSL/__init__.py", line 11, in <module>
  File "build/bdist.macosx-10.3-fat/egg/OpenSSL/rand.py", line 7, in <module>
  File "build/bdist.macosx-10.3-fat/egg/OpenSSL/rand.py", line 4, in __bootstrap__
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 841, in resource_filename
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 1311, in get_resource_filename
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 1332, in _extract_resource
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 921, in get_cache_path
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg/pkg_resources.py",
line 887, in extraction_error
pkg_resources.ExtractionError: Can't extract file(s) to egg cache

The following error occurred while trying to extract file(s) to the Python egg
cache:

  SandboxViolation: mkdir('/Users/zooko/.python-eggs', 511) {}

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

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

The Python egg cache directory is currently set to:

  /Users/zooko/.python-eggs

Perhaps your account does not have write access to this directory?  You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory.

----------
messages: 44
nosy: zooko
priority: bug
status: unread
title: SandboxViolation: mkdir('/Users/zooko/.python-eggs', 511) {}

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

From eliben at gmail.com  Fri Jun 13 07:51:28 2008
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 13 Jun 2008 07:51:28 +0200
Subject: [Distutils] py2exe finding dll's
Message-ID: <95cf475a0806122251g32e97809hfe516957b0250c75@mail.gmail.com>

Hello,

I've always assumed that py2exe uses modulefinder (or rather a
self-written version thereof) to find the modules used by the packaged
application. However, I see that py2exe manages to find things that
modulefinder doesn't find, such as DLLs. For example, when packaging
an app that uses wxPython, modulefinder finds only the relevant .py
and .pyd / .pyo files, while py2exe also finds all the wx DLLs.
What kind of additional searches does py2exe do to find all the
required infromation?

Eli

From cdcasey at gmail.com  Wed Jun 11 23:13:30 2008
From: cdcasey at gmail.com (chris)
Date: Wed, 11 Jun 2008 16:13:30 -0500
Subject: [Distutils] uninstall feature
Message-ID: <ead057790806111413v9a1e036u868327eb9d29b727@mail.gmail.com>

A few days ago I submitted a ticket for adding an uninstall feature in
setuptools. Today I submitted a patch that implements it. If anyone
would like to try it out and give feedback, the ticket (and patch) is
here:

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

Thanks,
Chris

From theller at ctypes.org  Fri Jun 13 13:47:45 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 13 Jun 2008 13:47:45 +0200
Subject: [Distutils] py2exe finding dll's
In-Reply-To: <95cf475a0806122251g32e97809hfe516957b0250c75@mail.gmail.com>
References: <95cf475a0806122251g32e97809hfe516957b0250c75@mail.gmail.com>
Message-ID: <g2tmp2$tg4$1@ger.gmane.org>

Eli Bendersky schrieb:
> Hello,
> 
> I've always assumed that py2exe uses modulefinder (or rather a
> self-written version thereof) to find the modules used by the packaged
> application. However, I see that py2exe manages to find things that
> modulefinder doesn't find, such as DLLs. For example, when packaging
> an app that uses wxPython, modulefinder finds only the relevant .py
> and .pyd / .pyo files, while py2exe also finds all the wx DLLs.
> What kind of additional searches does py2exe do to find all the
> required infromation?

See the code starting near line 360 in
http://py2exe.cvs.sourceforge.net/py2exe/py2exe/source/py2exe_util.c?view=markup

For each extension module, the depends() function in the py2exe_util module is called,
which in turn calls the Windows BindImageEx api function.  This function calls
a callback (StatusRoutine) with dll names that the extension depends on.

Thomas


From setuptools at bugs.python.org  Fri Jun 13 13:59:11 2008
From: setuptools at bugs.python.org (Armin Ronacher)
Date: Fri, 13 Jun 2008 11:59:11 +0000
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
Message-ID: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Currently the egg installation script is called "easy_install".  I would propose
to rename it to something like "pyegg" or something similar.  Mainly because
"easy_install" is a very generic name and doesn't include anything related with
python in the name which causes confusion.

Additionally if easy_install gets an uninstallation feature the name is wrong too.

----------
messages: 47
nosy: aronacher
priority: wish
status: unread
title: Rename easy_install

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

From setuptools at bugs.python.org  Fri Jun 13 15:47:53 2008
From: setuptools at bugs.python.org (Chris Galvan)
Date: Fri, 13 Jun 2008 13:47:53 +0000
Subject: [Distutils] [issue25] Prefer release versions of projects
In-Reply-To: <1213364873.5.0.953851294141.issue25@psf.upfronthosting.co.za>
Message-ID: <1213364873.5.0.953851294141.issue25@psf.upfronthosting.co.za>


New submission from Chris Galvan <cgalvan at mail.utexas.edu>:

Currently there is no ability to declare a preference for a release of a 
project.  For example, I'd like to say my project requires "a release of 
foo >= 2.0, <3.0".   I'd then like easy_install/setuptools 
to only pick releases (no qualifiers of any kind alpha, beta, dev, etc.) 
of 2.0, 2.1, 2.2, 2.3, 2.4, ....   As a further example, it should 
totally ignore '2.5a1' and '2.6_r15669' and instead would fetch '2.2' if it
existed in the same repository.

It would be nice if this was the default behavior unless the user specified an
additional flag to accept qualifiers(which would return the behavior to its
previous state).  Also, it would fall back on eggs with qualifiers if no
releases were found.

----------
messages: 48
nosy: cgalvan
priority: feature
status: chatting
title: Prefer release versions of projects

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

From zooko at zooko.com  Fri Jun 13 17:58:19 2008
From: zooko at zooko.com (zooko)
Date: Fri, 13 Jun 2008 08:58:19 -0700
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
Message-ID: <5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>

On Jun 13, 2008, at 4:59 AM, Armin Ronacher wrote:
>
> Currently the egg installation script is called "easy_install".  I  
> would propose
> to rename it to something like "pyegg" or something similar.   
> Mainly because
> "easy_install" is a very generic name and doesn't include anything  
> related with
> python in the name which causes confusion.
>
> Additionally if easy_install gets an uninstallation feature the  
> name is wrong too.

-0 from me.

While your reasons are good ones, Armin, it is too late to rename  
easy_install.

Regards,

Zooko


From python at jwp.name  Fri Jun 13 18:17:07 2008
From: python at jwp.name (James William Pye)
Date: Fri, 13 Jun 2008 09:17:07 -0700
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
Message-ID: <94E4C23E-3A72-4478-A7C8-F08084AB4856@jwp.name>

> On Jun 13, 2008, at 4:59 AM, Armin Ronacher wrote:
>>
>> Currently the egg installation script is called "easy_install".  I  
>> would propose
>> to rename it to something like "pyegg" or something similar.   
>> Mainly because
>> "easy_install" is a very generic name and doesn't include anything  
>> related with
>> python in the name which causes confusion.
>>
>> Additionally if easy_install gets an uninstallation feature the  
>> name is wrong too.
>
> -0 from me.
>
> While your reasons are good ones, Armin, it is too late to rename  
> easy_install.


+1 for a rename. Of course, start throwing a deprecation warning  
before removing
the command entirely. :(

From phil_schwartz at users.sourceforge.net  Fri Jun 13 23:36:53 2008
From: phil_schwartz at users.sourceforge.net (Phil Schwartz)
Date: Fri, 13 Jun 2008 14:36:53 -0700
Subject: [Distutils] Creating rpm's for multiple python versions?
Message-ID: <E1K7Gx3-0002k7-Vu@pr-shellA.sourceforge.net>

I have a Fedora Core 7 development server that has python2.3, python2.4 and python2.5 installed.  I'd like to build rpm's of my application for each
of these versions of python.

Python2.5 (/usr/bin/python, /usr/bin/python2, /usr/bin/python2.5) is the default version but the others are available from /usr/bin/python2.3 and
/usr/local/bin/python2.4 (both /usr/bin and /usr/local/bin are in my $PATH).


I've tried the following:

python2.3 setup.py bdist_rpm --python python2.3 \
          --release python2.3 --binary-only

python2.4 setup.py bdist_rpm --python python2.4 \
          --release python2.4 --binary-only

python2.5 setup.py bdist_rpm --python python2.5 \
          --release python2.5 --binary-only


All of the commands complete successfully, however, upon examining the generated dist/ rpm's for 2.3 and 2.4 I've noticed that the "site-packages"
files are all relative the python2.5.  That is, for the 2.3 rpm, there are files that contain the path "/usr/lib/python2.5/site-packages/...".

How can I force the rpm's to include the proper site-packages path (for python2.3 that would be "/usr/lib/python2.3/site-packages/")?

Thanks for any info,

Phil

From cgalvan at mail.utexas.edu  Sat Jun 14 00:42:54 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Fri, 13 Jun 2008 17:42:54 -0500
Subject: [Distutils] [issue25] Prefer release versions of projects
In-Reply-To: <1213364873.5.0.953851294141.issue25@psf.upfronthosting.co.za>
References: <1213364873.5.0.953851294141.issue25@psf.upfronthosting.co.za>
Message-ID: <4852F7EE.2040304@mail.utexas.edu>

I have attached a proposed patch for this feature request to the tracker 
issue, which implements the feature as described in the tracker.  
Passing an '--allow-dev' flag to easy_install will tell setuptools to 
accept qualifiers in the versions of the projects(returns the behavior 
to its previous state).

Chris Galvan wrote:
> <pre wrap>
> New submission from Chris Galvan &lt;cgalvan at mail.utexas.edu&gt;:
>
> Currently there is no ability to declare a preference for a release of a
> project.  For example, I'd like to say my project requires "a release of
> foo &gt;= 2.0, &lt;3.0".   I'd then like easy_install/setuptools
> to only pick releases (no qualifiers of any kind alpha, beta, dev, etc.)
> of 2.0, 2.1, 2.2, 2.3, 2.4, ....   As a further example, it should
> totally ignore '2.5a1' and '2.6_r15669' and instead would fetch '2.2' 
> if it
> existed in the same repository.
>
> It would be nice if this was the default behavior unless the user 
> specified an
> additional flag to accept qualifiers(which would return the behavior 
> to its
> previous state).  Also, it would fall back on eggs with qualifiers if no
> releases were found.
>
> ----------
> messages: 48
> nosy: cgalvan
> priority: feature
> status: chatting
> title: Prefer release versions of projects
>
> _______________________________________________
> Setuptools tracker &lt;setuptools at bugs.python.org&gt;
> &lt;http://bugs.python.org/setuptools/issue25&gt;
> _______________________________________________
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
> </pre></body>
> </html>
> </html>


From ivazqueznet at gmail.com  Sat Jun 14 00:47:38 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 13 Jun 2008 18:47:38 -0400
Subject: [Distutils] Creating rpm's for multiple python versions?
In-Reply-To: <E1K7Gx3-0002k7-Vu@pr-shellA.sourceforge.net>
References: <E1K7Gx3-0002k7-Vu@pr-shellA.sourceforge.net>
Message-ID: <1213397259.18802.51.camel@ignacio.lan>

On Fri, 2008-06-13 at 14:36 -0700, Phil Schwartz wrote:
> I have a Fedora Core 7 development server that has python2.3,
> python2.4 and python2.5 installed.  I'd like to build rpm's of my
> application for each
> of these versions of python.

> How can I force the rpm's to include the proper site-packages path
> (for python2.3 that would be "/usr/lib/python2.3/site-packages/")?

You may want to consider reading Fedora's Python packaging
guidelines[1].

[1] http://fedoraproject.org/wiki/Packaging/Python

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080613/2cadd3b0/attachment.pgp>

From bignose+hates-spam at benfinney.id.au  Sat Jun 14 02:48:18 2008
From: bignose+hates-spam at benfinney.id.au (Ben Finney)
Date: Sat, 14 Jun 2008 10:48:18 +1000
Subject: [Distutils] [issue24] Rename easy_install
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
Message-ID: <87tzfwdep9.fsf@benfinney.id.au>

zooko <zooko at zooko.com> writes:

> While your reasons are good ones, Armin, it is too late to rename
> easy_install.

I don't see why. Care to give some reasons of your own?

As pointed out, the name 'easy_install' isn't strongly associated with
the concepts or other names within setuptools. Changing it isn't
something to do overnight, nor in a single step, but there's plenty of
flux in setuptools at the moment and it's far from "too late" to
change the name of this program.

-- 
 \            "Beware of bugs in the above code; I have only proved it |
  `\               correct, not tried it." -- Donald Knuth, 1977-03-29 |
_o__)                                                                  |
Ben Finney


From zooko at zooko.com  Sat Jun 14 03:15:59 2008
From: zooko at zooko.com (zooko)
Date: Fri, 13 Jun 2008 18:15:59 -0700
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <87tzfwdep9.fsf@benfinney.id.au>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
Message-ID: <6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>


On Jun 13, 2008, at 5:48 PM, Ben Finney wrote:

> zooko <zooko at zooko.com> writes:
>
>> While your reasons are good ones, Armin, it is too late to rename
>> easy_install.
>
> I don't see why. Care to give some reasons of your own?

I said it was "too late", because there are already lots of people  
worldwide who know the name "easy_install".  It would be costly to  
them to change it -- they'll go looking for the new version of  
easy_install someday and won't find it, stuff like that.

On the other hand, if there is a strong desire on the parts of  
developers to change it, I won't object.

Regards,

Zooko


From asmodai at in-nomine.org  Sat Jun 14 08:46:02 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Sat, 14 Jun 2008 08:46:02 +0200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
Message-ID: <20080614064602.GK71640@nexus.in-nomine.org>

-On [20080614 03:18], zooko (zooko at zooko.com) wrote:
>I said it was "too late", because there are already lots of people  
>worldwide who know the name "easy_install".  It would be costly to  
>them to change it -- they'll go looking for the new version of  
>easy_install someday and won't find it, stuff like that.

Nothing proper release notes and the likes cannot fix. Heck, you could
provide a symlink from easy_install to the new pyegg --or whatever the name
might be-- for a few releases and if it is easy_install that's being
invoked, you act accordingly. Or even a placeholder script invoking the
necessary things.

Also, your claim of 'lots of people worldwide' is taken out of thin air. I
doubt you have evidence in favour or against.

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Nothing is constant but change...

From lists at zopyx.com  Sat Jun 14 08:55:27 2008
From: lists at zopyx.com (Andreas Jung)
Date: Sat, 14 Jun 2008 08:55:27 +0200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080614064602.GK71640@nexus.in-nomine.org>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
Message-ID: <AACD14183C404A2968C48C4D@suxmac.local>



--On 14. Juni 2008 08:46:02 +0200 Jeroen Ruigrok van der Werven 
<asmodai at in-nomine.org> wrote:

> -On [20080614 03:18], zooko (zooko at zooko.com) wrote:
>> I said it was "too late", because there are already lots of people
>> worldwide who know the name "easy_install".  It would be costly to
>> them to change it -- they'll go looking for the new version of
>> easy_install someday and won't find it, stuff like that.
>

-100 on renaming easy_install to something else.

> Also, your claim of 'lots of people worldwide' is taken out of thin air. I
> doubt you have evidence in favour or against.

Honestly spoken: the world has other problems than such a pointless issue.

I introduced eggs, setuptools and zc.buildout within a bigger organization 
with several courses and hands-on-training. 'easy_install' is a well-known 
term right now and there is basically no need for renaming it - just for 
the sake of renaming it to something like 'pyegg' which is as pointless and 
generic as 'easy_install'. Leave things as they are - don't confuse people 
by renaming things - it's not worth the effort.

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

From tseaver at palladion.com  Sat Jun 14 20:17:28 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 14 Jun 2008 14:17:28 -0400
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080614064602.GK71640@nexus.in-nomine.org>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>	<87tzfwdep9.fsf@benfinney.id.au>	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
Message-ID: <48540B38.8030205@palladion.com>

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

Jeroen Ruigrok van der Werven wrote:
> -On [20080614 03:18], zooko (zooko at zooko.com) wrote:
>> I said it was "too late", because there are already lots of people  
>> worldwide who know the name "easy_install".  It would be costly to  
>> them to change it -- they'll go looking for the new version of  
>> easy_install someday and won't find it, stuff like that.
> 
> Nothing proper release notes and the likes cannot fix. Heck, you could
> provide a symlink from easy_install to the new pyegg --or whatever the name
> might be-- for a few releases and if it is easy_install that's being
> invoked, you act accordingly. Or even a placeholder script invoking the
> necessary things.
> 
> Also, your claim of 'lots of people worldwide' is taken out of thin air. I
> doubt you have evidence in favour or against.

I'm quite confident that there are hundreds-to-thousands of users to
date, plus lots of third-party docs which describe using 'easy_install'
to get packages or applications installed.

- -1 to the rename.  I don't think 'easy_install' is ever a candidate for
/usr/bin on a system under package management, given that it breaks the
expectations of packagers that they control the horizontal and vertical
for software installation.


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

iD8DBQFIVAs4+gerLs4ltQ4RAruSAJwNK3cH5dIBKn16pqxaTS6bhi/ndQCeIX0z
NsqE/VyaWLFYom+eAMUGUNU=
=WTG7
-----END PGP SIGNATURE-----


From greg.ewing at canterbury.ac.nz  Sun Jun 15 01:51:30 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 15 Jun 2008 11:51:30 +1200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080614064602.GK71640@nexus.in-nomine.org>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
Message-ID: <48545982.4000406@canterbury.ac.nz>

Jeroen Ruigrok van der Werven wrote:
> -On [20080614 03:18], zooko (zooko at zooko.com) wrote:
> 
>>I said it was "too late", because there are already lots of people  
>>worldwide who know the name "easy_install".
> 
> Nothing proper release notes and the likes cannot fix.

My objection to the name "easy_install" is that is sounds
like a piece of marketing propaganda. If something based
on it were to become part of the standard distribution,
I would hope that a more neutral name could be found.

-- 
Greg

From bignose+hates-spam at benfinney.id.au  Sun Jun 15 04:16:30 2008
From: bignose+hates-spam at benfinney.id.au (Ben Finney)
Date: Sun, 15 Jun 2008 12:16:30 +1000
Subject: [Distutils] [issue24] Rename easy_install
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
Message-ID: <87prqjcuip.fsf@benfinney.id.au>

Greg Ewing <greg.ewing at canterbury.ac.nz> writes:

> My objection to the name "easy_install" is that is sounds like a
> piece of marketing propaganda. If something based on it were to
> become part of the standard distribution, I would hope that a more
> neutral name could be found.

I share this objection.

Also, the name 'easy_install' gives no indication that it's specific
to Python. Such a generic name shouldn't be chosen for such a specific
subsystem.

Further, when other, non-install actions are introduced (such as the
much-requested "uninstall" action), we should already have a name that
will allow those actions to fit. I would hate to see the existing
situation compounded by the introduction of some 'easy_uninstall'
command.

The suggestion of 'pyegg' for the command name seems like a good
start, but there are doubtless others that should be considered.

-- 
 \       "I went to a general store. They wouldn't let me buy anything |
  `\                                  specifically."  -- Steven Wright |
_o__)                                                                  |
Ben Finney


From pje at telecommunity.com  Sun Jun 15 05:26:06 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 14 Jun 2008 23:26:06 -0400
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <48545982.4000406@canterbury.ac.nz>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
Message-ID: <20080615032612.926A33A405F@sparrow.telecommunity.com>

At 11:51 AM 6/15/2008 +1200, Greg Ewing wrote:
>My objection to the name "easy_install" is that is sounds
>like a piece of marketing propaganda.

What do you mean, "sounds like"?  It *is* marketing propaganda.  And 
it worked very well, I might add.  ;-)

(On a side note, I find it tremendously amusing that this particular 
bike shed seems to be attracting the *most* attention, out of all the 
things that need to be fixed, improved, or replaced altogether.)


From bignose+hates-spam at benfinney.id.au  Sun Jun 15 06:21:29 2008
From: bignose+hates-spam at benfinney.id.au (Ben Finney)
Date: Sun, 15 Jun 2008 14:21:29 +1000
Subject: [Distutils] [issue24] Rename easy_install
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
Message-ID: <87k5grcoqe.fsf@benfinney.id.au>

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

> (On a side note, I find it tremendously amusing that this particular
> bike shed seems to be attracting the *most* attention, out of all
> the things that need to be fixed, improved, or replaced altogether.)

It's partly the bike-shed effect, true.

On the other hand, it's been a wart for a long time, so this period of
"fix things for the future" has inevitably brought this issue up. If
it's going to be addressed properly, now seems like the best time.

-- 
 \       ?As the most participatory form of mass speech yet developed, |
  `\    the Internet deserves the highest protection from governmental |
_o__)                   intrusion.? ?U.S. District Court Judge Dalzell |
Ben Finney


From zooko at zooko.com  Sun Jun 15 10:58:12 2008
From: zooko at zooko.com (zooko)
Date: Sun, 15 Jun 2008 01:58:12 -0700
Subject: [Distutils] how many users of easy_install or setuptools are there?
In-Reply-To: <20080614064602.GK71640@nexus.in-nomine.org>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
Message-ID: <535DDCD3-9060-4739-B028-743CC98F1F9D@zooko.com>

On Jun 13, 2008, at 11:46 PM, Jeroen Ruigrok van der Werven wrote:

 > Also, your claim of 'lots of people worldwide' is taken out of thin
 > air. I doubt you have evidence in favour or against.


Due to the "Shall we rename easy_install?" question, I became curious
about evidence of number of users.

Obviously we can't get reliable numbers of how many users there are,
since people can (and do) freely copy the software and use it without
sending any hint of their use to us.

However, here are a few numbers that might be indicative:

Google for "easy_install" has 141,000 hits.

http://pypi.python.org/pypi/setuptools/0.6c8 shows the following
numbers of downloads:

File                              Type          PyVer   downloads
----                              ----          -----   ---------
setuptools-0.6c8-py2.5.egg        Python Egg    2.5     66,197
setuptools-0.6c8.win32-py2.4.exe  W32 installer 2.4        991
setuptools-0.6c8.win32-py2.5.exe  W32 installer 2.5      5,007
setuptools-0.6c8.win32-py2.3.exe  W32 installer 2.3        207
setuptools-0.6c8-1.src.rpm        RPM redhat4.3 any        752
setuptools-0.6c8-py2.4.egg        Python Egg    2.4     68,237
setuptools-0.6c8-py2.3.egg        Python Egg    2.3      6,684
setuptools-0.6c8.tar.gz           Source        any     12,647


Next, I wonder about how many people got setuptools or easy_install
with their operating system instead of downloading it.  Unfortunately,
Debian's popularity-contest seems to be broken, so I can't use that to
try to get an estimate of how many Debian users use the setuptools as
distributed by Debian.

http://popcon.debian.org


Regards,

Zooko


From zooko at zooko.com  Sun Jun 15 11:15:29 2008
From: zooko at zooko.com (zooko)
Date: Sun, 15 Jun 2008 02:15:29 -0700
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <87prqjcuip.fsf@benfinney.id.au>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<87prqjcuip.fsf@benfinney.id.au>
Message-ID: <D305D057-2298-412E-AF12-420A57635645@zooko.com>

On Jun 14, 2008, at 7:16 PM, Ben Finney wrote:

> Greg Ewing <greg.ewing at canterbury.ac.nz> writes:
>
>> My objection to the name "easy_install" is that is sounds like a
>> piece of marketing propaganda. If something based on it were to
>> become part of the standard distribution, I would hope that a more
>> neutral name could be found.
>
> I share this objection.

Now that you mention it, I have heard more than one person snort  
derisively about the name "easy_install", and say something to the  
effect that it isn't a proper name.  This makes me think that it  
causes the "anti-marketing-propaganda" reaction in some folks.

Considering the opinions expressed by others in this thread, I'm  
changing my mind and would not object to changing the name.

Regards,

Zooko

From pje at telecommunity.com  Sun Jun 15 15:35:16 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 15 Jun 2008 09:35:16 -0400
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <D305D057-2298-412E-AF12-420A57635645@zooko.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<87prqjcuip.fsf@benfinney.id.au>
	<D305D057-2298-412E-AF12-420A57635645@zooko.com>
Message-ID: <20080615133522.6054A3A402D@sparrow.telecommunity.com>

At 02:15 AM 6/15/2008 -0700, zooko wrote:
>Now that you mention it, I have heard more than one person snort
>derisively about the name "easy_install", and say something to the
>effect that it isn't a proper name.  This makes me think that it
>causes the "anti-marketing-propaganda" reaction in some folks.

You seem to be under the mistaken impression that my choice of name 
was accidental or whimsical, rather than carefully chosen to appeal 
to some people at the possible expense of others.

And you can't actually avoid that tradeoff, any more than you can 
shove a program's complexity under the rug.  All you can do is 
attempt to please a different group, or to please no-one.  You don't 
get the option of pleasing everybody.


From fuzzyman at voidspace.org.uk  Sun Jun 15 15:40:25 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 15 Jun 2008 14:40:25 +0100
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080615133522.6054A3A402D@sparrow.telecommunity.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>	<87tzfwdep9.fsf@benfinney.id.au>	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>	<20080614064602.GK71640@nexus.in-nomine.org>	<48545982.4000406@canterbury.ac.nz>	<87prqjcuip.fsf@benfinney.id.au>	<D305D057-2298-412E-AF12-420A57635645@zooko.com>
	<20080615133522.6054A3A402D@sparrow.telecommunity.com>
Message-ID: <48551BC9.10900@voidspace.org.uk>

Phillip J. Eby wrote:
> At 02:15 AM 6/15/2008 -0700, zooko wrote:
>> Now that you mention it, I have heard more than one person snort
>> derisively about the name "easy_install", and say something to the
>> effect that it isn't a proper name.  This makes me think that it
>> causes the "anti-marketing-propaganda" reaction in some folks.
>
> You seem to be under the mistaken impression that my choice of name 
> was accidental or whimsical, rather than carefully chosen to appeal to 
> some people at the possible expense of others.
>
> And you can't actually avoid that tradeoff, any more than you can 
> shove a program's complexity under the rug.  All you can do is attempt 
> to please a different group, or to please no-one.  You don't get the 
> option of pleasing everybody.

Personally I think 'easy_install' is well named and not heard of anyone 
who misunderstood its intent or purpose...

Michael Foord

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


-- 
http://www.ironpythoninaction.com/
http://www.theotherdelia.co.uk/
http://www.voidspace.org.uk/
http://www.ironpython.info/
http://www.resolverhacks.net/


From greg.ewing at canterbury.ac.nz  Mon Jun 16 02:57:04 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 16 Jun 2008 12:57:04 +1200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080615032612.926A33A405F@sparrow.telecommunity.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
Message-ID: <4855BA60.2070003@canterbury.ac.nz>

Phillip J. Eby wrote:

> What do you mean, "sounds like"?  It *is* marketing propaganda.  And it 
> worked very well, I might add.  ;-)

Maybe on some people, but I tend to get turned off
by that sort of thing.

In any case, if it gets into the core, then the
marketing aspect will have done its job and will no
longer be necessary.

> (On a side note, I find it tremendously amusing that this particular 
> bike shed seems to be attracting the *most* attention, out of all the 
> things that need to be fixed, improved, or replaced altogether.)

Any discussion of that sort seems to get hopelessly
bogged down, so bikeshedding is all that's left for
people to do.

-- 
Greg

From stefan at tjarks.de  Mon Jun 16 06:59:28 2008
From: stefan at tjarks.de (stefan tjarks)
Date: Mon, 16 Jun 2008 16:59:28 +1200
Subject: [Distutils] [buildout] import develop eggs
Message-ID: <g34rvh$md6$1@ger.gmane.org>

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

I'm not sure where to post this, so if it's the wrong list please point
me to the right one.

I started using zc.buildout with django and are using djangorecipe[1].
After running buildout and trying to start django it fails trying to
import my development module. Here is what I did in more detail.

My folder structure:

root/
  bootstrap.py
  buildout.cfg
  src/
    myapp/
      setup.py
      src/
        ...

The buildout.cfg:

  [buildout]
  parts = django
  eggs = psycopg2
  develop = src/myapp

  [django]
  recipe = djangorecipe
  version = trunk
  django_location = ${buildout:directory}/django_src
  settings = development
  eggs = ${buildout:eggs}
  project = instance

Running bootstrap.py and bin/buildout works fine and gives me a
develop-eggs directory with an .egg-link file as well as a bin/django file.

After inserting 'myapp' into djangos settings file I tried to start
django with 'bin/django runserver' and it failed with

  ImportError: No module named myapp

The bin/django file is basically a wrapper, that sets the python path to
all eggs and the project root directory.

  #!/home/dev/python2.5/bin/python

  import sys
  sys.path[0:0] = [
  '/home/dev/eggs/psycopg2-2.0.7-py2.5-linux-ppc.egg',
  '/home/dev/eggs/djangorecipe-0.8-py2.5.egg',
  '/home/dev/eggs/zc.recipe.egg-1.0.0-py2.5.egg',
  '/home/dev/eggs/zc.buildout-1.0.6-py2.5.egg',
  '/home/dev/eggs/setuptools-0.6c8-py2.5.egg',
  '/home/dev/parts/django',
  '/home/dev',
  ]

  import djangorecipe.manage

  if __name__ == '__main__':
      djangorecipe.manage.main('instance.development')

I don't see what I have missed. I do see that the develop-eggs directory
is nowhere mentioned in the generated files, but thought that setuptools
would take care of that and made the dev eggs importable.

Regards
- -stj

[1] https://launchpad.net/djangorecipe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIVfMvwRdcaudH4ncRAvULAJsEzXnSpcX2MkelhQ/o+WRAGAAd/gCgmJ7e
/r3qUz9V5VbYIhkK4jJM4K4=
=wtjq
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Mon Jun 16 07:44:44 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 16 Jun 2008 01:44:44 -0400
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <4855BA60.2070003@canterbury.ac.nz>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
	<4855BA60.2070003@canterbury.ac.nz>
Message-ID: <20080616054416.646E33A40C2@sparrow.telecommunity.com>

At 12:57 PM 6/16/2008 +1200, Greg Ewing wrote:
>Any discussion of that sort seems to get hopelessly
>bogged down, so bikeshedding is all that's left for
>people to do.

What about testing patches?  Writing test code?  Writing more 
docs?  There's *plenty* of less controversial work to go around.  The 
only reason most of the outstanding patches I'm aware of haven't been 
applied yet is because they haven't been tested.  (Or more precisely, 
because setuptools hasn't been thoroughly tested with the patches applied.)


From mustapha at headnet.dk  Mon Jun 16 08:44:11 2008
From: mustapha at headnet.dk (mustapha)
Date: Mon, 16 Jun 2008 08:44:11 +0200
Subject: [Distutils] [buildout] import develop eggs
In-Reply-To: <g34rvh$md6$1@ger.gmane.org>
References: <g34rvh$md6$1@ger.gmane.org>
Message-ID: <48560BBB.6010302@headnet.dk>

You have to say to buildout that you want to use myapp in the django 
part. Add myapp to the eggs of the [django] part or add it to the 
buildout's eggs option because you are including ${buildout:eggs} in the 
[django]'s eggs. So do:

[buidlout]
eggs =
     psycopg2
     myapp

develop = src/myapp

or:

[django]
eggs =
     ${buildout:eggs}
     myapp



stefan tjarks wrote:
> I'm not sure where to post this, so if it's the wrong list please point
> me to the right one.
> 
> I started using zc.buildout with django and are using djangorecipe[1].
> After running buildout and trying to start django it fails trying to
> import my development module. Here is what I did in more detail.
> 
> My folder structure:
> 
> root/
>   bootstrap.py
>   buildout.cfg
>   src/
>     myapp/
>       setup.py
>       src/
>         ...
> 
> The buildout.cfg:
> 
>   [buildout]
>   parts = django
>   eggs = psycopg2
>   develop = src/myapp
> 
>   [django]
>   recipe = djangorecipe
>   version = trunk
>   django_location = ${buildout:directory}/django_src
>   settings = development
>   eggs = ${buildout:eggs}
>   project = instance
> 
> Running bootstrap.py and bin/buildout works fine and gives me a
> develop-eggs directory with an .egg-link file as well as a bin/django file.
> 
> After inserting 'myapp' into djangos settings file I tried to start
> django with 'bin/django runserver' and it failed with
> 
>   ImportError: No module named myapp
> 
> The bin/django file is basically a wrapper, that sets the python path to
> all eggs and the project root directory.
> 
>   #!/home/dev/python2.5/bin/python
> 
>   import sys
>   sys.path[0:0] = [
>   '/home/dev/eggs/psycopg2-2.0.7-py2.5-linux-ppc.egg',
>   '/home/dev/eggs/djangorecipe-0.8-py2.5.egg',
>   '/home/dev/eggs/zc.recipe.egg-1.0.0-py2.5.egg',
>   '/home/dev/eggs/zc.buildout-1.0.6-py2.5.egg',
>   '/home/dev/eggs/setuptools-0.6c8-py2.5.egg',
>   '/home/dev/parts/django',
>   '/home/dev',
>   ]
> 
>   import djangorecipe.manage
> 
>   if __name__ == '__main__':
>       djangorecipe.manage.main('instance.development')
> 
> I don't see what I have missed. I do see that the develop-eggs directory
> is nowhere mentioned in the generated files, but thought that setuptools
> would take care of that and made the dev eggs importable.
> 
> Regards
> -stj
> 
> [1] https://launchpad.net/djangorecipe

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



From mustapha at headnet.dk  Mon Jun 16 08:44:11 2008
From: mustapha at headnet.dk (mustapha)
Date: Mon, 16 Jun 2008 08:44:11 +0200
Subject: [Distutils] [buildout] import develop eggs
In-Reply-To: <g34rvh$md6$1@ger.gmane.org>
References: <g34rvh$md6$1@ger.gmane.org>
Message-ID: <48560BBB.6010302@headnet.dk>

You have to say to buildout that you want to use myapp in the django 
part. Add myapp to the eggs of the [django] part or add it to the 
buildout's eggs option because you are including ${buildout:eggs} in the 
[django]'s eggs. So do:

[buidlout]
eggs =
     psycopg2
     myapp

develop = src/myapp

or:

[django]
eggs =
     ${buildout:eggs}
     myapp



stefan tjarks wrote:
> I'm not sure where to post this, so if it's the wrong list please point
> me to the right one.
> 
> I started using zc.buildout with django and are using djangorecipe[1].
> After running buildout and trying to start django it fails trying to
> import my development module. Here is what I did in more detail.
> 
> My folder structure:
> 
> root/
>   bootstrap.py
>   buildout.cfg
>   src/
>     myapp/
>       setup.py
>       src/
>         ...
> 
> The buildout.cfg:
> 
>   [buildout]
>   parts = django
>   eggs = psycopg2
>   develop = src/myapp
> 
>   [django]
>   recipe = djangorecipe
>   version = trunk
>   django_location = ${buildout:directory}/django_src
>   settings = development
>   eggs = ${buildout:eggs}
>   project = instance
> 
> Running bootstrap.py and bin/buildout works fine and gives me a
> develop-eggs directory with an .egg-link file as well as a bin/django file.
> 
> After inserting 'myapp' into djangos settings file I tried to start
> django with 'bin/django runserver' and it failed with
> 
>   ImportError: No module named myapp
> 
> The bin/django file is basically a wrapper, that sets the python path to
> all eggs and the project root directory.
> 
>   #!/home/dev/python2.5/bin/python
> 
>   import sys
>   sys.path[0:0] = [
>   '/home/dev/eggs/psycopg2-2.0.7-py2.5-linux-ppc.egg',
>   '/home/dev/eggs/djangorecipe-0.8-py2.5.egg',
>   '/home/dev/eggs/zc.recipe.egg-1.0.0-py2.5.egg',
>   '/home/dev/eggs/zc.buildout-1.0.6-py2.5.egg',
>   '/home/dev/eggs/setuptools-0.6c8-py2.5.egg',
>   '/home/dev/parts/django',
>   '/home/dev',
>   ]
> 
>   import djangorecipe.manage
> 
>   if __name__ == '__main__':
>       djangorecipe.manage.main('instance.development')
> 
> I don't see what I have missed. I do see that the develop-eggs directory
> is nowhere mentioned in the generated files, but thought that setuptools
> would take care of that and made the dev eggs importable.
> 
> Regards
> -stj
> 
> [1] https://launchpad.net/djangorecipe

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



From stefan at tjarks.de  Mon Jun 16 10:35:59 2008
From: stefan at tjarks.de (stefan tjarks)
Date: Mon, 16 Jun 2008 20:35:59 +1200
Subject: [Distutils] [buildout] import develop eggs
In-Reply-To: <48560BBB.6010302@headnet.dk>
References: <g34rvh$md6$1@ger.gmane.org> <48560BBB.6010302@headnet.dk>
Message-ID: <g358lf$mcj$1@ger.gmane.org>

mustapha wrote:
> You have to say to buildout that you want to use myapp in the django
> part. Add myapp to the eggs of the [django] part or add it to the
> buildout's eggs option because you are including ${buildout:eggs} in the
> [django]'s eggs. So do:
> 
> [buidlout]
> eggs =
>     psycopg2
>     myapp
> 
> develop = src/myapp
> 
> or:
> 
> [django]
> eggs =
>     ${buildout:eggs}
>     myapp

Thanks mustapha that solved the problem.

-stj


From david at ar.media.kyoto-u.ac.jp  Mon Jun 16 17:33:09 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 00:33:09 +0900
Subject: [Distutils] What is needed by an uninstall command to be useful ?
Message-ID: <485687B5.2090702@ar.media.kyoto-u.ac.jp>

Hi,

    An uninstall command is a long-time wanted feature of distutils. I 
was wondering why it was not implemented: what does it need to do to be 
useful ? AFAIK, make uninstall in autotools simply removes currently 
installed files, with currently refering to the current configured value 
of prefix and all. Isn't this enough  (I am interested in a 'pure' 
distutils command, not a setuptools one) ? What would be the minimum 
semantics needed for an uninstall command ?

    cheers,

    David

From ivazqueznet at gmail.com  Mon Jun 16 18:31:00 2008
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Mon, 16 Jun 2008 12:31:00 -0400
Subject: [Distutils] What is needed by an uninstall command to be	useful
	?
In-Reply-To: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
Message-ID: <1213633860.10118.84.camel@ignacio.lan>

On Tue, 2008-06-17 at 00:33 +0900, David Cournapeau wrote:
>     An uninstall command is a long-time wanted feature of distutils. I 
> was wondering why it was not implemented: what does it need to do to be 
> useful ? AFAIK, make uninstall in autotools simply removes currently 
> installed files, with currently refering to the current configured value 
> of prefix and all. Isn't this enough  (I am interested in a 'pure' 
> distutils command, not a setuptools one) ? What would be the minimum 
> semantics needed for an uninstall command ?

One of the big differences between autotools and distutils is that in
autotools the destination path is set at *build* time (ignoring the
not-often directly-used DESTDIR make variable, of course), but in
distutils/setuptools the destination path is set at *install* time. IMO
this makes an uninstall option slightly less useful, since installing in
an alternate root isn't really as rare as overriding the path chosen by
autotools.

Having said that, yes, it could potentially be done so that it takes the
same argument as install for overriding the root, but I get the distinct
feeling that people are going to forget to specify the root on uninstall
quite often, thereby removing the module installed in the system
location instead.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

PLEASE don't CC me; I'm already subscribed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080616/e4ea4a5d/attachment.pgp>

From cdcasey at gmail.com  Mon Jun 16 19:28:23 2008
From: cdcasey at gmail.com (chris)
Date: Mon, 16 Jun 2008 12:28:23 -0500
Subject: [Distutils] What is needed by an uninstall command to be useful
	?
In-Reply-To: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
Message-ID: <ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>

On Mon, Jun 16, 2008 at 10:33 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Hi,
>
>   An uninstall command is a long-time wanted feature of distutils. I was
> wondering why it was not implemented: what does it need to do to be useful ?

I've submitted a patch for an uninstall feature here:

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

Currently it works by creating an installed_files.log file in an egg
on install. This file is used during uninstall (-r option) to remove
all files associated with an egg. If an egg was installed before this
patch was applied, the only things missed will be external scripts.

It will also do some dependency checking. If the package being removed
is depended upon by something else, it will warn the user (showing
what needs that package). If the package being removed has a
dependency not needed by anything else, it presents the user with the
option of removing that dependency as well. Also, entries from
easy_install.pth are removed.

If have the time and inclination, try it out and let me know what you think. :)

-Chris

From ianb at colorstudy.com  Mon Jun 16 22:29:04 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 16 Jun 2008 15:29:04 -0500
Subject: [Distutils] There should be a no-index on simple pypi index
Message-ID: <4856CD10.7050805@colorstudy.com>

I just did a search for "pyaudio" and this link:

   http://pypi.python.org/simple/PyAudio/

showed up above this link:

   http://pypi.python.org/pypi/PyAudio/0.2.0

If <meta name="robots" content="noindex"> was added to the simple pages 
that would help.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From dpeterson at enthought.com  Tue Jun 17 01:27:33 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Mon, 16 Jun 2008 18:27:33 -0500
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080616054416.646E33A40C2@sparrow.telecommunity.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>	<87tzfwdep9.fsf@benfinney.id.au>	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>	<20080614064602.GK71640@nexus.in-nomine.org>	<48545982.4000406@canterbury.ac.nz>	<20080615032612.926A33A405F@sparrow.telecommunity.com>	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
Message-ID: <4856F6E5.8040406@enthought.com>

Phillip J. Eby wrote:
> At 12:57 PM 6/16/2008 +1200, Greg Ewing wrote:
>> Any discussion of that sort seems to get hopelessly
>> bogged down, so bikeshedding is all that's left for
>> people to do.
>
> What about testing patches?  Writing test code?  Writing more docs?  
> There's *plenty* of less controversial work to go around.  The only 
> reason most of the outstanding patches I'm aware of haven't been 
> applied yet is because they haven't been tested.  (Or more precisely, 
> because setuptools hasn't been thoroughly tested with the patches 
> applied.)


I can help test some of the patches I've seen people posting to the 
tracker, but I can't commit to svn.   Beyond running the setuptools test 
suite and verifying that things seems to work for me and my environment, 
is there anything else that will help get some of the patches into svn?

BTW, most of those things you mention all effectively boil down to 
writing patches in one way or another. :-)  How do we make sure that 
after they get some review they get checked in when it seems so few 
people have check-in privileges?  Phillip, you already mentioned that 
you're short on time and no one else has responded to a plea for finding 
out who has check-in privileges.  IIRC, you had previously talked about 
coming up with a process to "bless" people but I don't think that went 
very far.   I'm interested in participating but unsure of how to go 
about the process.


-- Dave


From pje at telecommunity.com  Tue Jun 17 02:37:18 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 16 Jun 2008 20:37:18 -0400
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <4856F6E5.8040406@enthought.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
Message-ID: <20080617003916.735693A40A2@sparrow.telecommunity.com>

At 06:27 PM 6/16/2008 -0500, Dave Peterson wrote:
>Phillip J. Eby wrote:
>>At 12:57 PM 6/16/2008 +1200, Greg Ewing wrote:
>>>Any discussion of that sort seems to get hopelessly
>>>bogged down, so bikeshedding is all that's left for
>>>people to do.
>>
>>What about testing patches?  Writing test code?  Writing more docs?
>>There's *plenty* of less controversial work to go around.  The only 
>>reason most of the outstanding patches I'm aware of haven't been 
>>applied yet is because they haven't been tested.  (Or more 
>>precisely, because setuptools hasn't been thoroughly tested with 
>>the patches applied.)
>
>
>I can help test some of the patches

Don't test patches - test setuptools with the patches.  :)  More 
precisely, make sure you test things beyond what the patch is 
supposed to do, to make sure that other things aren't affected.  This 
is particularly important for patches to easy_install, which is 
ridiculously complicated
due to all the obscure edge cases it has to be able to handle.


>  I've seen people posting to the tracker, but I can't commit to 
> svn.   Beyond running the setuptools test suite

The test suite is pretty useless for most of these kinds of 
patches.  It essentially only exercises various internals of 
pkg_resources and a few other things that are almost never 
touched.  I'm talking testing as in "actually install some packages 
in a few different kinds of install targets, using a few different 
options".  I don't have a rigorous process for that, as I tend to 
pick things on the basis of the code paths to be exercised.  But that 
might not be an option for casual testers.

If I had it all to do over -- and I didn't simply run screaming from 
attempting the task in the first place -- I would write a full 
functional test suite, including chrooting tests if necessary.  In 
the long run, it would have saved enormous amounts of manual test 
time, and we could have had more people involved in development a 
long time ago.

That, by the way, is why "writing test code" is on the list above.


>and verifying that things seems to work for me and my environment, 
>is there anything else that will help get some of the patches into svn?
>
>BTW, most of those things you mention all effectively boil down to 
>writing patches in one way or another. :-)  How do we make sure that 
>after they get some review they get checked in when it seems so few 
>people have check-in privileges?  Phillip, you already mentioned 
>that you're short on time and no one else has responded to a plea 
>for finding out who has check-in privileges.

Jim Fulton has previously been "blessed" by me to apply 
non-controversial patches to setuptools after giving me a 
heads-up.  (But note that he's probably busier than I am, and 
unlikely to have bandwidth for stuff that doesn't affect zc.buildout 
or Zope in some way.)

If you want to expand the available development pool for setuptools, 
I would strongly suggest focusing development efforts on creating a 
regression test suite emphasizing end-to-end functional testing of 
the current functionality.  Such tests would ideally be factored for 
narrative clarity and compact expressiveness, rather like Jim 
Fulton's doctests for easy_install's .exe wrappers, and the doctests 
for zc.buildout.  (Because if they're too complicated for me to read, 
they'll take too long for me to review.)

If people *really* want to solve the development bottleneck, this is 
the way to go, because it will reduce my role to deciding whether 
something should go in, and seeing if it passes the tests on a 
platform or two.  That's something I think I could manage to do, even 
with my current work load.


From phil_schwartz at users.sourceforge.net  Tue Jun 17 04:45:15 2008
From: phil_schwartz at users.sourceforge.net (Phil Schwartz)
Date: Mon, 16 Jun 2008 19:45:15 -0700
Subject: [Distutils] Creating rpm's for multiple python versions?
Message-ID: <E1K8RC7-0001QC-Kz@pr-shellE.sourceforge.net>

From: phil_schwartz at users.sourceforge.net

Thanks for the reference Ignacio, however, I'm not sure how this applies to packaging the rpm in 
my current build environment.

[Quote]

If you are installing anything into the global site_packages directory, use the following trick.
First, define python_sitelib at the top of your specfile:

%{!?python_sitelib: %define python_sitelib %(%{__python} -c \
"from distutils.sysconfig import get_python_lib; print get_python_lib()")}

[End Quote]

since I don't have a spec file (distutils may create one as necessary and delete it).  

Running the following command returns the expected result:

$ python2.3 -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"
/usr/lib/python2.3/site-packages

But not sure how to include this in distutils (setup.py, setup.cfg, MANIFEST.in, etc).

Certainly, someone else be packaging their python apps for multiple python versions.  

Thanks for any addition leads,

Phil




Ignacio Vazquez-Abrams wrote:

You may want to consider reading Fedora's Python packaging
guidelines[1].

[1] http://fedoraproject.org/wiki/Packaging/Python


On Fri, 2008-06-13 at 14:36 -0700, Phil Schwartz wrote:
> > I have a Fedora Core 7 development server that has python2.3,
> > python2.4 and python2.5 installed.  I'd like to build rpm's of my
> > application for each
> > of these versions of python.

> > How can I force the rpm's to include the proper site-packages path
> > (for python2.3 that would be "/usr/lib/python2.3/site-packages/")?


-- Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> 

From david at ar.media.kyoto-u.ac.jp  Tue Jun 17 07:01:39 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 14:01:39 +0900
Subject: [Distutils] What is needed by an uninstall command to be	useful
 ?
In-Reply-To: <1213633860.10118.84.camel@ignacio.lan>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<1213633860.10118.84.camel@ignacio.lan>
Message-ID: <48574533.3000208@ar.media.kyoto-u.ac.jp>

Ignacio Vazquez-Abrams wrote:
> On Tue, 2008-06-17 at 00:33 +0900, David Cournapeau wrote:
>>     An uninstall command is a long-time wanted feature of distutils. I 
>> was wondering why it was not implemented: what does it need to do to be 
>> useful ? AFAIK, make uninstall in autotools simply removes currently 
>> installed files, with currently refering to the current configured value 
>> of prefix and all. Isn't this enough  (I am interested in a 'pure' 
>> distutils command, not a setuptools one) ? What would be the minimum 
>> semantics needed for an uninstall command ?
>
> One of the big differences between autotools and distutils is that in
> autotools the destination path is set at *build* time (ignoring the
> not-often directly-used DESTDIR make variable, of course), but in
> distutils/setuptools the destination path is set at *install* time.

Yes, that's actually one of the thing I really don't like about 
distutils (the way options are handled), but there is nothing we can do 
about that in the short term.

I think it would be possible to record the last install directories into 
the build directory of distutils, such as by default, it will remove the 
last installed package ? There is no question that an uninstall command 
will not be good for all cases; but here are some of the scenario I am 
thinking about:
    - install run uninstall before install (if uninstall info found in 
build): avoiding people having problems when re-installing a package 
without removing it first (that's my first priority, actually, but I am 
willing to handle other cases, of course)
    - uninstall a package a user does not want anymore.

>
>
> Having said that, yes, it could potentially be done so that it takes the
> same argument as install for overriding the root, but I get the distinct
> feeling that people are going to forget to specify the root on uninstall
> quite often, thereby removing the module installed in the system
> location instead.

Well, there is not much you can do about that. On unix, people do not 
install in system location, I hope. On windows, most people install in 
the default location, no ? The ones who don't should be able to pass the 
uninstall command, normally.

If we have a reliable mechanism to remove the last installed package, I 
think we would mostly alleviate this problem (which concern people who 
do not tweak much; for people who want to install in non default 
location, I would expect them to handle this issue by themselves ?)

cheers,

David

From david at ar.media.kyoto-u.ac.jp  Tue Jun 17 07:46:33 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 14:46:33 +0900
Subject: [Distutils] What is needed by an uninstall command to be useful
 ?
In-Reply-To: <ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
Message-ID: <48574FB9.2070409@ar.media.kyoto-u.ac.jp>

chris wrote:
>
> I've submitted a patch for an uninstall feature here:
>
> http://bugs.python.org/setuptools/issue21
>

Hi Chris,

    Yes, I saw it. Unfortunately, it is a setuptools extension, and I 
don't want to use setuptools. I also want something which may be 
integrated by distutils at some point.

> Currently it works by creating an installed_files.log file in an egg
> on install. This file is used during uninstall (-r option) to remove
> all files associated with an egg. If an egg was installed before this
> patch was applied, the only things missed will be external scripts.
>
> It will also do some dependency checking. If the package being removed
> is depended upon by something else, it will warn the user (showing
> what needs that package). If the package being removed has a
> dependency not needed by anything else, it presents the user with the
> option of removing that dependency as well. Also, entries from
> easy_install.pth are removed.

Do you think it would be possible to refactor it to split the 
distutils/setuptools parts ? I could do it myself, obviously, but I 
don't know anything about setuptools internals.

cheers,

David

From bignose+hates-spam at benfinney.id.au  Tue Jun 17 11:38:21 2008
From: bignose+hates-spam at benfinney.id.au (Ben Finney)
Date: Tue, 17 Jun 2008 19:38:21 +1000
Subject: [Distutils] What is needed by an uninstall command to be	useful
	?
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<1213633860.10118.84.camel@ignacio.lan>
	<48574533.3000208@ar.media.kyoto-u.ac.jp>
Message-ID: <873ance702.fsf@benfinney.id.au>

David Cournapeau <david at ar.media.kyoto-u.ac.jp> writes:

> On unix, people do not install in system location, I hope.

I don't understand what you mean here. How do packages get into the
system location if they're not installed there at some time? What,
specifically, do you hope people don't do?

-- 
 \              ?There is something wonderful in seeing a wrong-headed |
  `\             majority assailed by truth.? ?John Kenneth Galbraith, |
_o__)                                                       1989-07-28 |
Ben Finney


From ziade.tarek at gmail.com  Tue Jun 17 11:56:42 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 17 Jun 2008 11:56:42 +0200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080617003916.735693A40A2@sparrow.telecommunity.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
	<20080617003916.735693A40A2@sparrow.telecommunity.com>
Message-ID: <94bdd2610806170256r276f44eco72649bc2df041b86@mail.gmail.com>

On Tue, Jun 17, 2008 at 2:37 AM, Phillip J. Eby <pje at telecommunity.com>
wrote:

> cut



>
> If you want to expand the available development pool for setuptools, I
> would strongly suggest focusing development efforts on creating a regression
> test suite emphasizing end-to-end functional testing of the current
> functionality.  Such tests would ideally be factored for narrative clarity
> and compact expressiveness, rather like Jim Fulton's doctests for
> easy_install's .exe wrappers, and the doctests for zc.buildout.  (Because if
> they're too complicated for me to read, they'll take too long for me to
> review.)
>
> If people *really* want to solve the development bottleneck, this is the
> way to go, because it will reduce my role to deciding whether something
> should go in, and seeing if it passes the tests on a platform or two.


Having a clear state of what "sits in your folder of patches" would be
useful too.
(http://mail.python.org/pipermail/distutils-sig/2008-April/009278.html)

I am not sure http://bugs.python.org/setuptools/ reflects it


That's something I think I could manage to do, even with my current work
> load.


What about dedicating a sprint on building a regression test suite this
Saturday ? It is Python bug day.

I am in to work on some doctests. Do you have the time to give us more
details on what you would
like to see ? Maybe you could write one-sentence doctests for us to start it
up this week end ?


Tarek




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



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080617/f22a0914/attachment.htm>

From david at ar.media.kyoto-u.ac.jp  Tue Jun 17 11:57:28 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 18:57:28 +0900
Subject: [Distutils] What is needed by an uninstall command to be	useful
 ?
In-Reply-To: <873ance702.fsf@benfinney.id.au>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>	<1213633860.10118.84.camel@ignacio.lan>	<48574533.3000208@ar.media.kyoto-u.ac.jp>
	<873ance702.fsf@benfinney.id.au>
Message-ID: <48578A88.4050506@ar.media.kyoto-u.ac.jp>

Ben Finney wrote:
>
> I don't understand what you mean here. How do packages get into the
> system location if they're not installed there at some time? What,
> specifically, do you hope people don't do?
>   

I meant installing packages from sources into /usr. I know some people 
do that under debian for example, and of course, they overwrite/mess up 
the package most of the time (because dpkg has already its own version 
there, for example). What else would you mean by system location ?

cheers,

David


From bignose+hates-spam at benfinney.id.au  Tue Jun 17 13:45:30 2008
From: bignose+hates-spam at benfinney.id.au (Ben Finney)
Date: Tue, 17 Jun 2008 21:45:30 +1000
Subject: [Distutils] What is needed by an uninstall command to be	useful
	?
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<1213633860.10118.84.camel@ignacio.lan>
	<48574533.3000208@ar.media.kyoto-u.ac.jp>
	<873ance702.fsf@benfinney.id.au>
	<48578A88.4050506@ar.media.kyoto-u.ac.jp>
Message-ID: <87r6awcmjp.fsf@benfinney.id.au>

David Cournapeau <david at ar.media.kyoto-u.ac.jp> writes:

> Ben Finney wrote:
> > I don't understand what you mean here. How do packages get into
> > the system location if they're not installed there at some time?
> > What, specifically, do you hope people don't do?
> 
> I meant installing packages from sources into /usr.

That's what the Debian packaging system would do when installing a
Python package. What would you have different?

> I know some people do that under debian for example, and of course,
> they overwrite/mess up the package most of the time (because dpkg
> has already its own version there, for example).

The question that seems inconsistently addressed is: What should
happen when installing (onto a Debian system) via distutils a Python
package that *isn't* packaged yet for Debian?

-- 
 \      "It is difficult to get a man to understand something when his |
  `\             salary depends upon his not understanding it." ?Upton |
_o__)                                                   Sinclair, 1935 |
Ben Finney


From david at ar.media.kyoto-u.ac.jp  Tue Jun 17 14:19:07 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 21:19:07 +0900
Subject: [Distutils] What is needed by an uninstall command to be	useful
 ?
In-Reply-To: <87r6awcmjp.fsf@benfinney.id.au>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>	<1213633860.10118.84.camel@ignacio.lan>	<48574533.3000208@ar.media.kyoto-u.ac.jp>	<873ance702.fsf@benfinney.id.au>	<48578A88.4050506@ar.media.kyoto-u.ac.jp>
	<87r6awcmjp.fsf@benfinney.id.au>
Message-ID: <4857ABBB.6050708@ar.media.kyoto-u.ac.jp>

Ben Finney wrote:
>
> That's what the Debian packaging system would do when installing a
> Python package. What would you have different?
>   

I don't understand what you are getting at. Of course the packaging 
system would install in /usr - which is exactly why a user should not 
install anything there to avoid clashing with the package manager.

>
> The question that seems inconsistently addressed is: What should
> happen when installing (onto a Debian system) via distutils a Python
> package that *isn't* packaged yet for Debian?
>   

Personally, I install everything into $HOME/local through stow (I don't 
have admin privileges at my lab). If it was meant to be system wide, I 
would install it in /usr/local instead of $HOME/local. I think this is 
pretty standard, no ?

To come back at the uninstall command: the protection of the OS sounds 
good enough to me. If things are installed system-wide, I expect the 
user knows what he is doing. If the user change prefix, I also expect 
him to change things (most 'casual' python users I have met do not 
change the prefix at all, not that I claim any knowledge on typical 
kinds of python users).

Even if I am wrong, I am not quite sure what could be done about it 
anyway (generally, you are not supposed to build things as 
root/privileged user, only install/uninstall is; uninstalling something 
without prefixing is not more dangerous than installing without prefixing).

cheers,

David

From bignose+hates-spam at benfinney.id.au  Tue Jun 17 15:04:11 2008
From: bignose+hates-spam at benfinney.id.au (Ben Finney)
Date: Tue, 17 Jun 2008 23:04:11 +1000
Subject: [Distutils] What is needed by an uninstall command to be	useful
	?
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<1213633860.10118.84.camel@ignacio.lan>
	<48574533.3000208@ar.media.kyoto-u.ac.jp>
	<873ance702.fsf@benfinney.id.au>
	<48578A88.4050506@ar.media.kyoto-u.ac.jp>
	<87r6awcmjp.fsf@benfinney.id.au>
	<4857ABBB.6050708@ar.media.kyoto-u.ac.jp>
Message-ID: <87lk14ciwk.fsf@benfinney.id.au>

David Cournapeau <david at ar.media.kyoto-u.ac.jp> writes:

> Ben Finney wrote:
> > That's what the Debian packaging system would do when installing a
> > Python package. What would you have different?
> 
> I don't understand what you are getting at. Of course the packaging
> system would install in /usr - which is exactly why a user should
> not install anything there to avoid clashing with the package
> manager.

We seem to have a terminological confusion here (there are many of
these in discussions about Python's packaging practices).

How is the Python packaging system to distinguish between different
"users" of the system? Is not the Debian packaging system a "user" of
the Python distutils/setuptools?

-- 
 \      "The fact that a believer is happier than a skeptic is no more |
  `\   to the point than the fact that a drunken man is happier than a |
_o__)                                 sober one." ?George Bernard Shaw |
Ben Finney


From david at ar.media.kyoto-u.ac.jp  Tue Jun 17 15:20:20 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 17 Jun 2008 22:20:20 +0900
Subject: [Distutils] What is needed by an uninstall command to be	useful
 ?
In-Reply-To: <87lk14ciwk.fsf@benfinney.id.au>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>	<1213633860.10118.84.camel@ignacio.lan>	<48574533.3000208@ar.media.kyoto-u.ac.jp>	<873ance702.fsf@benfinney.id.au>	<48578A88.4050506@ar.media.kyoto-u.ac.jp>	<87r6awcmjp.fsf@benfinney.id.au>	<4857ABBB.6050708@ar.media.kyoto-u.ac.jp>
	<87lk14ciwk.fsf@benfinney.id.au>
Message-ID: <4857BA14.7060504@ar.media.kyoto-u.ac.jp>

Ben Finney wrote:
>
> We seem to have a terminological confusion here (there are many of
> these in discussions about Python's packaging practices).
>
> How is the Python packaging system to distinguish between different
> "users" of the system? Is not the Debian packaging system a "user" of
> the Python distutils/setuptools?
>
>   

Not in this context, obviously; otherwise, I would mean that it is not 
advised to install anything, which does not make sense :)

The context was: how to determine which version to uninstall, assuming a 
given package were installed at several locations ? Someone mentioned 
the risk of not setting the installation directory right , which is not 
a concern for packagers. Some possible strategies are:
    - make the install directory mandatory when uninstalling ?
    - make the uninstall directory the one passed as prefix at the 
former install step, throw an error if it has not been installed yet 
(this is as good as we can get to mimic the autotools way, I think).
    - others

cheers,

David

From pje at telecommunity.com  Tue Jun 17 17:39:44 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 17 Jun 2008 11:39:44 -0400
Subject: [Distutils] What is needed by an uninstall command to be useful
 ?
In-Reply-To: <48574FB9.2070409@ar.media.kyoto-u.ac.jp>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
	<48574FB9.2070409@ar.media.kyoto-u.ac.jp>
Message-ID: <20080617153951.08C283A4105@sparrow.telecommunity.com>

At 02:46 PM 6/17/2008 +0900, David Cournapeau wrote:
>Do you think it would be possible to refactor it to split the 
>distutils/setuptools parts ? I could do it myself, obviously, but I 
>don't know anything about setuptools internals.

A trivial way to do it would be to have your uninstall command take a 
distutils installation log file as its only input argument, and then 
remove those files/directories.  This would ensure that only packages 
installed using --record would be uninstallable.


From dpeterson at enthought.com  Wed Jun 18 19:14:37 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Wed, 18 Jun 2008 12:14:37 -0500
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <20080617003916.735693A40A2@sparrow.telecommunity.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<5C8E0872-A91D-4E72-AA76-3C12C141E83E@zooko.com>
	<87tzfwdep9.fsf@benfinney.id.au>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
	<20080617003916.735693A40A2@sparrow.telecommunity.com>
Message-ID: <4859427D.3070509@enthought.com>

Phillip J. Eby wrote:
> At 06:27 PM 6/16/2008 -0500, Dave Peterson wrote:
>> Phillip J. Eby wrote:
>>> At 12:57 PM 6/16/2008 +1200, Greg Ewing wrote:
>>>> Any discussion of that sort seems to get hopelessly
>>>> bogged down, so bikeshedding is all that's left for
>>>> people to do.
>>>
>>> What about testing patches?  Writing test code?  Writing more docs?
>>> There's *plenty* of less controversial work to go around.  The only 
>>> reason most of the outstanding patches I'm aware of haven't been 
>>> applied yet is because they haven't been tested.  (Or more 
>>> precisely, because setuptools hasn't been thoroughly tested with the 
>>> patches applied.)
>>
>>
>> I can help test some of the patches
>
> Don't test patches - test setuptools with the patches.  :)  More 
> precisely, make sure you test things beyond what the patch is supposed 
> to do, to make sure that other things aren't affected.  This is 
> particularly important for patches to easy_install, which is 
> ridiculously complicated
> due to all the obscure edge cases it has to be able to handle.

Right.  That is what I meant but worded poorly. :-)


>>  I've seen people posting to the tracker, but I can't commit to 
>> svn.   Beyond running the setuptools test suite
>
> The test suite is pretty useless for most of these kinds of patches.  
> It essentially only exercises various internals of pkg_resources and a 
> few other things that are almost never touched.  I'm talking testing 
> as in "actually install some packages in a few different kinds of 
> install targets, using a few different options".  I don't have a 
> rigorous process for that, as I tend to pick things on the basis of 
> the code paths to be exercised.  But that might not be an option for 
> casual testers.

Still, I'd run it anyway. :-)   I definitely don't have the depth of 
experience to know what features being exercised hit what code paths.   
But I do use setuptools for both building and installing on Windows XP, 
Mac OS X, and various Linux flavors.   We heavily use eggs here at 
Enthought. :-)


> If I had it all to do over -- and I didn't simply run screaming from 
> attempting the task in the first place -- I would write a full 
> functional test suite, including chrooting tests if necessary.  In the 
> long run, it would have saved enormous amounts of manual test time, 
> and we could have had more people involved in development a long time 
> ago.
>
> That, by the way, is why "writing test code" is on the list above.
>
>
>> and verifying that things seems to work for me and my environment, is 
>> there anything else that will help get some of the patches into svn?
>>
>> BTW, most of those things you mention all effectively boil down to 
>> writing patches in one way or another. :-)  How do we make sure that 
>> after they get some review they get checked in when it seems so few 
>> people have check-in privileges?  Phillip, you already mentioned that 
>> you're short on time and no one else has responded to a plea for 
>> finding out who has check-in privileges.
>
> Jim Fulton has previously been "blessed" by me to apply 
> non-controversial patches to setuptools after giving me a heads-up.  
> (But note that he's probably busier than I am, and unlikely to have 
> bandwidth for stuff that doesn't affect zc.buildout or Zope in some way.)
>
> If you want to expand the available development pool for setuptools, I 
> would strongly suggest focusing development efforts on creating a 
> regression test suite emphasizing end-to-end functional testing of the 
> current functionality.  Such tests would ideally be factored for 
> narrative clarity and compact expressiveness, rather like Jim Fulton's 
> doctests for easy_install's .exe wrappers, and the doctests for 
> zc.buildout.  (Because if they're too complicated for me to read, 
> they'll take too long for me to review.)

Okay, we'll see what we can do about that here at Enthought.  So far 
we'd been focusing on bugs / new features that we thought needed to be 
addressed but that effort can be redirected a bit to helping write 
tests.  I think Tarek suggested a sprint this weekend but I'm not sure 
if any of our guys will be available that soon.  I'll ask around.

-- Dave


From jaraco at jaraco.com  Thu Jun 19 04:07:57 2008
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Wed, 18 Jun 2008 20:07:57 -0600
Subject: [Distutils] ImportError running 'test' on namespace package - other
	package in namespace not found
Message-ID: <750B64C66078B34D918257A1AC004DB20307EB@messiah.jaraco.com>

I've got two projects:  mynamespace.myprojectA and mynamespace.myprojectB
myprojectB depends on myprojectA.  I'm using setuptools 0.6c8 to manage both
projects.
Both projects are registered using 'setup develop'.  Both projects are
accessible from an interactive interpreter:

PS C:\Users\me\projects> python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import mynamespace.myprojectA
>>> import mynamespace.myprojectB
>>> from mynamespace.myprojectA import mymoduleZ

However, when I run 'setup test' in myprojectB, the tests fail with

    File ".mymoduleZ.py", line NNN, in [some context]
        from mynamespace.myprojectA.mymoduleZ import MyClassC
    ImportError: No module named myprojectA.mymoduleZ

In setup.py, the test_suite is nose.collector.

I searched and couldn't find anyone else with this problem.  Is this a
supported configuration?  Is there something I can do to make tests work
with interdependent projects with the same root namespace?

If there's not something obvious I should be doing differently, I'm happy to
put together a minimal test case that reproduces the problem.  Any
suggestions are appreciated.

Sincerely,
Jason R. Coombs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6580 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080618/588ec28a/attachment.bin>

From david at ar.media.kyoto-u.ac.jp  Fri Jun 20 05:17:36 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 12:17:36 +0900
Subject: [Distutils] What is needed by an uninstall command to be useful
 ?
In-Reply-To: <20080617153951.08C283A4105@sparrow.telecommunity.com>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
	<48574FB9.2070409@ar.media.kyoto-u.ac.jp>
	<20080617153951.08C283A4105@sparrow.telecommunity.com>
Message-ID: <485B2150.5000805@ar.media.kyoto-u.ac.jp>

Phillip J. Eby wrote:
> A trivial way to do it would be to have your uninstall command take a 
> distutils installation log file as its only input argument, and then 
> remove those files/directories.  This would ensure that only packages 
> installed using --record would be uninstallable.

Indeed. Since any uninstall command has to do this internally, it can be 
a useful start. What's the best way to submit something for distutils ? 
Python bug-tracker or somewhere specific to distutils ?

thanks,

David


From cdcasey at gmail.com  Fri Jun 20 06:02:14 2008
From: cdcasey at gmail.com (chris)
Date: Thu, 19 Jun 2008 23:02:14 -0500
Subject: [Distutils] What is needed by an uninstall command to be useful
	?
In-Reply-To: <20080617153951.08C283A4105@sparrow.telecommunity.com>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
	<48574FB9.2070409@ar.media.kyoto-u.ac.jp>
	<20080617153951.08C283A4105@sparrow.telecommunity.com>
Message-ID: <ead057790806192102j1f4445fan1590d52aedefa18d@mail.gmail.com>

On Tue, Jun 17, 2008 at 10:39 AM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 02:46 PM 6/17/2008 +0900, David Cournapeau wrote:
>
> A trivial way to do it would be to have your uninstall command take a
> distutils installation log file as its only input argument, and then remove
> those files/directories.  This would ensure that only packages installed
> using --record would be uninstallable.
>

Why have only certain packages uninstallable as opposed to everything
being uninstallable by default?

From david at ar.media.kyoto-u.ac.jp  Fri Jun 20 06:06:09 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 13:06:09 +0900
Subject: [Distutils] What is needed by an uninstall command to be useful
 ?
In-Reply-To: <ead057790806192102j1f4445fan1590d52aedefa18d@mail.gmail.com>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>	<48574FB9.2070409@ar.media.kyoto-u.ac.jp>	<20080617153951.08C283A4105@sparrow.telecommunity.com>
	<ead057790806192102j1f4445fan1590d52aedefa18d@mail.gmail.com>
Message-ID: <485B2CB1.5070503@ar.media.kyoto-u.ac.jp>

chris wrote:
>
> Why have only certain packages uninstallable as opposed to everything
> being uninstallable by default?
>   

I did not take Phillip's comment literally: I understood that the *UI* 
should take the log file as an argument, not that the file itself had to 
be produced by --record ?

cheers,

David

From pje at telecommunity.com  Fri Jun 20 13:31:12 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 20 Jun 2008 07:31:12 -0400
Subject: [Distutils] What is needed by an uninstall command to be useful
 ?
In-Reply-To: <485B2CB1.5070503@ar.media.kyoto-u.ac.jp>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
	<48574FB9.2070409@ar.media.kyoto-u.ac.jp>
	<20080617153951.08C283A4105@sparrow.telecommunity.com>
	<ead057790806192102j1f4445fan1590d52aedefa18d@mail.gmail.com>
	<485B2CB1.5070503@ar.media.kyoto-u.ac.jp>
Message-ID: <20080620113037.273233A4111@sparrow.telecommunity.com>

At 01:06 PM 6/20/2008 +0900, David Cournapeau wrote:
>chris wrote:
>>
>>Why have only certain packages uninstallable as opposed to everything
>>being uninstallable by default?
>>
>
>I did not take Phillip's comment literally: I understood that the 
>*UI* should take the log file as an argument, not that the file 
>itself had to be produced by --record ?

Well, what *else* is going to produce it?


From david at ar.media.kyoto-u.ac.jp  Fri Jun 20 13:31:15 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 20 Jun 2008 20:31:15 +0900
Subject: [Distutils] What is needed by an uninstall command to be useful
 ?
In-Reply-To: <20080620113037.273233A4111@sparrow.telecommunity.com>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
	<48574FB9.2070409@ar.media.kyoto-u.ac.jp>
	<20080617153951.08C283A4105@sparrow.telecommunity.com>
	<ead057790806192102j1f4445fan1590d52aedefa18d@mail.gmail.com>
	<485B2CB1.5070503@ar.media.kyoto-u.ac.jp>
	<20080620113037.273233A4111@sparrow.telecommunity.com>
Message-ID: <485B9503.4090606@ar.media.kyoto-u.ac.jp>

Phillip J. Eby wrote:
>
> Well, what *else* is going to produce it?

The install command. That's how I did a first draft, and that's how 
Chris did it in his patch, I think (I have not studied it carefully 
yet). An uninstall command which does not work without installing in a 
special way does not make any sense.

cheers,

David


From pje at telecommunity.com  Fri Jun 20 14:44:39 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 20 Jun 2008 08:44:39 -0400
Subject: [Distutils] What is needed by an uninstall command to be useful
 ?
In-Reply-To: <485B9503.4090606@ar.media.kyoto-u.ac.jp>
References: <485687B5.2090702@ar.media.kyoto-u.ac.jp>
	<ead057790806161028h247ca85dk6b98bb68fb8fe5dd@mail.gmail.com>
	<48574FB9.2070409@ar.media.kyoto-u.ac.jp>
	<20080617153951.08C283A4105@sparrow.telecommunity.com>
	<ead057790806192102j1f4445fan1590d52aedefa18d@mail.gmail.com>
	<485B2CB1.5070503@ar.media.kyoto-u.ac.jp>
	<20080620113037.273233A4111@sparrow.telecommunity.com>
	<485B9503.4090606@ar.media.kyoto-u.ac.jp>
Message-ID: <20080620124405.520073A40D9@sparrow.telecommunity.com>

At 08:31 PM 6/20/2008 +0900, David Cournapeau wrote:
>Phillip J. Eby wrote:
>>
>>Well, what *else* is going to produce it?
>
>The install command. That's how I did a first draft, and that's how 
>Chris did it in his patch, I think (I have not studied it carefully 
>yet). An uninstall command which does not work without installing in 
>a special way does not make any sense.

Keep in mind that system-managed packages (e.g. RPMs) must NOT 
install this file, to prevent users from uninstalling them without 
the tool.  So, there must be at least a way to suppress its creation.


From pje at telecommunity.com  Fri Jun 20 14:45:58 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 20 Jun 2008 08:45:58 -0400
Subject: [Distutils] ImportError running 'test' on namespace package -
 other package in namespace not found
In-Reply-To: <750B64C66078B34D918257A1AC004DB20307EB@messiah.jaraco.com>
References: <750B64C66078B34D918257A1AC004DB20307EB@messiah.jaraco.com>
Message-ID: <20080620124522.215D53A40D9@sparrow.telecommunity.com>

At 08:07 PM 6/18/2008 -0600, Jason R. Coombs wrote:
>If there's not something obvious I should be doing differently, I'm happy to
>put together a minimal test case that reproduces the problem.

Please do.  Thanks!


From ziade.tarek at gmail.com  Fri Jun 20 17:40:08 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 20 Jun 2008 17:40:08 +0200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <4859427D.3070509@enthought.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
	<20080617003916.735693A40A2@sparrow.telecommunity.com>
	<4859427D.3070509@enthought.com>
Message-ID: <94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>

On Wed, Jun 18, 2008 at 7:14 PM, Dave Peterson <dpeterson at enthought.com>
wrote:

>
> If you want to expand the available development pool for setuptools, I
>> would strongly suggest focusing development efforts on creating a regression
>> test suite emphasizing end-to-end functional testing of the current
>> functionality.  Such tests would ideally be factored for narrative clarity
>> and compact expressiveness, rather like Jim Fulton's doctests for
>> easy_install's .exe wrappers, and the doctests for zc.buildout.  (Because if
>> they're too complicated for me to read, they'll take too long for me to
>> review.)
>>
>
> Okay, we'll see what we can do about that here at Enthought.  So far we'd
> been focusing on bugs / new features that we thought needed to be addressed
> but that effort can be redirected a bit to helping write tests.  I think
> Tarek suggested a sprint this weekend but I'm not sure if any of our guys
> will be available that soon.  I'll ask around.


Ok cool,

I can spend a bit of time on sunday on this topic, writing a few scenarii.
What I have been thinking of is:

- a doctest for each command setuptools provides
- a doctest for easy_install
- a doctest that uses setuptools/distutils to build, release, and upload a
package

Anything else in mind ?

Tarek




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



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080620/d737f6aa/attachment.htm>

From cgalvan at mail.utexas.edu  Fri Jun 20 17:56:12 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Fri, 20 Jun 2008 10:56:12 -0500
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>	<20080614064602.GK71640@nexus.in-nomine.org>	<48545982.4000406@canterbury.ac.nz>	<20080615032612.926A33A405F@sparrow.telecommunity.com>	<4855BA60.2070003@canterbury.ac.nz>	<20080616054416.646E33A40C2@sparrow.telecommunity.com>	<4856F6E5.8040406@enthought.com>	<20080617003916.735693A40A2@sparrow.telecommunity.com>	<4859427D.3070509@enthought.com>
	<94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>
Message-ID: <485BD31C.9060202@mail.utexas.edu>

Tarek Ziad? wrote:
>
>
> On Wed, Jun 18, 2008 at 7:14 PM, Dave Peterson 
> <dpeterson at enthought.com <mailto:dpeterson at enthought.com>> wrote:
>
>
>         If you want to expand the available development pool for
>         setuptools, I would strongly suggest focusing development
>         efforts on creating a regression test suite emphasizing
>         end-to-end functional testing of the current functionality.
>          Such tests would ideally be factored for narrative clarity
>         and compact expressiveness, rather like Jim Fulton's doctests
>         for easy_install's .exe wrappers, and the doctests for
>         zc.buildout.  (Because if they're too complicated for me to
>         read, they'll take too long for me to review.)
>
>
>     Okay, we'll see what we can do about that here at Enthought.  So
>     far we'd been focusing on bugs / new features that we thought
>     needed to be addressed but that effort can be redirected a bit to
>     helping write tests.  I think Tarek suggested a sprint this
>     weekend but I'm not sure if any of our guys will be available that
>     soon.  I'll ask around.
>
>
> Ok cool,
>
> I can spend a bit of time on sunday on this topic, writing a few 
> scenarii. What I have been thinking of is:
>
> - a doctest for each command setuptools provides
> - a doctest for easy_install
> - a doctest that uses setuptools/distutils to build, release, and 
> upload a package
>
> Anything else in mind ?
>
> Tarek
>
>
That list looks like a great place to start :)  I can spend some time 
this weekend working on this as well, if you want to coordinate efforts.

-- Chris Galvan
>  
>
>
>
>     -- Dave
>
>
>     _______________________________________________
>     Distutils-SIG maillist  -  Distutils-SIG at python.org
>     <mailto:Distutils-SIG at python.org>
>     http://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
>
> -- 
> Tarek Ziad? | Association AfPy | www.afpy.org <http://www.afpy.org>
> Blog FR | http://programmation-python.org
> Blog EN | http://tarekziade.wordpress.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>   


From ziade.tarek at gmail.com  Fri Jun 20 18:13:16 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 20 Jun 2008 18:13:16 +0200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <485BD31C.9060202@mail.utexas.edu>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
	<20080617003916.735693A40A2@sparrow.telecommunity.com>
	<4859427D.3070509@enthought.com>
	<94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>
	<485BD31C.9060202@mail.utexas.edu>
Message-ID: <94bdd2610806200913i110b7538v57cecdcf62916716@mail.gmail.com>

On Fri, Jun 20, 2008 at 5:56 PM, Chris Galvan <cgalvan at mail.utexas.edu>
wrote:

>
> I can spend a bit of time on sunday on this topic, writing a few scenarii.
>> What I have been thinking of is:
>>
>> - a doctest for each command setuptools provides
>> - a doctest for easy_install
>> - a doctest that uses setuptools/distutils to build, release, and upload a
>> package
>>
>> Anything else in mind ?
>>
>> Tarek
>>
>>
>>  That list looks like a great place to start :)  I can spend some time
> this weekend working on this as well, if you want to coordinate efforts.
>

Sure that would be great

I can be present Sunday from 9am to 11am and after 8pm CEST time (Paris)
So i guess we can meet after 8pm if you are locate in Texas ?

Tarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080620/18231328/attachment.htm>

From cgalvan at mail.utexas.edu  Fri Jun 20 19:43:43 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Fri, 20 Jun 2008 12:43:43 -0500
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <94bdd2610806200913i110b7538v57cecdcf62916716@mail.gmail.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>	
	<48545982.4000406@canterbury.ac.nz>	
	<20080615032612.926A33A405F@sparrow.telecommunity.com>	
	<4855BA60.2070003@canterbury.ac.nz>	
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>	
	<4856F6E5.8040406@enthought.com>	
	<20080617003916.735693A40A2@sparrow.telecommunity.com>	
	<4859427D.3070509@enthought.com>	
	<94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>	
	<485BD31C.9060202@mail.utexas.edu>
	<94bdd2610806200913i110b7538v57cecdcf62916716@mail.gmail.com>
Message-ID: <485BEC4F.1020300@mail.utexas.edu>

Tarek Ziad? wrote:
>
>
> On Fri, Jun 20, 2008 at 5:56 PM, Chris Galvan <cgalvan at mail.utexas.edu 
> <mailto:cgalvan at mail.utexas.edu>> wrote:
>
>
>         I can spend a bit of time on sunday on this topic, writing a
>         few scenarii. What I have been thinking of is:
>
>         - a doctest for each command setuptools provides
>         - a doctest for easy_install
>         - a doctest that uses setuptools/distutils to build, release,
>         and upload a package
>
>         Anything else in mind ?
>
>         Tarek
>
>
>     That list looks like a great place to start :)  I can spend some
>     time this weekend working on this as well, if you want to
>     coordinate efforts.
>
>
> Sure that would be great
>
> I can be present Sunday from 9am to 11am and after 8pm CEST time (Paris) 
> So i guess we can meet after 8pm if you are locate in Texas ?
>
> Tarek
Yes, I live in Texas.  Anytime after 8pm CEST works great since that 
will be 1pm for me.  Would IRC be a good discussion place to meet so 
that others could help out as well?

-- Chris Galvan


From ziade.tarek at gmail.com  Fri Jun 20 20:11:37 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 20 Jun 2008 20:11:37 +0200
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <485BEC4F.1020300@mail.utexas.edu>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
	<20080617003916.735693A40A2@sparrow.telecommunity.com>
	<4859427D.3070509@enthought.com>
	<94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>
	<485BD31C.9060202@mail.utexas.edu>
	<94bdd2610806200913i110b7538v57cecdcf62916716@mail.gmail.com>
	<485BEC4F.1020300@mail.utexas.edu>
Message-ID: <94bdd2610806201111o72617ca0oa0241017d75345df@mail.gmail.com>

On Fri, Jun 20, 2008 at 7:43 PM, Chris Galvan <cgalvan at mail.utexas.edu>
wrote:

> Tarek Ziad? wrote:
>
>
>>
>> On Fri, Jun 20, 2008 at 5:56 PM, Chris Galvan <cgalvan at mail.utexas.edu<mailto:
>> cgalvan at mail.utexas.edu>> wrote:
>>
>>
>>        I can spend a bit of time on sunday on this topic, writing a
>>        few scenarii. What I have been thinking of is:
>>
>>        - a doctest for each command setuptools provides
>>        - a doctest for easy_install
>>        - a doctest that uses setuptools/distutils to build, release,
>>        and upload a package
>>
>>        Anything else in mind ?
>>
>>        Tarek
>>
>>
>>    That list looks like a great place to start :)  I can spend some
>>    time this weekend working on this as well, if you want to
>>    coordinate efforts.
>>
>>
>> Sure that would be great
>>
>> I can be present Sunday from 9am to 11am and after 8pm CEST time (Paris)
>> So i guess we can meet after 8pm if you are locate in Texas ?
>>
>> Tarek
>>
> Yes, I live in Texas.  Anytime after 8pm CEST works great since that will
> be 1pm for me.  Would IRC be a good discussion place to meet so that others
> could help out as well?


Sure, let's meet at #distutils






>
>
> -- Chris Galvan
>
>


-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080620/81ad9e64/attachment.htm>

From zooko at zooko.com  Fri Jun 20 20:26:07 2008
From: zooko at zooko.com (zooko)
Date: Fri, 20 Jun 2008 11:26:07 -0700
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<6FB41E75-28D1-4504-B302-25EF061E4180@zooko.com>
	<20080614064602.GK71640@nexus.in-nomine.org>
	<48545982.4000406@canterbury.ac.nz>
	<20080615032612.926A33A405F@sparrow.telecommunity.com>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
	<20080617003916.735693A40A2@sparrow.telecommunity.com>
	<4859427D.3070509@enthought.com>
	<94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>
Message-ID: <E257F8A6-451B-4691-BEFE-4226922AE105@zooko.com>

Another way that easy_install/setuptools gets tested is when projects  
that use it have automated, automatically scheduled tests of their  
install process.

For example, divmod Nevow recently set up an automated test of  
installing Nevow using easy_install.

For example, here is a successful install:

http://divmod.org/users/buildbot.twistd/q-nevowinstall/builds/26/step- 
shell_3/0

Unfortunately, such tests only test some released version of  
setuptools/easy_install, not the current head version.  It would be  
potentially interesting for such tests of setuptools-using-projects- 
install-and-unit-tests to be run in response to SVN checkins to  
setuptools (triggered by buildbot).

Regards,

Zooko


From zooko at zooko.com  Fri Jun 20 20:28:08 2008
From: zooko at zooko.com (zooko)
Date: Fri, 20 Jun 2008 11:28:08 -0700
Subject: [Distutils] [issue24] Rename easy_install
In-Reply-To: <94bdd2610806201111o72617ca0oa0241017d75345df@mail.gmail.com>
References: <1213358351.24.0.221582848829.issue24@psf.upfronthosting.co.za>
	<4855BA60.2070003@canterbury.ac.nz>
	<20080616054416.646E33A40C2@sparrow.telecommunity.com>
	<4856F6E5.8040406@enthought.com>
	<20080617003916.735693A40A2@sparrow.telecommunity.com>
	<4859427D.3070509@enthought.com>
	<94bdd2610806200840m3b05c727l100fb11ada73ddca@mail.gmail.com>
	<485BD31C.9060202@mail.utexas.edu>
	<94bdd2610806200913i110b7538v57cecdcf62916716@mail.gmail.com>
	<485BEC4F.1020300@mail.utexas.edu>
	<94bdd2610806201111o72617ca0oa0241017d75345df@mail.gmail.com>
Message-ID: <572FCF9E-0E9E-4685-B0EF-3B46D260A2A2@zooko.com>

On Jun 20, 2008, at 11:11 AM, Tarek Ziad? wrote:

> Sure, let's meet at #distutils

By the way, I've noticed that people occasionally appear on  
irc.freenode.net channel #setuptools to ask for help with their usage  
of setuptools.  Presumably they are just running a "list channels"  
tool on irc.freenode.net and noticing "#setuptools" listed therein.   
Perhaps they will likewise do so for the channel "#distutils".

Regards,

Zooko


From robert at redcor.ch  Sat Jun 21 11:56:52 2008
From: robert at redcor.ch (robert rottermann)
Date: Sat, 21 Jun 2008 11:56:52 +0200
Subject: [Distutils] problem with setuptools when using subversion 1.5
Message-ID: <485CD064.8090109@redcor.ch>

Hi there,
I found two problems using setuptools 0.6c8 in conjunction with suversion 1.5

1. the file setuptools/commands/sdist.py checks for '8' as the start of an 
svn.entires file (line 89). in subversion 1.5 this is '9'.
2. it the tries to log a warning, but log is not imported (line 98).

I changed '8' to '9' and all works fine again. seems no further changes in the 
structure of the file have been incoorporated that would affect the working of 
setuptools.

thanks for your great tools
robert

From ianb at colorstudy.com  Sat Jun 21 22:00:19 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat, 21 Jun 2008 15:00:19 -0500
Subject: [Distutils] [venv] Re: Changes & News / 1.1 / * Added support
 for Python 2.6.
In-Reply-To: <b7c4b220-4f69-4394-95ff-d0286a62b474@d45g2000hsc.googlegroups.com>
References: <7939f1a6-56c0-49ec-9c05-8f62af6eb216@t54g2000hsg.googlegroups.com>
	<485D3040.4090203@colorstudy.com>
	<bb8409bf-a0dc-4cd9-b79a-9eb39231b773@m44g2000hsc.googlegroups.com>
	<485D44D3.7000107@colorstudy.com>
	<b7c4b220-4f69-4394-95ff-d0286a62b474@d45g2000hsc.googlegroups.com>
Message-ID: <485D5DD3.6070308@colorstudy.com>

d2m wrote:
> You could go on and add another 3 modules
> ('linecache','_abcoll','abc') to REQUIRED_MODULES just to find that
> setuptools itself cannot be copied to my_env/lib/python2.6/site-
> packages -- because there is no such distribution (2.6) right now:
> 
> Downloading http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c8-py2.6.eggtry
> run python2.6 ez_setup.py, gets you almost the same error.)
> 
> How did you install setuptools and virtualenv to make it functional?

*I* haven't, because I don't have Python 2.6 and haven't tried it with 
that.  I've added the other modules, but I'm not sure how to deal with 
the issue of a lack of a 2.6 setuptools egg.

So, copying the distutils list: what's the best way to handle setuptools 
installation on Python 2.6?

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From bignose+hates-spam at benfinney.id.au  Sun Jun 22 00:30:13 2008
From: bignose+hates-spam at benfinney.id.au (Ben Finney)
Date: Sun, 22 Jun 2008 08:30:13 +1000
Subject: [Distutils] [venv] Re: Changes & News / 1.1 / * Added support
	for Python 2.6.
References: <7939f1a6-56c0-49ec-9c05-8f62af6eb216@t54g2000hsg.googlegroups.com>
	<485D3040.4090203@colorstudy.com>
	<bb8409bf-a0dc-4cd9-b79a-9eb39231b773@m44g2000hsc.googlegroups.com>
	<485D44D3.7000107@colorstudy.com>
	<b7c4b220-4f69-4394-95ff-d0286a62b474@d45g2000hsc.googlegroups.com>
	<485D5DD3.6070308@colorstudy.com>
Message-ID: <87bq1uv2tm.fsf@benfinney.id.au>

Ian Bicking <ianb at colorstudy.com> writes:

> So, copying the distutils list: what's the best way to handle
> setuptools installation on Python 2.6?

Install from a source dist? i.e., unpack it to a temporary location,
'python ./setup.py install', remove the temporary location.

-- 
 \     "If I melt dry ice, can I swim without getting wet?"  -- Steven |
  `\                                                            Wright |
_o__)                                                                  |
Ben Finney


From ziade.tarek at gmail.com  Sun Jun 22 14:20:07 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 22 Jun 2008 14:20:07 +0200
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
Message-ID: <94bdd2610806220520p2a3ecaf4r7ed48c0434e506ed@mail.gmail.com>

On Sun, Jun 22, 2008 at 11:25 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> Hi,
>
> Like discussed earlier, some people will work today on adding tests to
> setuptools.
>
> The idea is to add human-readable doctests to setuptools a bit like what
> zc.buildout has.
>
> I am planning to create one doctest per setuptools feature, and some
> general doctest that
> demonstrates the usage of the tool. (functional tests but preferrably with
> no os.popen/os.system magic)
>


Heres a first quick draft for 'develop':

http://paste.plone.org/22122

It uses a bit of magic to simulate a command line usage like in zc.buildout,
to avoid having to write too much test fixture in the doctests.

It prints out all infos written by setuptools to distutils.log.info (so to
stdout as well)

I guess this is enough to write functional tests for all commands,
I am going to write similar doctest for all commands,

Phillip, is this what you had in mind ?

Regards

Tarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080622/ac092989/attachment.htm>

From ziade.tarek at gmail.com  Sun Jun 22 23:42:39 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 22 Jun 2008 23:42:39 +0200
Subject: [Distutils] distutils sprint wrapup
Message-ID: <94bdd2610806221442gb6b1d1fo8f90046903a15e94@mail.gmail.com>

Hello,

We sprinted together with Chris on adding doctests with distutils,
by taking each command and adding a doctest that demonstrates it.

Chris worked under windows and I worked under Mac, which was
great to get more robust tests quickly.

We covered so far 7 commands with various level of details
(egg_infos.txt is more detailed for instance).

We think it is the best approach to start things up,
as the tests will evolve on each code change later.

I guess we will continue covering commands,
and wait for Phillip feedback and others.

Especially about the amount of "magic" doctesting.py
introduces into the doctests syntax.

See : http://bazaar.launchpad.net/~setuptools/setuptools-test/main/files

That was a very productive and fun sprint,

++
Tarek

-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080622/0519f250/attachment.htm>

From ziade.tarek at gmail.com  Sun Jun 22 11:25:37 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 22 Jun 2008 11:25:37 +0200
Subject: [Distutils] setuptools "tests" sprint today
Message-ID: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>

Hi,

Like discussed earlier, some people will work today on adding tests to
setuptools.

The idea is to add human-readable doctests to setuptools a bit like what
zc.buildout has.

I am planning to create one doctest per setuptools feature, and some general
doctest that
demonstrates the usage of the tool. (functional tests but preferrably with
no os.popen/os.system magic)

To synchronize all our work (I doubt we can all get commiter access to
svn.python.org today :D ),
I have created a launchpad project here:
https://launchpad.net/setuptools-test

It is a copy of the current setuptools trunk, you can get it with bzr:

bzr branch lp:~tziade/setuptools-test/main

I suggest we all push changes there then present that work for review to
Phillip,

Let's meet in #distutils today !

Regards
Tarek

-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080622/2fe8ed24/attachment.htm>

From lists at durin42.com  Mon Jun 23 16:13:06 2008
From: lists at durin42.com (Augie Fackler)
Date: Mon, 23 Jun 2008 09:13:06 -0500
Subject: [Distutils] problem with setuptools when using subversion 1.5
In-Reply-To: <485CD064.8090109@redcor.ch>
References: <485CD064.8090109@redcor.ch>
Message-ID: <B8928CAA-303A-4F34-819E-53195A78B5E3@durin42.com>


On Jun 21, 2008, at 4:56 AM, robert rottermann wrote:

> Hi there,
> I found two problems using setuptools 0.6c8 in conjunction with  
> suversion 1.5
>
> 1. the file setuptools/commands/sdist.py checks for '8' as the start  
> of an svn.entires file (line 89). in subversion 1.5 this is '9'.
> 2. it the tries to log a warning, but log is not imported (line 98).
>
> I changed '8' to '9' and all works fine again. seems no further  
> changes in the structure of the file have been incoorporated that  
> would affect the working of setuptools.

I've read the svn notes on the wc entries file format - nothing  
substantial has changed, and that regular expression should continue  
to work.
I've even tried this on some checkouts that use the new features in a  
version 9 entries file - the patch I've attached to the ticket http://bugs.python.org/issue2770 
  fixes the problem. I've been running with that setup for months now.

If desired, I'll even rework the patch so that the missing import gets  
fixed.


> thanks for your great tools
> robert
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From cgalvan at mail.utexas.edu  Mon Jun 23 17:56:54 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Mon, 23 Jun 2008 10:56:54 -0500
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
Message-ID: <485FC7C6.6020505@mail.utexas.edu>

Tarek Ziad? wrote:
> Hi,
>
> Like discussed earlier, some people will work today on adding tests to 
> setuptools.
>
> The idea is to add human-readable doctests to setuptools a bit like 
> what zc.buildout has.
>
> I am planning to create one doctest per setuptools feature, and some 
> general doctest that
> demonstrates the usage of the tool. (functional tests but preferrably 
> with no os.popen/os.system magic)
>
> To synchronize all our work (I doubt we can all get commiter access to 
> svn.python.org <http://svn.python.org> today :D ),
> I have created a launchpad project here: 
> https://launchpad.net/setuptools-test
>
> It is a copy of the current setuptools trunk, you can get it with bzr:
>
> bzr branch lp:~tziade/setuptools-test/main
Since we created a group for setuptools, the new link to the branch is:

bzr branch lp:~setuptools/setuptools-test/main

-- Chris Galvan
>
> I suggest we all push changes there then present that work for review 
> to Phillip,
>
> Let's meet in #distutils today !
>
> Regards
> Tarek
>
> -- 
> Tarek Ziad? | Association AfPy | www.afpy.org <http://www.afpy.org>
> Blog FR | http://programmation-python.org
> Blog EN | http://tarekziade.wordpress.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>   


From plewis at spamcop.net  Tue Jun 24 02:29:48 2008
From: plewis at spamcop.net (Patrick Lewis)
Date: Mon, 23 Jun 2008 20:29:48 -0400
Subject: [Distutils] easy_install installing old version
Message-ID: <7F8DE020-4E16-490C-B7AB-77589023E949@spamcop.net>

Hello, I'm having some trouble with easy_install finding and  
installing old packages, and I'm not sure why. Specifically, with  
python2.4, easy_install wants to grab the oldest egg file possible,  
rather than newer egg or tar.gz  source distributions.

Here is the pypi page:

http://pypi.python.org/pypi/registration

and here is a sample install (from a fresh virtualenv)

(ENV_24_clean)pat-mac:~/Programming/TurboGears/ENV_24_clean plewis$  
which easy_install-2.4
/Users/plewis/Programming/TurboGears/ENV_24_clean/bin/easy_install-2.4
(ENV_24_clean)pat-mac:~/Programming/TurboGears/ENV_24_clean plewis$  
easy_install-2.4 -U registration
Searching for registration
Reading http://pypi.python.org/simple/registration/
Reading http://patrickhlewis.googlepages.com/registration.html
Reading http://pat.lewis.home.insightbb.com/
Best match: registration 0.11
Processing registration-0.11-py2.4.egg
registration 0.11 is already the active version in easy-install.pth

I'm not quite sure what's going on here, since

http://pypi.python.org/simple/registration/

clearly shows newer versions. If someone could point out what I've  
done wrong, I'd much appreciate it.

From tseaver at palladion.com  Tue Jun 24 05:24:35 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 23 Jun 2008 23:24:35 -0400
Subject: [Distutils] easy_install installing old version
In-Reply-To: <7F8DE020-4E16-490C-B7AB-77589023E949@spamcop.net>
References: <7F8DE020-4E16-490C-B7AB-77589023E949@spamcop.net>
Message-ID: <486068F3.1080108@palladion.com>

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

Patrick Lewis wrote:
> Hello, I'm having some trouble with easy_install finding and  
> installing old packages, and I'm not sure why. Specifically, with  
> python2.4, easy_install wants to grab the oldest egg file possible,  
> rather than newer egg or tar.gz  source distributions.
> 
> Here is the pypi page:
> 
> http://pypi.python.org/pypi/registration
> 
> and here is a sample install (from a fresh virtualenv)
> 
> (ENV_24_clean)pat-mac:~/Programming/TurboGears/ENV_24_clean plewis$  
> which easy_install-2.4
> /Users/plewis/Programming/TurboGears/ENV_24_clean/bin/easy_install-2.4
> (ENV_24_clean)pat-mac:~/Programming/TurboGears/ENV_24_clean plewis$  
> easy_install-2.4 -U registration
> Searching for registration
> Reading http://pypi.python.org/simple/registration/
> Reading http://patrickhlewis.googlepages.com/registration.html
> Reading http://pat.lewis.home.insightbb.com/
> Best match: registration 0.11
> Processing registration-0.11-py2.4.egg
> registration 0.11 is already the active version in easy-install.pth
> 
> I'm not quite sure what's going on here, since
> 
> http://pypi.python.org/simple/registration/
> 
> clearly shows newer versions. If someone could point out what I've  
> done wrong, I'd much appreciate it.

0.11 is the latest version I see there:  the others (0.2, 0.3, 0.4) are
all earlier.  It helps to think of version numbers as the result of
calling '.'.join(version_parts);  they are *not* decimal numbers.  So,
the tuple in question would be (0, 11), which is clearly greater than
(0, 4).


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

iD8DBQFIYGjy+gerLs4ltQ4RAm5LAJ0QdPI8tNDRxNB1rT3lh+ejCfD4eACgrWf1
qxeD33qTEBT0bqO403o3rXg=
=0gAT
-----END PGP SIGNATURE-----


From tseaver at palladion.com  Tue Jun 24 05:24:35 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 23 Jun 2008 23:24:35 -0400
Subject: [Distutils] easy_install installing old version
In-Reply-To: <7F8DE020-4E16-490C-B7AB-77589023E949@spamcop.net>
References: <7F8DE020-4E16-490C-B7AB-77589023E949@spamcop.net>
Message-ID: <486068F3.1080108@palladion.com>

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

Patrick Lewis wrote:
> Hello, I'm having some trouble with easy_install finding and  
> installing old packages, and I'm not sure why. Specifically, with  
> python2.4, easy_install wants to grab the oldest egg file possible,  
> rather than newer egg or tar.gz  source distributions.
> 
> Here is the pypi page:
> 
> http://pypi.python.org/pypi/registration
> 
> and here is a sample install (from a fresh virtualenv)
> 
> (ENV_24_clean)pat-mac:~/Programming/TurboGears/ENV_24_clean plewis$  
> which easy_install-2.4
> /Users/plewis/Programming/TurboGears/ENV_24_clean/bin/easy_install-2.4
> (ENV_24_clean)pat-mac:~/Programming/TurboGears/ENV_24_clean plewis$  
> easy_install-2.4 -U registration
> Searching for registration
> Reading http://pypi.python.org/simple/registration/
> Reading http://patrickhlewis.googlepages.com/registration.html
> Reading http://pat.lewis.home.insightbb.com/
> Best match: registration 0.11
> Processing registration-0.11-py2.4.egg
> registration 0.11 is already the active version in easy-install.pth
> 
> I'm not quite sure what's going on here, since
> 
> http://pypi.python.org/simple/registration/
> 
> clearly shows newer versions. If someone could point out what I've  
> done wrong, I'd much appreciate it.

0.11 is the latest version I see there:  the others (0.2, 0.3, 0.4) are
all earlier.  It helps to think of version numbers as the result of
calling '.'.join(version_parts);  they are *not* decimal numbers.  So,
the tuple in question would be (0, 11), which is clearly greater than
(0, 4).


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

iD8DBQFIYGjy+gerLs4ltQ4RAm5LAJ0QdPI8tNDRxNB1rT3lh+ejCfD4eACgrWf1
qxeD33qTEBT0bqO403o3rXg=
=0gAT
-----END PGP SIGNATURE-----

From plewis at spamcop.net  Tue Jun 24 12:54:05 2008
From: plewis at spamcop.net (Patrick Lewis)
Date: Tue, 24 Jun 2008 06:54:05 -0400
Subject: [Distutils] easy_install installing old version
In-Reply-To: <486068F3.1080108@palladion.com>
References: <7F8DE020-4E16-490C-B7AB-77589023E949@spamcop.net>
	<486068F3.1080108@palladion.com>
Message-ID: <5281295B-7635-442E-937E-1E73D8EB8BD0@spamcop.net>


On Jun 23, 2008, at 11:24 PM, Tres Seaver wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Patrick Lewis wrote:
>> registration 0.11 is already the active version in easy-install.pth
>>
>> I'm not quite sure what's going on here, since
>>
>> http://pypi.python.org/simple/registration/
>>
>> clearly shows newer versions. If someone could point out what I've
>> done wrong, I'd much appreciate it.
>
> 0.11 is the latest version I see there:  the others (0.2, 0.3, 0.4)  
> are
> all earlier.  It helps to think of version numbers as the result of
> calling '.'.join(version_parts);  they are *not* decimal numbers.  So,
> the tuple in question would be (0, 11), which is clearly greater than
> (0, 4).
>
>
> Tres.
> - --

Ok, that makes sense. And it works for 2.5 because there is no (0,  
11) for 2.5, only a 2.4 egg.  Argh. Thanks.



From dorneles at x3ng.com.br  Wed Jun 25 01:17:00 2008
From: dorneles at x3ng.com.br (=?ISO-8859-1?Q?Dorneles_Trem=E9a?=)
Date: Tue, 24 Jun 2008 20:17:00 -0300
Subject: [Distutils] buildout: setting envirionment variables for
	zc.recipe.egg:custom?
In-Reply-To: <fpbuj9$jv2$1@ger.gmane.org>
References: <foplof$n3g$1@ger.gmane.org>	<FCDAEF1C-B42C-4055-B448-EBAD943AB4B4@zope.com>	<fpbmdv$lr0$1@ger.gmane.org>
	<fpbuj9$jv2$1@ger.gmane.org>
Message-ID: <g3rv9b$mo3$1@ger.gmane.org>

Hello,

> > > I suggest updating zc.recipe.egg:custom to accept environment-
> > > variable, assuming that setting environment variables is sufficient.
> >
> > I added setting the environment in r84015. Jim, could you review that?
> 
> I added some fixes and did some cleanup in r84019.

may I poke you guys for a new release of zc.recipe.egg? :-)

-- 

Dorneles Trem?a
X3ng Web Technology
http://nosleepforyou.blogspot.com


From ena2413 at gmail.com  Wed Jun 25 10:47:26 2008
From: ena2413 at gmail.com (Zahed Emon)
Date: Wed, 25 Jun 2008 10:47:26 +0200
Subject: [Distutils] Adding include path during install
Message-ID: <378ad3ad0806250147t70d96aahc1e45b18effcc7ef@mail.gmail.com>

Hi,

I am trying to install PJSIP py-pjsua with distutils setup.py install
command. But the while building with visual studio .NET 2003 it
complains about missing header files. the files are there I suppose
its not finding paths to it.
SO is it possible to give the path to include directory?

thanks in advance

BR

Sarker

From prepin at gmail.com  Thu Jun 26 01:05:05 2008
From: prepin at gmail.com (Pavel Repin)
Date: Wed, 25 Jun 2008 16:05:05 -0700
Subject: [Distutils] Two bugs in
	setuptools-0.6c8-py2.5.egg/setuptools/command/sdist.py
	(entries_finder)
Message-ID: <4b217830806251605p39b5ba68v84c696fb601cca54@mail.gmail.com>

Hi,
I noticed the following by running setup.py in a non SVN-1.4 working copy.

   1. When 'entries_finder' gets confused about the svn working copy .svn
   entries, it tries to log an error by doing: log.warn(....). But there's no
   'log' object. See a simple hack that fixes it (the diff attached).
   2. It assumes my working copy format is SVN-1.4. But, I happen to use a
   SVN 1.5 working copy that contains my setup.py.

Does 'entries_finder' simply try to find objects that are under version
control minus the ones that have pending delete status? If so, maybe
invoking 'svn status' in a child process and parsing its output would be
better?

-- 
Pavel Repin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080625/9bcb29dd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdist.py.diff
Type: application/octet-stream
Size: 416 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080625/9bcb29dd/attachment.obj>

From chris at simplistix.co.uk  Thu Jun 26 13:18:22 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 26 Jun 2008 12:18:22 +0100
Subject: [Distutils] how can I find out what version of an egg buildout has
	selected?
Message-ID: <48637AFE.7030605@simplistix.co.uk>

Hi All,

If I have a buildout.cfg such as:

[buildout]
eggs =
     some.egg
     some.other.egg

...what's the correct way to find out what versiosn of these eggs 
buildout has selected and is using?

cheers,

Chris

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

From ziade.tarek at gmail.com  Thu Jun 26 14:09:10 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 26 Jun 2008 14:09:10 +0200
Subject: [Distutils] how can I find out what version of an egg buildout
	has selected?
In-Reply-To: <48637AFE.7030605@simplistix.co.uk>
References: <48637AFE.7030605@simplistix.co.uk>
Message-ID: <94bdd2610806260509p23d3555eia7147705b6e5e25a@mail.gmail.com>

On Thu, Jun 26, 2008 at 1:18 PM, Chris Withers <chris at simplistix.co.uk>
wrote:

> Hi All,
>
> If I have a buildout.cfg such as:
>
> [buildout]
> eggs =
>    some.egg
>    some.other.egg
>
> ...what's the correct way to find out what versiosn of these eggs buildout
> has selected and is using?


I read the output of "bin/buildout -v", where versions are shown.

otherwise you can look at the result in your buildout:

Buildout does not have an eggs section, it is probably used in another
section, with ${buildout:eggs}.

Are you installing a zope or a plone ? if so, the recipe that uses the eggs
variable here,
has probably created a script in bin/ where you will find something like:

import sys
sys.path[0:0] = [
   some eggs
]

So you can see which eggs were used, with their paths

That would be 'zopepy' or 'instance' for a typical plone buildout for
example

Tarek



>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Zope & 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? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080626/e9e8bce8/attachment.htm>

From cgalvan at mail.utexas.edu  Thu Jun 26 20:51:09 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Thu, 26 Jun 2008 13:51:09 -0500
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
Message-ID: <4863E51D.4010708@mail.utexas.edu>

Hello,

I was hoping to have another sprint this weekend to continue our work on 
adding
tests to setuptools, but we haven't received any feedback on the work 
we've done
so far yet.  We would like to get some feedback from others, especially 
Phillip, on
the work we've done so far before continuing to work on the tests :)

For iteration's sake, here is the link to the launchpad project being used:
https://code.launchpad.net/~setuptools/setuptools-test/main

-- Chris Galvan

Tarek Ziad? wrote:
> Hi,
>
> Like discussed earlier, some people will work today on adding tests to 
> setuptools.
>
> The idea is to add human-readable doctests to setuptools a bit like 
> what zc.buildout has.
>
> I am planning to create one doctest per setuptools feature, and some 
> general doctest that
> demonstrates the usage of the tool. (functional tests but preferrably 
> with no os.popen/os.system magic)
>
> To synchronize all our work (I doubt we can all get commiter access to 
> svn.python.org <http://svn.python.org> today :D ),
> I have created a launchpad project here: 
> https://launchpad.net/setuptools-test
>
> It is a copy of the current setuptools trunk, you can get it with bzr:
>
> bzr branch lp:~tziade/setuptools-test/main
>
> I suggest we all push changes there then present that work for review 
> to Phillip,
>
> Let's meet in #distutils today !
>
> Regards
> Tarek
>
> -- 
> Tarek Ziad? | Association AfPy | www.afpy.org <http://www.afpy.org>
> Blog FR | http://programmation-python.org
> Blog EN | http://tarekziade.wordpress.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>   


From marius at pov.lt  Thu Jun 26 22:45:12 2008
From: marius at pov.lt (Marius Gedminas)
Date: Thu, 26 Jun 2008 23:45:12 +0300
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <4863E51D.4010708@mail.utexas.edu>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
	<4863E51D.4010708@mail.utexas.edu>
Message-ID: <20080626204512.GA11719@fridge.pov.lt>

On Thu, Jun 26, 2008 at 01:51:09PM -0500, Chris Galvan wrote:
> I was hoping to have another sprint this weekend to continue our work
> on adding tests to setuptools, but we haven't received any feedback on
> the work we've done so far yet.  We would like to get some feedback
> from others, especially Phillip, on the work we've done so far before
> continuing to work on the tests :)

The knowledge that someone is writing tests for a very important piece
of infrastructure that I plan to use more and more heavily in the future
filled me with joy.

> >It is a copy of the current setuptools trunk, you can get it with bzr:
> >
> >bzr branch lp:~tziade/setuptools-test/main

I get

  bzr: ERROR: Not a branch:
  "http://bazaar.launchpad.net/~tziade/setuptools-test/main/".

but that's probably because it's bzr 1.3.1 from Ubuntu Hardy.  I'll try
with bzr 1.5.

Marius Gedminas
-- 
I saw `cout' being shifted "Hello world" times to the left and stopped right
there!!
        -- Steve Gonedes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080626/ee11dba3/attachment.pgp>

From marius at pov.lt  Thu Jun 26 22:54:16 2008
From: marius at pov.lt (Marius Gedminas)
Date: Thu, 26 Jun 2008 23:54:16 +0300
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <20080626204512.GA11719@fridge.pov.lt>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
	<4863E51D.4010708@mail.utexas.edu>
	<20080626204512.GA11719@fridge.pov.lt>
Message-ID: <20080626205416.GB11719@fridge.pov.lt>

On Thu, Jun 26, 2008 at 11:45:12PM +0300, Marius Gedminas wrote:
> > >It is a copy of the current setuptools trunk, you can get it with bzr:
> > >
> > >bzr branch lp:~tziade/setuptools-test/main
> 
> I get
> 
>   bzr: ERROR: Not a branch:
>   "http://bazaar.launchpad.net/~tziade/setuptools-test/main/".
> 
> but that's probably because it's bzr 1.3.1 from Ubuntu Hardy.  I'll try
> with bzr 1.5.

Same error with bzr 1.5, but I finally found the right URL:

  bzr branch lp:~setuptools/setuptools-test/main

Now, how do I run the test suite?  I see no scripts with suggestive
names (such as test.py or runtests.py), setup.py test says there's no
such command, nosetests aborts with a mysterious TypeError deep in its
internals.

Marius Gedminas
-- 
Perl is not a programming language, it's a natural language that
computers understand.

Better than people, for the most part.
		-- Steve Simmons
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080626/eb6b8aa7/attachment.pgp>

From marius at pov.lt  Thu Jun 26 22:57:06 2008
From: marius at pov.lt (Marius Gedminas)
Date: Thu, 26 Jun 2008 23:57:06 +0300
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <20080626205416.GB11719@fridge.pov.lt>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
	<4863E51D.4010708@mail.utexas.edu>
	<20080626204512.GA11719@fridge.pov.lt>
	<20080626205416.GB11719@fridge.pov.lt>
Message-ID: <20080626205706.GC11719@fridge.pov.lt>

On Thu, Jun 26, 2008 at 11:54:16PM +0300, Marius Gedminas wrote:
> Same error with bzr 1.5, but I finally found the right URL:
> 
>   bzr branch lp:~setuptools/setuptools-test/main
> 
> Now, how do I run the test suite?  I see no scripts with suggestive
> names (such as test.py or runtests.py), setup.py test says there's no
> such command, nosetests aborts with a mysterious TypeError deep in its
> internals.

I tried ./setup.py test again, and it worked.  Apparently it needs
python-setuptools installed in my system Python, which I got as a side
effect of apt-get installing python-nose.

All 55 tests pass here.

Marius Gedminas
-- 
(mental note: stop installing red hat. everytime i do so, it takes ages to fix
my system again.)
                -- from the sig of Martin H?gman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080626/e1978647/attachment.pgp>

From cgalvan at mail.utexas.edu  Thu Jun 26 23:30:43 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Thu, 26 Jun 2008 16:30:43 -0500
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <20080626204512.GA11719@fridge.pov.lt>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>	<4863E51D.4010708@mail.utexas.edu>
	<20080626204512.GA11719@fridge.pov.lt>
Message-ID: <48640A83.2050802@mail.utexas.edu>

Marius Gedminas wrote:
> The knowledge that someone is writing tests for a very important piece
> of infrastructure that I plan to use more and more heavily in the future
> filled me with joy.
>   
I'm glad you feel that way :)
> I get
>
>   bzr: ERROR: Not a branch:
>   "http://bazaar.launchpad.net/~tziade/setuptools-test/main/".
>
> but that's probably because it's bzr 1.3.1 from Ubuntu Hardy.  I'll try
> with bzr 1.5.
>
> Marius Gedminas
>   
You are getting that error because that link is out-dated.  The original 
branch was under Tarek's launchpad directory,
but we ended up moving it to a setuptools group so that it would be 
easier to give people access to the branch.  Here is the link
to the current branch:

bzr branch lp:~setuptools/setuptools-test/main

Let me know if you have any problems with that link :)

-- Chris Galvan


From zooko at zooko.com  Fri Jun 27 20:48:36 2008
From: zooko at zooko.com (zooko)
Date: Fri, 27 Jun 2008 11:48:36 -0700
Subject: [Distutils] patches for stdeb: autodetect Debian dependencies
Message-ID: <9CEEF99C-409F-474E-ADBD-CF9907CF8D7F@zooko.com>

Folks:

Thanks for stdeb!  I'm using stdeb to produce debian packages for a  
few Python projects -- zfec [1], pycryptopp [2], pyutil [3], and  
argparse [4].  It works nicely.

I intend to use it in the future to produce debian packages for  
allmydata.org Tahoe, the Least-Authority Filesystem [5].

Along the way I added this feature to stdeb: use apt-file to discover  
which debian package(s) provide $DISTNAME.egg-info of the required  
version number, and automatically produce debian metadata showing  
that the new debian package depends on those debian packages.  For  
this to work requires that you have the "apt-file" command available  
and that you have run "apt-file update" in order to acquire the apt- 
file database.  Please see the patch for details.

With this patch, there is no "manual intervention" required to  
produce a good Debian package from a good Python package (for these  
five projects that I'm using it on).  I just run stdeb then run the  
debian build-package command and then I'm done.  We are going to  
script our buildbot to automatically do this whenever a new patch is  
committed to revision control and the unit tests pass.

This is really cool!  Stdeb is almost mature enough that every well- 
packaged Python package can automatically be converted into a well- 
packaged Debian package!

I also ported stdeb to Python 2.4, set zip_ok=False so that it could  
install on Ubuntu dapper, and made one tiny clean-up that was  
suggested by lintian.  The patch is appended.

Thanks!

Regards,

Zooko

[1] http://allmydata.org/trac/zfec
[2] http://allmydata.org/trac/pycryptopp
[3] http://allmydata.org/trac/pyutil
[4] http://argparse.python-hosting.com/
[5] http://allmydata.org

Fri Jun 27 11:38:23 MST 2008  zooko at zooko.com
   * remove print statements used for debugging

Thu Jun 12 10:41:50 MST 2008  zooko at zooko.com
   * include an implementation of check_call so that this will work  
with Python 2.4

Thu Jun 12 10:40:36 MST 2008  zooko at zooko.com
   * setup.cfg: zip_ok = False
   Zipping your eggs causes various problems.  I have seen about four  
or five such problems.  I just now added one to the list --
  installing stdeb with "./setup.py install" when there is already a  
version of stdeb installed fails on Ubuntu dapper (setuptool
s-0.6a9) unless you set zip_ok = False.


Tue May 27 11:16:05 MST 2008  zooko at zooko.com
   * automatically produce Debian "Depends:" metadata from setuptools  
"install_requires" metadata

Wed May 21 15:49:10 MST 2008  zooko at zooko.com
   * don't build-depend on "-1" of python-setuptools

   lintian says that it is a bad idea to depend on "-1" versions.


Thu May 15 16:03:04 MST 2008  zooko at zooko.com
   * more details in exception message

diff -u -r --exclude=_darcs dw/setup.cfg autodeps/setup.cfg
--- dw/setup.cfg	2008-05-15 15:31:42.000000000 -0700
+++ autodeps/setup.cfg	2008-06-27 11:35:40.000000000 -0700
@@ -1,3 +1,6 @@
  [egg_info]
  tag_build = .dev
  tag_svn_revision = 1
+
+[easy_install]
+zip_ok = False
diff -u -r --exclude=_darcs dw/setup.py autodeps/setup.py
--- dw/setup.py	2008-05-15 15:32:13.000000000 -0700
+++ autodeps/setup.py	2008-06-27 11:39:26.000000000 -0700
@@ -1,5 +1,3 @@
-#!/usr/bin/env python
-
  import setuptools
  from setuptools import setup

diff -u -r --exclude=_darcs dw/stdeb/command/sdist_dsc.py autodeps/ 
stdeb/command/sdist_dsc.py
--- dw/stdeb/command/sdist_dsc.py	2008-05-21 06:33:07.000000000 -0700
+++ autodeps/stdeb/command/sdist_dsc.py	2008-06-27 11:35:40.000000000  
-0700
@@ -80,6 +80,10 @@
          if self.extra_cfg_file is not None:
              cfg_files.append(self.extra_cfg_file)

+        try:
+            install_requires = open(os.path.join 
(egg_info_dirname,'requires.txt'),'rU').read()
+        except EnvironmentError:
+            install_requires = ()
          debinfo = DebianInfo(
              cfg_files=cfg_files,
              module_name = module_name,
@@ -93,6 +97,8 @@
              long_description =  
self.distribution.get_long_description(),
              patch_file = self.patch_file,
              patch_level = self.patch_level,
+            install_requires = install_requires,
+            setup_requires = (), # XXX How do we get the  
setup_requires?
          )
          if debinfo.patch_file != '' and self.patch_already_applied:
              raise RuntimeError('A patch was already applied, but  
another '
diff -u -r --exclude=_darcs dw/stdeb/util.py autodeps/stdeb/util.py
--- dw/stdeb/util.py	2008-05-21 06:33:07.000000000 -0700
+++ autodeps/stdeb/util.py	2008-06-27 11:39:00.000000000 -0700
@@ -1,11 +1,12 @@
  #
  # This module contains most of the code of stdeb.
  #
-import sys, os, shutil, sets, select
+import re, sys, os, shutil, sets, select
  import ConfigParser
  import subprocess
  import tempfile
  import stdeb
+import pkg_resources
  from stdeb import log, __version__ as __stdeb_version__

  __all__ = ['DebianInfo','build_dsc','expand_tarball','expand_zip',
@@ -13,6 +14,15 @@
             'apply_patch','repack_tarball_with_debianized_dirname',
             'expand_sdist_file']

+import exceptions
+class CalledProcessError(exceptions.Exception): pass
+
+def check_call(*popenargs, **kwargs):
+    retcode = subprocess.call(*popenargs, **kwargs)
+    if retcode == 0:
+        return
+    raise CalledProcessError(retcode)
+
  stdeb_cmdline_opts = [
      ('dist-dir=', 'd',
       "directory to put final built distributions in  
(default='deb_dist')"),
@@ -48,7 +58,7 @@
  def process_command(args, cwd=None):
      if not isinstance(args, (list, tuple)):
          raise RuntimeError, "args passed must be in a list"
-    subprocess.check_call(args, cwd=cwd)
+    check_call(args, cwd=cwd)

  def recursive_hardlink(src,dst):
      dst = os.path.abspath(dst)
@@ -111,6 +121,80 @@
      result = cmd.stdout.read().strip()
      return result

+def get_deb_depends_from_setuptools_requires(requirements):
+    depends = [] # This will be the return value from this function.
+
+    requirements = list(pkg_resources.parse_requirements(requirements))
+    if not requirements:
+        return depends
+
+    # Ask apt-file for any packages which have a .egg-info file by  
these names.
+    # Note that apt-file appears to think that some packages e.g.  
setuptools itself have "foo.egg-info/BLAH" files but not a "foo.egg- 
info" directory.
+
+    egginfore="((%s)(?:-[^/]+)?(?:-py[0-9]\.[0-9.]+)?\.egg-info)" %  
'|'.join(req.project_name for req in requirements)
+
+    args = ["apt-file", "search", "--ignore-case", "--regexp",  
egginfore]
+    try:
+        cmd = subprocess.Popen(args, stdin=subprocess.PIPE,  
stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
+    except Exception, le:
+        log.error('ERROR running: %s', ' '.join(args))
+        raise RuntimeError('exception %s from subprocess %s' %  
(le,args))
+    returncode = cmd.wait()
+    if returncode:
+        log.error('ERROR running: %s', ' '.join(args))
+        raise RuntimeError('returncode %d from subprocess %s' %  
(returncode, args))
+
+    inlines = cmd.stdout.readlines()
+
+    dd = {} # {pydistname: {pydist: set(debpackagename)}}
+    E=re.compile(egginfore, re.I)
+    D=re.compile("^([^:]*):", re.I)
+    eggsndebs = set()
+    for l in inlines:
+        if l:
+            emo = E.search(l)
+            assert emo, l
+            dmo = D.search(l)
+            assert dmo, l
+            eggsndebs.add((emo.group(1), dmo.group(1)))
+
+    for (egginfo, debname) in eggsndebs:
+        pydist = pkg_resources.Distribution.from_filename(egginfo)
+        try:
+            dd.setdefault(pydist.project_name.lower(), {}).setdefault 
(pydist, set()).add(debname)
+        except ValueError, le:
+            log.warn("I got an error parsing a .egg-info file named  
\"%s\" from Debian package \"%s\" as a pkg_resources Distribution: % 
s" % (egginfo, debname, le,))
+            pass
+
+    # Now for each requirement, see if a Debian package satisfies it.
+    ops = {'<':'<<','>':'>>','==':'=','<=':'<=','>=':'>='}
+    for req in requirements:
+        reqname = req.project_name.lower()
+        gooddebs = set()
+        for pydist, debs in dd.get(reqname, {}).iteritems():
+            if pydist in req:
+                # log.info("I found Debian packages \"%s\" which  
provides Python package \"%s\", version \"%s\", which satisfies our  
version requirements: \"%s\"" % (', '.join(debs), req.project_name,  
ver, req))
+                gooddebs |= (debs)
+            else:
+                log.info("I found Debian packages \"%s\" which  
provides Python package \"%s\", version \"%s\", which does not  
satisfy our version requirements: \"%s\" -- ignoring." % (', '.join 
(debs), req.project_name, ver, req))
+        if not gooddebs:
+            log.warn("I found no Debian package which provides the  
required Python package \"%s\" with version requirements \"%s\".   
Guessing blindly that the name \"python-%s\" will be it, and that the  
Python package version number requirements will apply to the Debian  
package." % (req.project_name, req.specs, reqname))
+            gooddebs.add("python-" + reqname)
+        elif len(gooddebs) == 1:
+            log.info("I found a Debian package which provides the  
require Python package.  Python package: \"%s\", Debian package: \"%s 
\";  adding Depends specifications for the following version(s): \"%s 
\"" % (req.project_name, tuple(gooddebs)[0], req.specs))
+        else:
+            log.warn("I found multiple Debian packages which provide  
the Python distribution required.  I'm listing them all as  
alternates.  Candidate debs which claim to provide the Python package  
\"%s\" are: \"%s\"" % (req.project_name, ', '.join(gooddebs),))
+
+        alts = []
+        for deb in gooddebs:
+            for spec in req.specs:
+                # Here we blithely assume that the Debian package  
versions are enough like the Python package versions that the  
requirement can be ported straight over...
+                alts.append("%s (%s %s)" % (deb, ops[spec[0]], spec 
[1]))
+
+        depends.append(' | '.join(alts))
+
+    return depends
+
  def make_tarball(tarball_fname,directory,cwd=None):
      "create a tarball from a directory"
      if tarball_fname.endswith('.gz'): opts = 'czf'
@@ -278,6 +362,8 @@
                   long_description=NotGiven,
                   patch_file=None,
                   patch_level=None,
+                 install_requires=None,
+                 setup_requires=None,
                   ):
          if cfg_files is NotGiven: raise ValueError("cfg_files must  
be supplied")
          if module_name is NotGiven: raise ValueError("module_name  
must be supplied")
@@ -337,7 +423,9 @@
              self.pycentral_showversions=current


-        build_deps = ['python-setuptools (>= 0.6b3-1)']
+        build_deps = ['python-setuptools (>= 0.6b3)']
+        build_deps.extend(get_deb_depends_from_setuptools_requires 
(setup_requires))
+
          depends = []

          depends.append('${python:Depends}')
@@ -386,6 +474,7 @@
              self.copy_files_lines += '\n\tcp %s %s'% 
(mime_desktop_file,dest_file)

          depends.extend(parse_vals(cfg,module_name,'Depends') )
+        depends.extend(get_deb_depends_from_setuptools_requires 
(install_requires))
          self.depends = ', '.join(depends)

          self.description = description


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: autodeps.patch.txt
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080627/d03dd853/attachment.txt>

From zooko at zooko.com  Fri Jun 27 20:58:21 2008
From: zooko at zooko.com (zooko)
Date: Fri, 27 Jun 2008 11:58:21 -0700
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <4863E51D.4010708@mail.utexas.edu>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
	<4863E51D.4010708@mail.utexas.edu>
Message-ID: <4A5ED41D-81D2-4E19-AB20-236C895C4AE7@zooko.com>

On Jun 26, 2008, at 11:51 AM, Chris Galvan wrote:

> I was hoping to have another sprint this weekend to continue our  
> work on adding
> tests to setuptools, but we haven't received any feedback on the  
> work we've done
> so far yet.  We would like to get some feedback from others,  
> especially Phillip, on
> the work we've done so far before continuing to work on the tests :)

Here's some feedback:

                  Way to go!!!

I'm so glad that you are writing automated tests for setuptools.   
Let's integrate your patches into the trunk as soon as possible (I  
guess that is blocked on PJE doing so or granting commit access to  
someone else who can do so), and let's write more tests, and let's  
set up a buildbot to automatically run all the tests on every checkin.

I could contribute a buildmaster and administration thereof.

Regards,

Zooko

From lists at zopyx.com  Sun Jun 29 20:17:45 2008
From: lists at zopyx.com (Andreas Jung)
Date: Sun, 29 Jun 2008 20:17:45 +0200
Subject: [Distutils] bug in setuptools 0.6c8/undefined log in
	entries_finder()/sdist.py
Message-ID: <6D4923D1C0305F16142DE7AA@[192.168.0.24]>

sdist.py contains this:

def entries_finder(dirname, filename):
    f = open(filename,'rU')
    data = f.read()
    f.close()
    if data.startswith('8'):    # subversion 1.4
        for record in map(str.splitlines, data.split('\n\x0c\n')[1:]):
            if not record or len(record)>=6 and record[5]=="delete":
                continue    # skip deleted
            yield joinpath(dirname, record[0])
    elif data.startswith('<?xml'):
        for match in entries_pattern.finditer(data):
            yield joinpath(dirname,unescape(match.group(1)))
    else:
        log.warn("unrecognized .svn/entries format in %s", dirname)


However 'log' is undefined.

Andreas


-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 T?bingen - Germany
Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376
Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
Gesch?ftsf?hrer/Gesellschafter: ZOPYX Limited, Birmingham, UK
------------------------------------------------------------------------
E-Publishing, Python, Zope & Plone development, Consulting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080629/f0e4522f/attachment.pgp>

From pje at telecommunity.com  Sun Jun 29 21:48:01 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 29 Jun 2008 15:48:01 -0400
Subject: [Distutils] bug in setuptools 0.6c8/undefined log in
 entries_finder()/sdist.py
In-Reply-To: <6D4923D1C0305F16142DE7AA@[192.168.0.24]>
References: <6D4923D1C0305F16142DE7AA@[192.168.0.24]>
Message-ID: <20080629194724.94DF53A408E@sparrow.telecommunity.com>

At 08:17 PM 6/29/2008 +0200, Andreas Jung wrote:
>sdist.py contains this:
>
>[snip outdated version]
>
>However 'log' is undefined.

This was fixed four months ago...  just not in a released version.

http://svn.python.org/view/sandbox/branches/setuptools-0.6/setuptools/command/sdist.py?rev=60849&r1=52009&r2=60849

http://svn.python.org/view/sandbox/trunk/setuptools/setuptools/command/sdist.py?rev=60846&view=diff&r1=60846&r2=60845&p1=sandbox/trunk/setuptools/setuptools/command/sdist.py&p2=/sandbox/trunk/setuptools/setuptools/command/sdist.py

You can get the updated version with easy_install setuptools==dev 
(trunk) or setuptools==dev06 (branch). 


From ziade.tarek at gmail.com  Sun Jun 29 23:01:15 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 29 Jun 2008 23:01:15 +0200
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <4863E51D.4010708@mail.utexas.edu>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
	<4863E51D.4010708@mail.utexas.edu>
Message-ID: <94bdd2610806291401l489a9b2fqce7e95e87e36af59@mail.gmail.com>

On Thu, Jun 26, 2008 at 8:51 PM, Chris Galvan <cgalvan at mail.utexas.edu>
wrote:

> Hello,
>
> I was hoping to have another sprint this weekend to continue our work on
> adding
> tests to setuptools, but we haven't received any feedback on the work we've
> done
> so far yet.  We would like to get some feedback from others, especially
> Phillip, on
> the work we've done so far before continuing to work on the tests :)


+1

I was hoping to have some feedback as well on this topic by Phillip, since
he asked
for tests in setuptools.

I hope we didn't work for nothing :D

Tarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080629/9615d7db/attachment.htm>

From ziade.tarek at gmail.com  Sun Jun 29 23:09:47 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 29 Jun 2008 23:09:47 +0200
Subject: [Distutils] setuptools "tests" sprint today
In-Reply-To: <20080626205706.GC11719@fridge.pov.lt>
References: <94bdd2610806220225g263840f4o9be5472191906d47@mail.gmail.com>
	<4863E51D.4010708@mail.utexas.edu>
	<20080626204512.GA11719@fridge.pov.lt>
	<20080626205416.GB11719@fridge.pov.lt>
	<20080626205706.GC11719@fridge.pov.lt>
Message-ID: <94bdd2610806291409p2d3eb5dasf90f76b4d6bb8fef@mail.gmail.com>

On Thu, Jun 26, 2008 at 10:57 PM, Marius Gedminas <marius at pov.lt> wrote:

> On Thu, Jun 26, 2008 at 11:54:16PM +0300, Marius Gedminas wrote:
> > Same error with bzr 1.5, but I finally found the right URL:
> >
> >   bzr branch lp:~setuptools/setuptools-test/main
> >
> > Now, how do I run the test suite?  I see no scripts with suggestive
> > names (such as test.py or runtests.py), setup.py test says there's no
> > such command, nosetests aborts with a mysterious TypeError deep in its
> > internals.
>
> I tried ./setup.py test again, and it worked.  Apparently it needs
> python-setuptools installed in my system Python, which I got as a side
> effect of apt-get installing python-nose.


A yes, there's a setup_requires metadata in setup.py that needs to be
uncommented
for tests to work.

I wonder if this could not be changed to a test_requires section, I'll try


>
> All 55 tests pass here.


Cool, thanks for the feedback



>
>
> Marius Gedminas
> --
> (mental note: stop installing red hat. everytime i do so, it takes ages to
> fix
> my system again.)
>                -- from the sig of Martin H?gman
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIZAKikVdEXeem148RAgT9AJ4qHcdh0nr8fAJBLrLKXimdSAdJ/gCdEOBg
> fdi27NSHc+FcplzHMDABFlo=
> =Frj/
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080629/550af547/attachment.htm>

From jaraco at jaraco.com  Mon Jun 30 02:06:14 2008
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Sun, 29 Jun 2008 18:06:14 -0600
Subject: [Distutils] ImportError running 'test' on namespace package -
	other package in namespace not found
In-Reply-To: <20080620124522.215D53A40D9@sparrow.telecommunity.com>
References: <750B64C66078B34D918257A1AC004DB20307EB@messiah.jaraco.com>
	<20080620124522.215D53A40D9@sparrow.telecommunity.com>
Message-ID: <750B64C66078B34D918257A1AC004DB203086B@messiah.jaraco.com>

Okay.  I narrowed the problem down and created a minimal test case.  I created 
two projects, myns.projA and myns.projB.  myns.projA is stock basic_namespace 
project with one module added.

First, I created myns.projA with the basic_namespace template from ZopeSkel:

> paster create -t basic_namespace
Selected and implied templates:
  zopeskel#basic_namespace  A project with a namespace package

Enter project name: myns.projA
Variables:
  egg:      myns.projA
  package:  mynsproja
  project:  myns.projA
Enter namespace_package (Namespace package (like plone)) ['plone']: myns
Enter package (The package contained namespace package (like example)) 
['example']: projA
... (rest are defaults)

Then I added a single module with a simple function

> cat > myns.projA\myns\projA\modA.py
def funcA():
  print "funcA called"
^D

myns.projB is another project created basically the same way, but they key to 
getting the bug to surface was to put the packages in a sub-directory... so I 
modified setup.py with the following parameters to setup:
      packages=find_packages('src'),
      package_dir={'': 'src'},
	test_suite='nose.collector',

And of course, I moved the myns directory to src/myns.  Note, this only had to 
happen for myns.projB.

Finally, I created a test directory and a file testBasic.py

> cat > test/testBasic.py
from myns.projA.modA import funcA
^D

Note, I could add a dependency from myns.projB on myns.projA, but it's not 
necessary for this demonstration.

Then, I either setup myns.projA with either "install" or "develop" so that 
it's visible to the Python installation.

Thereafter, if I try to run "setup.py test" on myns.projB, I get the 
ImportError.  See error.txt, attached, for the transcript.  I've also attached 
the two test packages as described.  I notice now that the error appears to 
only occur when nose.collector is used... and when the package_dir of the 
child package is overridden.  Perhaps this needs to go to the nose project and 
instead of the distutils project.

Please advise on what I might do next to help resolve this issue.  Obviously I 
could restructure my projects to avoid the problem, but I would much rather 
help resolve the problem, as I suspect it may affect other users' deployments 
as well.

Much obliged,
Jason

-----Original Message-----
From: Phillip J. Eby [mailto:pje at telecommunity.com]
Sent: Friday, 20 June, 2008 08:46
To: Jason R. Coombs; distutils-sig at python.org
Subject: Re: [Distutils] ImportError running 'test' on namespace package - 
other package in namespace not found

At 08:07 PM 6/18/2008 -0600, Jason R. Coombs wrote:
>If there's not something obvious I should be doing differently, I'm happy to
>put together a minimal test case that reproduces the problem.

Please do.  Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: myns.zip
Type: application/x-zip-compressed
Size: 15371 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080629/58e79b8c/attachment-0002.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: error.txt
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080629/58e79b8c/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6580 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080629/58e79b8c/attachment-0003.bin>

From jaraco at jaraco.com  Mon Jun 30 02:22:59 2008
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Sun, 29 Jun 2008 18:22:59 -0600
Subject: [Distutils] ImportError running 'test' on namespace package -
	other package in namespace not found
In-Reply-To: <20080620124522.215D53A40D9@sparrow.telecommunity.com>
References: <750B64C66078B34D918257A1AC004DB20307EB@messiah.jaraco.com>
	<20080620124522.215D53A40D9@sparrow.telecommunity.com>
Message-ID: <750B64C66078B34D918257A1AC004DB203086C@messiah.jaraco.com>

It seems that error messages are stripped... so I've uploaded the test case to 
here: http://www.filedropper.com/myns and below is the error message I 
mentioned was attached previously.

Jason

PS C:\Users\jaraco\projects\distutils_namespace\myns.projB> ./setup test
running test
running egg_info
creating src\myns.projB.egg-info
writing requirements to src\myns.projB.egg-info\requires.txt
writing src\myns.projB.egg-info\PKG-INFO
writing namespace_packages to src\myns.projB.egg-info\namespace_packages.txt
writing top-level names to src\myns.projB.egg-info\top_level.txt
writing dependency_links to src\myns.projB.egg-info\dependency_links.txt
writing entry points to src\myns.projB.egg-info\entry_points.txt
writing manifest file 'src\myns.projB.egg-info\SOURCES.txt'
reading manifest file 'src\myns.projB.egg-info\SOURCES.txt'
writing manifest file 'src\myns.projB.egg-info\SOURCES.txt'
running build_ext
Failure: ImportError (No module named projA.modA) ... ERROR

======================================================================
ERROR: Failure: ImportError (No module named projA.modA)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\program files 
(x86)\python\lib\site-packages\nose-0.10.3-py2.5.egg\nose\loader.py", line 
364, in loadTestsFro
mName
    addr.filename, addr.module)
  File "c:\program files 
(x86)\python\lib\site-packages\nose-0.10.3-py2.5.egg\nose\importer.py", line 
39, in importFromP
ath
    return self.importFromDir(dir_path, fqname)
  File "c:\program files 
(x86)\python\lib\site-packages\nose-0.10.3-py2.5.egg\nose\importer.py", line 
84, in importFromD
ir
    mod = load_module(part_fqname, fh, filename, desc)
  File 
"C:\Users\jaraco\projects\distutils_namespace\myns.projB\test\testBasic.py", 
line 1, in <module>
    from myns.projA.modA import funcA
ImportError: No module named projA.modA

----------------------------------------------------------------------
Ran 1 test in 0.014s

FAILED (errors=1)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6580 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080629/2f0ca9a2/attachment.bin>

From pje at telecommunity.com  Mon Jun 30 03:20:46 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 29 Jun 2008 21:20:46 -0400
Subject: [Distutils] ImportError running 'test' on namespace package -
 other package in namespace not found
In-Reply-To: <750B64C66078B34D918257A1AC004DB203086B@messiah.jaraco.com>
References: <750B64C66078B34D918257A1AC004DB20307EB@messiah.jaraco.com>
	<20080620124522.215D53A40D9@sparrow.telecommunity.com>
	<750B64C66078B34D918257A1AC004DB203086B@messiah.jaraco.com>
Message-ID: <20080630012008.5FA7E3A408E@sparrow.telecommunity.com>

At 06:06 PM 6/29/2008 -0600, Jason R. Coombs wrote:
>Note, I could add a dependency from myns.projB on myns.projA, but it's not
>necessary for this demonstration.
>
>Then, I either setup myns.projA with either "install" or "develop" so that
>it's visible to the Python installation.
>
>Thereafter, if I try to run "setup.py test" on myns.projB, I get the
>ImportError.  See error.txt, attached, for the transcript.  I've 
>also attached
>the two test packages as described.  I notice now that the error appears to
>only occur when nose.collector is used... and when the package_dir of the
>child package is overridden.  Perhaps this needs to go to the nose 
>project and
>instead of the distutils project.
>
>Please advise on what I might do next to help resolve this 
>issue.  Obviously I
>could restructure my projects to avoid the problem, but I would much rather
>help resolve the problem, as I suspect it may affect other users' deployments
>as well.

I can't reproduce this using the archive you uploaded.  After running 
develop on projA, I ran test on projB and got an error message about 
nose not being available, so I added tests_require="nose" to projB, 
and then I got a run that said zero tests ran.


From strawman at astraw.com  Mon Jun 30 07:26:15 2008
From: strawman at astraw.com (Andrew Straw)
Date: Sun, 29 Jun 2008 22:26:15 -0700
Subject: [Distutils] patches for stdeb: autodetect Debian dependencies
In-Reply-To: <9CEEF99C-409F-474E-ADBD-CF9907CF8D7F@zooko.com>
References: <9CEEF99C-409F-474E-ADBD-CF9907CF8D7F@zooko.com>
Message-ID: <48686E77.9000708@astraw.com>

Dear zooko,

Thanks for the patches. The way you implemented automatic finding of
dependencies is a really clever idea. I've created a bzr branch for it at
http://code.launchpad.net/~astraw/stdeb/autofind-depends where I've been
getting it shape for the mainline. This will probably continue with some
more extensive testing on my end over the coming days and then I
anticipate merging it.

The new branch passes my (way too small) test suite (test.sh which is
next to setup.py). If you have any use cases you could stick in test.sh,
that would help me make sure I don't break anything for you.

I'm initially going to make the auto-dependency finding optional with a
default to off, but I'll spend some time with various projects around
here to see how it goes...

(I've also hacked down some of your lines closer to 80 characters wide
-- you must have a wide monitor!)

Anyhow, thanks for the patch...

-Andrew

zooko wrote:
> Folks:
>
> Thanks for stdeb!  I'm using stdeb to produce debian packages for a
> few Python projects -- zfec [1], pycryptopp [2], pyutil [3], and
> argparse [4].  It works nicely.
>
> I intend to use it in the future to produce debian packages for
> allmydata.org Tahoe, the Least-Authority Filesystem [5].
>
> Along the way I added this feature to stdeb: use apt-file to discover
> which debian package(s) provide $DISTNAME.egg-info of the required
> version number, and automatically produce debian metadata showing that
> the new debian package depends on those debian packages.  For this to
> work requires that you have the "apt-file" command available and that
> you have run "apt-file update" in order to acquire the apt-file
> database.  Please see the patch for details.
>
> With this patch, there is no "manual intervention" required to produce
> a good Debian package from a good Python package (for these five
> projects that I'm using it on).  I just run stdeb then run the debian
> build-package command and then I'm done.  We are going to script our
> buildbot to automatically do this whenever a new patch is committed to
> revision control and the unit tests pass.
>
> This is really cool!  Stdeb is almost mature enough that every
> well-packaged Python package can automatically be converted into a
> well-packaged Debian package!
>
> I also ported stdeb to Python 2.4, set zip_ok=False so that it could
> install on Ubuntu dapper, and made one tiny clean-up that was
> suggested by lintian.  The patch is appended.
>
> Thanks!
>
> Regards,
>
> Zooko
>
> [1] http://allmydata.org/trac/zfec
> [2] http://allmydata.org/trac/pycryptopp
> [3] http://allmydata.org/trac/pyutil
> [4] http://argparse.python-hosting.com/
> [5] http://allmydata.org
>
> Fri Jun 27 11:38:23 MST 2008  zooko at zooko.com
>   * remove print statements used for debugging
>
> Thu Jun 12 10:41:50 MST 2008  zooko at zooko.com
>   * include an implementation of check_call so that this will work
> with Python 2.4
>
> Thu Jun 12 10:40:36 MST 2008  zooko at zooko.com
>   * setup.cfg: zip_ok = False
>   Zipping your eggs causes various problems.  I have seen about four
> or five such problems.  I just now added one to the list --
>  installing stdeb with "./setup.py install" when there is already a
> version of stdeb installed fails on Ubuntu dapper (setuptool
> s-0.6a9) unless you set zip_ok = False.
>
>
> Tue May 27 11:16:05 MST 2008  zooko at zooko.com
>   * automatically produce Debian "Depends:" metadata from setuptools
> "install_requires" metadata
>
> Wed May 21 15:49:10 MST 2008  zooko at zooko.com
>   * don't build-depend on "-1" of python-setuptools
>
>   lintian says that it is a bad idea to depend on "-1" versions.
>
>
> Thu May 15 16:03:04 MST 2008  zooko at zooko.com
>   * more details in exception message
>
> diff -u -r --exclude=_darcs dw/setup.cfg autodeps/setup.cfg
> --- dw/setup.cfg    2008-05-15 15:31:42.000000000 -0700
> +++ autodeps/setup.cfg    2008-06-27 11:35:40.000000000 -0700
> @@ -1,3 +1,6 @@
>  [egg_info]
>  tag_build = .dev
>  tag_svn_revision = 1
> +
> +[easy_install]
> +zip_ok = False
> diff -u -r --exclude=_darcs dw/setup.py autodeps/setup.py
> --- dw/setup.py    2008-05-15 15:32:13.000000000 -0700
> +++ autodeps/setup.py    2008-06-27 11:39:26.000000000 -0700
> @@ -1,5 +1,3 @@
> -#!/usr/bin/env python
> -
>  import setuptools
>  from setuptools import setup
>
> diff -u -r --exclude=_darcs dw/stdeb/command/sdist_dsc.py
> autodeps/stdeb/command/sdist_dsc.py
> --- dw/stdeb/command/sdist_dsc.py    2008-05-21 06:33:07.000000000 -0700
> +++ autodeps/stdeb/command/sdist_dsc.py    2008-06-27
> 11:35:40.000000000 -0700
> @@ -80,6 +80,10 @@
>          if self.extra_cfg_file is not None:
>              cfg_files.append(self.extra_cfg_file)
>
> +        try:
> +            install_requires =
> open(os.path.join(egg_info_dirname,'requires.txt'),'rU').read()
> +        except EnvironmentError:
> +            install_requires = ()
>          debinfo = DebianInfo(
>              cfg_files=cfg_files,
>              module_name = module_name,
> @@ -93,6 +97,8 @@
>              long_description = self.distribution.get_long_description(),
>              patch_file = self.patch_file,
>              patch_level = self.patch_level,
> +            install_requires = install_requires,
> +            setup_requires = (), # XXX How do we get the setup_requires?
>          )
>          if debinfo.patch_file != '' and self.patch_already_applied:
>              raise RuntimeError('A patch was already applied, but
> another '
> diff -u -r --exclude=_darcs dw/stdeb/util.py autodeps/stdeb/util.py
> --- dw/stdeb/util.py    2008-05-21 06:33:07.000000000 -0700
> +++ autodeps/stdeb/util.py    2008-06-27 11:39:00.000000000 -0700
> @@ -1,11 +1,12 @@
>  #
>  # This module contains most of the code of stdeb.
>  #
> -import sys, os, shutil, sets, select
> +import re, sys, os, shutil, sets, select
>  import ConfigParser
>  import subprocess
>  import tempfile
>  import stdeb
> +import pkg_resources
>  from stdeb import log, __version__ as __stdeb_version__
>
>  __all__ = ['DebianInfo','build_dsc','expand_tarball','expand_zip',
> @@ -13,6 +14,15 @@
>             'apply_patch','repack_tarball_with_debianized_dirname',
>             'expand_sdist_file']
>
> +import exceptions
> +class CalledProcessError(exceptions.Exception): pass
> +
> +def check_call(*popenargs, **kwargs):
> +    retcode = subprocess.call(*popenargs, **kwargs)
> +    if retcode == 0:
> +        return
> +    raise CalledProcessError(retcode)
> +
>  stdeb_cmdline_opts = [
>      ('dist-dir=', 'd',
>       "directory to put final built distributions in
> (default='deb_dist')"),
> @@ -48,7 +58,7 @@
>  def process_command(args, cwd=None):
>      if not isinstance(args, (list, tuple)):
>          raise RuntimeError, "args passed must be in a list"
> -    subprocess.check_call(args, cwd=cwd)
> +    check_call(args, cwd=cwd)
>
>  def recursive_hardlink(src,dst):
>      dst = os.path.abspath(dst)
> @@ -111,6 +121,80 @@
>      result = cmd.stdout.read().strip()
>      return result
>
> +def get_deb_depends_from_setuptools_requires(requirements):
> +    depends = [] # This will be the return value from this function.
> +
> +    requirements = list(pkg_resources.parse_requirements(requirements))
> +    if not requirements:
> +        return depends
> +
> +    # Ask apt-file for any packages which have a .egg-info file by
> these names.
> +    # Note that apt-file appears to think that some packages e.g.
> setuptools itself have "foo.egg-info/BLAH" files but not a
> "foo.egg-info" directory.
> +
> +    egginfore="((%s)(?:-[^/]+)?(?:-py[0-9]\.[0-9.]+)?\.egg-info)" %
> '|'.join(req.project_name for req in requirements)
> +
> +    args = ["apt-file", "search", "--ignore-case", "--regexp",
> egginfore]
> +    try:
> +        cmd = subprocess.Popen(args, stdin=subprocess.PIPE,
> stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
> +    except Exception, le:
> +        log.error('ERROR running: %s', ' '.join(args))
> +        raise RuntimeError('exception %s from subprocess %s' %
> (le,args))
> +    returncode = cmd.wait()
> +    if returncode:
> +        log.error('ERROR running: %s', ' '.join(args))
> +        raise RuntimeError('returncode %d from subprocess %s' %
> (returncode, args))
> +
> +    inlines = cmd.stdout.readlines()
> +
> +    dd = {} # {pydistname: {pydist: set(debpackagename)}}
> +    E=re.compile(egginfore, re.I)
> +    D=re.compile("^([^:]*):", re.I)
> +    eggsndebs = set()
> +    for l in inlines:
> +        if l:
> +            emo = E.search(l)
> +            assert emo, l
> +            dmo = D.search(l)
> +            assert dmo, l
> +            eggsndebs.add((emo.group(1), dmo.group(1)))
> +
> +    for (egginfo, debname) in eggsndebs:
> +        pydist = pkg_resources.Distribution.from_filename(egginfo)
> +        try:
> +            dd.setdefault(pydist.project_name.lower(),
> {}).setdefault(pydist, set()).add(debname)
> +        except ValueError, le:
> +            log.warn("I got an error parsing a .egg-info file named
> \"%s\" from Debian package \"%s\" as a pkg_resources Distribution: %s"
> % (egginfo, debname, le,))
> +            pass
> +
> +    # Now for each requirement, see if a Debian package satisfies it.
> +    ops = {'<':'<<','>':'>>','==':'=','<=':'<=','>=':'>='}
> +    for req in requirements:
> +        reqname = req.project_name.lower()
> +        gooddebs = set()
> +        for pydist, debs in dd.get(reqname, {}).iteritems():
> +            if pydist in req:
> +                # log.info("I found Debian packages \"%s\" which
> provides Python package \"%s\", version \"%s\", which satisfies our
> version requirements: \"%s\"" % (', '.join(debs), req.project_name,
> ver, req))
> +                gooddebs |= (debs)
> +            else:
> +                log.info("I found Debian packages \"%s\" which
> provides Python package \"%s\", version \"%s\", which does not satisfy
> our version requirements: \"%s\" -- ignoring." % (', '.join(debs),
> req.project_name, ver, req))
> +        if not gooddebs:
> +            log.warn("I found no Debian package which provides the
> required Python package \"%s\" with version requirements \"%s\". 
> Guessing blindly that the name \"python-%s\" will be it, and that the
> Python package version number requirements will apply to the Debian
> package." % (req.project_name, req.specs, reqname))
> +            gooddebs.add("python-" + reqname)
> +        elif len(gooddebs) == 1:
> +            log.info("I found a Debian package which provides the
> require Python package.  Python package: \"%s\", Debian package:
> \"%s\";  adding Depends specifications for the following version(s):
> \"%s\"" % (req.project_name, tuple(gooddebs)[0], req.specs))
> +        else:
> +            log.warn("I found multiple Debian packages which provide
> the Python distribution required.  I'm listing them all as
> alternates.  Candidate debs which claim to provide the Python package
> \"%s\" are: \"%s\"" % (req.project_name, ', '.join(gooddebs),))
> +
> +        alts = []
> +        for deb in gooddebs:
> +            for spec in req.specs:
> +                # Here we blithely assume that the Debian package
> versions are enough like the Python package versions that the
> requirement can be ported straight over...
> +                alts.append("%s (%s %s)" % (deb, ops[spec[0]], spec[1]))
> +
> +        depends.append(' | '.join(alts))
> +
> +    return depends
> +
>  def make_tarball(tarball_fname,directory,cwd=None):
>      "create a tarball from a directory"
>      if tarball_fname.endswith('.gz'): opts = 'czf'
> @@ -278,6 +362,8 @@
>                   long_description=NotGiven,
>                   patch_file=None,
>                   patch_level=None,
> +                 install_requires=None,
> +                 setup_requires=None,
>                   ):
>          if cfg_files is NotGiven: raise ValueError("cfg_files must be
> supplied")
>          if module_name is NotGiven: raise ValueError("module_name
> must be supplied")
> @@ -337,7 +423,9 @@
>              self.pycentral_showversions=current
>
>
> -        build_deps = ['python-setuptools (>= 0.6b3-1)']
> +        build_deps = ['python-setuptools (>= 0.6b3)']
> +       
> build_deps.extend(get_deb_depends_from_setuptools_requires(setup_requires))
>
> +
>          depends = []
>
>          depends.append('${python:Depends}')
> @@ -386,6 +474,7 @@
>              self.copy_files_lines += '\n\tcp %s
> %s'%(mime_desktop_file,dest_file)
>
>          depends.extend(parse_vals(cfg,module_name,'Depends') )
> +       
> depends.extend(get_deb_depends_from_setuptools_requires(install_requires))
>
>          self.depends = ', '.join(depends)
>
>          self.description = description
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From plone at hannosch.info  Mon Jun 30 10:57:57 2008
From: plone at hannosch.info (Hanno Schlichting)
Date: Mon, 30 Jun 2008 10:57:57 +0200
Subject: [Distutils] zc.buildout 1.1?
Message-ID: <g4a76l$14n$1@ger.gmane.org>

Hi buildout-people,

I have noticed us slacking a bit on the proper release management side 
of buildout as of late. It seems we have chosen to use the 1.0.x 
releases for introducing new features which has led to at least one 
completely broken release already.

How do people feel about declaring the 1.0.x line as stable and 
maintenance only and do new feature work in a 1.1 release instead?

Thanks,
Hanno


From ziade.tarek at gmail.com  Mon Jun 30 11:21:00 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 30 Jun 2008 11:21:00 +0200
Subject: [Distutils] zc.buildout 1.1?
In-Reply-To: <g4a76l$14n$1@ger.gmane.org>
References: <g4a76l$14n$1@ger.gmane.org>
Message-ID: <94bdd2610806300221i3e9dfffgfa7b722b3ee3bed2@mail.gmail.com>

On Mon, Jun 30, 2008 at 10:57 AM, Hanno Schlichting <plone at hannosch.info>
wrote:

> Hi buildout-people,
>
> I have noticed us slacking a bit on the proper release management side of
> buildout as of late. It seems we have chosen to use the 1.0.x releases for
> introducing new features which has led to at least one completely broken
> release already.
>
> How do people feel about declaring the 1.0.x line as stable and maintenance
> only and do new feature work in a 1.1 release instead?
>
> Thanks,
> Hanno


Hey Hanno,

I would be in favor of keeping one line for zc.buildout releases to avoid
people having to deal with release numbers in their buildouts.

People that want the latest features can deal with the trunk ihmo.

I have proposed a while ago to reduce the pace of releases, and to come up
with releases that are robust,
and keep the new feature in the trunk until they are well tested.

What about having a stable release, let's say in three month, and releasing
an alpha one one week before ?

The current release (1.0.6) I have made was to avoid having a broken release
(1.0.5) at pypi head,
and seem robust.

I would really like to see the next one *way* later :D


Regards
Tarek



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



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080630/1e580840/attachment.htm>

From jaraco at jaraco.com  Mon Jun 30 18:04:40 2008
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Mon, 30 Jun 2008 10:04:40 -0600
Subject: [Distutils] ImportError running 'test' on namespace package -
	other package in namespace not found
In-Reply-To: <20080630012008.5FA7E3A408E@sparrow.telecommunity.com>
References: <750B64C66078B34D918257A1AC004DB20307EB@messiah.jaraco.com>
	<20080620124522.215D53A40D9@sparrow.telecommunity.com>
	<750B64C66078B34D918257A1AC004DB203086B@messiah.jaraco.com>
	<20080630012008.5FA7E3A408E@sparrow.telecommunity.com>
Message-ID: <750B64C66078B34D918257A1AC004DB2030872@messiah.jaraco.com>

Phillip,
	You're right.  I was running the tests on my two Windows Vista
environments, and now I discover the problem only exhibits itself under
Windows.  I expanded the packages to my Ubuntu 8.04 box, and after
installing nose (as you pointed out), the tests also ran (minimally) without
incident.

	I then copied the packages to a brand-new Windows Vista install.  I
installed Python 2.5.2, setuptools-0.6c8, and nose 0.10.3.  I then installed
myns.projA using develop, and attempted to run "setup.py test" on
myns.projB, and the error did exhibit itself.  Additionally, I tested the
sample on Windows XP (Python 2.5.2) and it also exhibits the error.

	Thanks to your help, I've further narrowed down the problem.

	I have filed a ticket with the nose tracker:
http://code.google.com/p/python-nose/issues/detail?id=197

	Any further suggestions are always appreciated.

Regards,
Jason

-----Original Message-----
From: Phillip J. Eby [mailto:pje at telecommunity.com] 
Sent: Sunday, 29 June, 2008 21:21
To: Jason R. Coombs; distutils-sig at python.org
Subject: Re: [Distutils] ImportError running 'test' on namespace package -
other package in namespace not found

I can't reproduce this using the archive you uploaded.  After running 
develop on projA, I ran test on projB and got an error message about 
nose not being available, so I added tests_require="nose" to projB, 
and then I got a run that said zero tests ran.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6580 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080630/a0363622/attachment.bin>

From michael.wieher at gmail.com  Mon Jun 30 20:02:54 2008
From: michael.wieher at gmail.com (Michael Wieher)
Date: Mon, 30 Jun 2008 13:02:54 -0500
Subject: [Distutils] Optimization of C++ extensions to Python
Message-ID: <fb251aba0806301102n3da58f9ct653ee50a03b2c9f1@mail.gmail.com>

hi,

I tried this question on the C++/Python SIG and was told to ask here. So.

When using distutils to build an extension (shared library), a C++
library to be imported into python, I find the optimization level set
for me, to -O2

This is great, I guess, but for certain debugging tools (valgrind) I
need that to be -O0

I tried setting the extra_compile_args and get output like this

gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC
-I/usr/include/python2.4 -c memrid.cpp -o
build/temp.linux-i686-2.4/memrid.o -O0


Which as you can see, has -O2 (the default) following -DNDEBUG ... and
my "extra" argument appended ... as -O0.

I need to be sure that this overrides the -O2 setting (or know how to
set it to -O0 correctly) ...
I noted that the binaries produced are different and that the binary
created when -O0 is in the gcc string is larger than the other...
the GCC documentation I could find didn't address the issue of
multiple flags on the same line and/or how the compiler would handle
them, and I think there is/should be a "correct" way of doing this
such that the confusion of "which optimization level is it using"
doesn't exist.

Can anyone
a) tell me if my binary compiled w/extra_compile_args -O0 is, indeed, level zero
b) tell me the correct way to adjust this flag?

thank you
-mike