From pkienzle at gmail.com  Mon Oct  1 05:19:12 2007
From: pkienzle at gmail.com (pkienzle)
Date: Sun, 30 Sep 2007 20:19:12 -0700 (PDT)
Subject: [Distutils] mingw32 exe problem
Message-ID: <12972801.post@talk.nabble.com>


Summary: cannot create windows exe files with distutils and mingw gcc-4.2. 
The fix is to remove the def_file from the list of objects in the link line.

When building my own version of py2exe with --compiler=mingw32, I was able
to compile (with some hacking of the py2exe source) but could not create
usable windows binaries.   The error I got when trying to run them is,
"myapp.exe is not a valid Win32 application".

Laboriously tracing code and modifying the link line by hand, I found I
could build usable EXEs if I eliminated the following line from
cygwinccompiler.py:

  objects.append(def_file)

The def file itself contains:

  LIBRARY run.exe
  EXPORTS

I'm using the technology preview gcc-4.2.1-dw2 prerelease from the mingw
download site.  I don't know if the def file is required on the current
release gcc-3.4.5.

Let me know if this is considered a bug in distutils, or if I need to post
this message to the mingw list.

Thanks in advance

  - Paul

-- 
View this message in context: http://www.nabble.com/mingw32-exe-problem-tf4546042.html#a12972801
Sent from the Python - distutils-sig mailing list archive at Nabble.com.


From ckkart at hoc.net  Mon Oct  1 09:27:35 2007
From: ckkart at hoc.net (Christian K.)
Date: Mon, 1 Oct 2007 07:27:35 +0000 (UTC)
Subject: [Distutils] errors compiling c++ extensions with swig on windows
References: <5p5kll$1kuvpu@rrcs-agw-02.hrndva.rr.com>
Message-ID: <loom.20071001T072628-516@post.gmane.org>

Karl Kobata <karl.kobata <at> syncira.com> writes:
> Did you get a reply for your questions?
> 
> If so, please forward or post.

No, neither do I remember what I changed but now it works nicely.

Christian




From cklinger at novareto.de  Mon Oct  1 13:13:11 2007
From: cklinger at novareto.de (Christian Klinger)
Date: Mon, 01 Oct 2007 13:13:11 +0200
Subject: [Distutils] Problem with easy_install
Message-ID: <fdqko7$jmh$1@sea.gmane.org>

Hi,

i hope this is the right mailing-list to ask for help.

Something with my easy install goes wrong:

svcwebkerb:/# easy_install virtualenv -v
'import site' failed; use -v for traceback
Traceback (most recent call last):
   File "/usr/local/bin/easy_install", line 5, in ?
     from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

Does anyone have an idea what to do.

I tried update setuptools but with no luck.

Christian


From pje at telecommunity.com  Mon Oct  1 17:32:08 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 01 Oct 2007 11:32:08 -0400
Subject: [Distutils] Problem with easy_install
In-Reply-To: <fdqko7$jmh$1@sea.gmane.org>
References: <fdqko7$jmh$1@sea.gmane.org>
Message-ID: <20071001152931.01A4E3A407B@sparrow.telecommunity.com>

At 01:13 PM 10/1/2007 +0200, Christian Klinger wrote:
>Hi,
>
>i hope this is the right mailing-list to ask for help.
>
>Something with my easy install goes wrong:
>
>svcwebkerb:/# easy_install virtualenv -v
>'import site' failed; use -v for traceback
>Traceback (most recent call last):
>    File "/usr/local/bin/easy_install", line 5, in ?
>      from pkg_resources import load_entry_point
>ImportError: No module named pkg_resources
>
>Does anyone have an idea what to do.
>
>I tried update setuptools but with no luck.

It appears that the setuptools egg is no longer on your sys.path.  I 
would suggest re-installing setuptools.


From me at rpatterson.net  Mon Oct  1 19:25:00 2007
From: me at rpatterson.net (Ross Patterson)
Date: Mon, 01 Oct 2007 10:25:00 -0700
Subject: [Distutils] ANN: z3c.recipe.egg - Recipes based on zc.recipe.egg
	for working with source distributions
Message-ID: <871wcekas3.fsf@superfluity.lefae.org>

An embedded and charset-unspecified text was scrubbed...
Name: README.txt
Url: http://mail.python.org/pipermail/distutils-sig/attachments/20071001/a216ee5c/attachment.txt 

From zooko at zooko.com  Mon Oct  1 23:02:13 2007
From: zooko at zooko.com (zooko)
Date: Mon, 1 Oct 2007 15:02:13 -0600
Subject: [Distutils] namespace package doesn't get its __init__.py file if
	--single-version-externally-managed
Message-ID: <7940C13F-6693-42B0-A99F-A57D4155174C@zooko.com>

The full version is here:

https://bugs.launchpad.net/zope3/+bug/146373

The short version is that if you run ./setup.py install --single- 
version-externally-managed from the zope.interface 3.4.0 source tree,  
you'll get everything you need to import zope.interface except for  
the "zope/__init__.py" file.

Is this a bug in setuptools?

Regards,

Zooko


From pje at telecommunity.com  Tue Oct  2 03:50:39 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 01 Oct 2007 21:50:39 -0400
Subject: [Distutils] namespace package doesn't get its __init__.py file
 if --single-version-externally-managed
In-Reply-To: <7940C13F-6693-42B0-A99F-A57D4155174C@zooko.com>
References: <7940C13F-6693-42B0-A99F-A57D4155174C@zooko.com>
Message-ID: <20071002014802.048253A407B@sparrow.telecommunity.com>

At 03:02 PM 10/1/2007 -0600, zooko wrote:
>The full version is here:
>
>https://bugs.launchpad.net/zope3/+bug/146373
>
>The short version is that if you run ./setup.py install --single-
>version-externally-managed from the zope.interface 3.4.0 source tree,
>you'll get everything you need to import zope.interface except for
>the "zope/__init__.py" file.
>
>Is this a bug in setuptools?

--single-version-externally-managed is intended for installation in 
site-packages, especially by system packages.  It thus *cannot* 
install the __init__.py without conflicting with other system 
packages that include code that's part of the same namespace 
package.  Thus, it installs a .pth file to work around the absence of 
the __init__.py

Unfortunately, this doesn't work if you install to a location that 
doesn't support .pth files.  If you are installing to a PYTHONPATH 
directory, you need to install setuptools' special 'site.py' to make 
that directory function in the same way that site-packages does.

Please remember that --single-version-externally-managed option is 
intended primarily for the benefit of system packaging 
tools.  Routine or even manual use is not recommended, because it's 
not manageable without some kind of management tool.  Hence the 
phrase, "externally managed".  :)


From alex at underwares.org  Tue Oct  2 18:01:19 2007
From: alex at underwares.org (Alexandre Gauthier)
Date: Tue, 02 Oct 2007 12:01:19 -0400
Subject: [Distutils] Distutils ignoring INSTALL_SCHEMES (or: How to put data
 files in PURELIB)
Message-ID: <47026B4F.1080701@underwares.org>

Hello there. I'm currently trying to package python bindings for a 
library. The bindings are currently compiled in an obscure way, so I end 
up with the following

libmylib\__init__.py
libmylib\mylib.pyd
libmylib\dep.dll
mylib.py

Where mylib.py is the SWIG interface for mylib.pyd.

Since I cannot have distutils compile the bindings at all, I'd like to 
just install the pyd and dll as "data files" along with the .py in 
"site-packages". That can be accomplished with the following:

for scheme in INSTALL_SCHEMES.values():
    scheme['data'] = scheme['purelib']

However, bdist_wininst will actually ignore this, at least in python 
2.5.1. I'll end up with the pyd and dll in the DATA dir, instead of in 
the PURELIB one.

I'm really at loss on how to proceed. I read about forcing /PURELIB/ in 
front of file paths with the following:

if sys.argv[1] == 'bdist_wininst':
     for fileInfo in COMPILED_LIBS:
         fileInfo[0] = '/PURELIB/%s' % fileInfo[0]

However, that doesn't work, and complains the path for each file forced 
into PURELIB this way can't be absolute.

I also tried installing the file into an absolute path constructed from 
sys.path variables, which actually worked if I ran "setup.py install", 
but creating a bdist_wininst with that setup file actually just ignored 
the files to copy.

I'm really at loss on how to proceed. The setup file doesn't need to be 
cross platform. It just needs to be able to build a friendly windows 
installer -- that's all...

If anyone could help, i'd be immensely grateful. Thank you.
--
Alexandre Gauthier


From pje at telecommunity.com  Tue Oct  2 18:53:54 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 02 Oct 2007 12:53:54 -0400
Subject: [Distutils] Distutils ignoring INSTALL_SCHEMES (or: How to put
 data files in PURELIB)
In-Reply-To: <47026B4F.1080701@underwares.org>
References: <47026B4F.1080701@underwares.org>
Message-ID: <20071002165116.407653A407A@sparrow.telecommunity.com>

At 12:01 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>Hello there. I'm currently trying to package python bindings for a
>library. The bindings are currently compiled in an obscure way, so I end
>up with the following
>
>libmylib\__init__.py
>libmylib\mylib.pyd
>libmylib\dep.dll
>mylib.py
>
>Where mylib.py is the SWIG interface for mylib.pyd.
>
>Since I cannot have distutils compile the bindings at all, I'd like to
>just install the pyd and dll as "data files" along with the .py in
>"site-packages". That can be accomplished with the following:
>
>for scheme in INSTALL_SCHEMES.values():
>     scheme['data'] = scheme['purelib']

Don't do this.  If you are using Python 2.4 or above, use this option 
in setup():

setup(
     package_data = {'mylib': ['mylib.pyd', 'dep.dll']},
     ...
)


From alex at underwares.org  Tue Oct  2 19:53:54 2007
From: alex at underwares.org (Alexandre Gauthier)
Date: Tue, 02 Oct 2007 13:53:54 -0400
Subject: [Distutils] Distutils ignoring INSTALL_SCHEMES (or: How to put
 data files in PURELIB)
In-Reply-To: <20071002165116.407653A407A@sparrow.telecommunity.com>
References: <47026B4F.1080701@underwares.org>
	<20071002165116.407653A407A@sparrow.telecommunity.com>
Message-ID: <470285B2.1030900@underwares.org>

Phillip J. Eby a ?crit :
> At 12:01 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>> Hello there. I'm currently trying to package python bindings for a
>> library. The bindings are currently compiled in an obscure way, so I end
>> up with the following
>>
>> libmylib\__init__.py
>> libmylib\mylib.pyd
>> libmylib\dep.dll
>> mylib.py
>>
>> Where mylib.py is the SWIG interface for mylib.pyd.
>>
>> Since I cannot have distutils compile the bindings at all, I'd like to
>> just install the pyd and dll as "data files" along with the .py in
>> "site-packages". That can be accomplished with the following:
>>
>> for scheme in INSTALL_SCHEMES.values():
>>     scheme['data'] = scheme['purelib']
>
> Don't do this.  If you are using Python 2.4 or above, use this option 
> in setup():
>
> setup(
>     package_data = {'mylib': ['mylib.pyd', 'dep.dll']},
>     ...
> )
>
Thanks, but I tried this as well, and it doesn't seem to work...

setup(
    .......
    py_modules = ['mylib'],
    packages = ['libmylib'],
    package_data = {'libmylib': ['_mylib.pyd', 'dep.dll']},
)

It only installs the package, the module but the two files I specified 
are nowhere to be found...
Perhaps I am doing something wrong....?


From pje at telecommunity.com  Tue Oct  2 22:37:43 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 02 Oct 2007 16:37:43 -0400
Subject: [Distutils] Distutils ignoring INSTALL_SCHEMES (or: How to put
 data files in PURELIB)
In-Reply-To: <470285B2.1030900@underwares.org>
References: <47026B4F.1080701@underwares.org>
	<20071002165116.407653A407A@sparrow.telecommunity.com>
	<470285B2.1030900@underwares.org>
Message-ID: <20071002203542.68B3D3A40A5@sparrow.telecommunity.com>

At 01:53 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>Phillip J. Eby a ?crit :
>>At 12:01 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>>>Hello there. I'm currently trying to package python bindings for a
>>>library. The bindings are currently compiled in an obscure way, so I end
>>>up with the following
>>>
>>>libmylib\__init__.py
>>>libmylib\mylib.pyd
>>>libmylib\dep.dll
>>>mylib.py
>>>
>>>Where mylib.py is the SWIG interface for mylib.pyd.
>>>
>>>Since I cannot have distutils compile the bindings at all, I'd like to
>>>just install the pyd and dll as "data files" along with the .py in
>>>"site-packages". That can be accomplished with the following:
>>>
>>>for scheme in INSTALL_SCHEMES.values():
>>>     scheme['data'] = scheme['purelib']
>>
>>Don't do this.  If you are using Python 2.4 or above, use this 
>>option in setup():
>>
>>setup(
>>     package_data = {'mylib': ['mylib.pyd', 'dep.dll']},
>>     ...
>>)
>Thanks, but I tried this as well, and it doesn't seem to work...
>
>setup(
>    .......
>    py_modules = ['mylib'],
>    packages = ['libmylib'],
>    package_data = {'libmylib': ['_mylib.pyd', 'dep.dll']},
>)
>
>It only installs the package, the module but the two files I 
>specified are nowhere to be found...
>Perhaps I am doing something wrong....?

Did you delete the build/ directory and re-build?


From zooko at zooko.com  Wed Oct  3 00:36:28 2007
From: zooko at zooko.com (zooko)
Date: Tue, 2 Oct 2007 16:36:28 -0600
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
	your current address space in order to learn its version number
In-Reply-To: <63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
Message-ID: <60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>

> Okay.  Attached is a patch that doesn't import pkg_resources and  
> doesn't reload anything.  I haven't yet tested it -- I am  
> submitting it only to inform the discussion and get any early  
> feedback from you on whether the very idea is sound.

Okay, I tested this patch on Mac OS X and it worked.  First I  
installed setuptools v0.6c3, then I tried to execute allmydata.org 's  
"setup.py install".  I got the error message saying that it couldn't  
install a newer version of setuptools (v0.6c7) when an older version  
was already loaded.  Then I applied my patch to ez_setup.py and tried  
again.  This time it installed v0.6c7.

Regards,

Zooko


From pje at telecommunity.com  Wed Oct  3 01:41:20 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 02 Oct 2007 19:41:20 -0400
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
 your current address space in order to learn its version number
In-Reply-To: <60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
	<60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
Message-ID: <20071002234240.135FC3A407A@sparrow.telecommunity.com>

At 04:36 PM 10/2/2007 -0600, zooko wrote:
> > Okay.  Attached is a patch that doesn't import pkg_resources and
> > doesn't reload anything.  I haven't yet tested it -- I am
> > submitting it only to inform the discussion and get any early
> > feedback from you on whether the very idea is sound.
>
>Okay, I tested this patch on Mac OS X and it worked.  First I
>installed setuptools v0.6c3, then I tried to execute allmydata.org 's
>"setup.py install".  I got the error message saying that it couldn't
>install a newer version of setuptools (v0.6c7) when an older version
>was already loaded.  Then I applied my patch to ez_setup.py and tried
>again.  This time it installed v0.6c7.

Interesting.  But the patch doesn't actually address the real issue 
with importing; i.e., upgrading setuptools in-place *while setuptools 
is already running*.

In other words, the test I care about is what happens when you run 
easy_install on the package, not "setup.py install".

Or, to put it more succinctly:

     if 'pkg_resources' in sys.modules or 'setuptools' in sys.modules:
         # setuptools is installed, but can't be upgraded, so
         # just version check (using pkg_resources) and exit if
         # it's not a good enough version.
     else:
         # okay to import pkg_resources and check for version,
         # as long as afterwards we del sys.modules['pkg_resources']
         # and re-import it.

So the subprocess and the duplication of code from pkg_resources is 
unnecessary, since it does not fix the problem when the code is run 
via easy_install.


From alex at underwares.org  Wed Oct  3 03:29:59 2007
From: alex at underwares.org (Alexandre Gauthier)
Date: Tue, 02 Oct 2007 21:29:59 -0400
Subject: [Distutils] Distutils ignoring INSTALL_SCHEMES (or: How to put
 data files in PURELIB)
In-Reply-To: <20071002203542.68B3D3A40A5@sparrow.telecommunity.com>
References: <47026B4F.1080701@underwares.org>
	<20071002165116.407653A407A@sparrow.telecommunity.com>
	<470285B2.1030900@underwares.org>
	<20071002203542.68B3D3A40A5@sparrow.telecommunity.com>
Message-ID: <4702F097.90805@underwares.org>

Phillip J. Eby a ?crit :
> At 01:53 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>> Phillip J. Eby a ?crit :
>>> At 12:01 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>>>> Hello there. I'm currently trying to package python bindings for a
>>>> library. The bindings are currently compiled in an obscure way, so 
>>>> I end
>>>> up with the following
>>>>
>>>> libmylib\__init__.py
>>>> libmylib\mylib.pyd
>>>> libmylib\dep.dll
>>>> mylib.py
>>>>
>>>> Where mylib.py is the SWIG interface for mylib.pyd.
>>>>
>>>> Since I cannot have distutils compile the bindings at all, I'd like to
>>>> just install the pyd and dll as "data files" along with the .py in
>>>> "site-packages". That can be accomplished with the following:
>>>>
>>>> for scheme in INSTALL_SCHEMES.values():
>>>>     scheme['data'] = scheme['purelib']
>>>
>>> Don't do this.  If you are using Python 2.4 or above, use this 
>>> option in setup():
>>>
>>> setup(
>>>     package_data = {'mylib': ['mylib.pyd', 'dep.dll']},
>>>     ...
>>> )
>> Thanks, but I tried this as well, and it doesn't seem to work...
>>
>> setup(
>>    .......
>>    py_modules = ['mylib'],
>>    packages = ['libmylib'],
>>    package_data = {'libmylib': ['_mylib.pyd', 'dep.dll']},
>> )
>>
>> It only installs the package, the module but the two files I 
>> specified are nowhere to be found...
>> Perhaps I am doing something wrong....?
>
> Did you delete the build/ directory and re-build?
>
Yes I did, I also added a MANIFEST.in file including *.dll and *.pyd. It 
doesn't seem to work at all! The package_data section seems to have 
absolutely no effect! This is the output:

 >python setup.py bdist_wininst

running bdist_wininst
running build
running build_py
creating build
creating build\lib
copying mylib.py -> build\lib
creating build\lib\libmylib
copying libmylib\__init__.py -> build\lib\libmylib
installing to build\bdist.win32\wininst
running install_lib
creating build\bdist.win32
creating build\bdist.win32\wininst
creating build\bdist.win32\wininst\PURELIB
creating build\bdist.win32\wininst\PURELIB\libmylib
copying build\lib\libmylib\__init__.py -> 
build\bdist.win32\wininst\PURELIB\lib
mylib
copying build\lib\mylib.py -> build\bdist.win32\wininst\PURELIB
running install_egg_info
Writing 
build\bdist.win32\wininst\PURELIB\mylib_python_bindings-1.0.3-py2.5.egg
-info
creating 'c:\docume~1\supern~1\locals~1\temp\2\tmpr379bd.zip' and adding 
'.' to
it
adding 'PURELIB\mylib.py'
adding 'PURELIB\mylib_python_bindings-1.0.3-py2.5.egg-info'
adding 'PURELIB\libmylib\__init__.py'
creating dist
removing 'build\bdist.win32\wininst' (and everything under it)

From alex at underwares.org  Wed Oct  3 03:43:41 2007
From: alex at underwares.org (Alexandre Gauthier)
Date: Tue, 02 Oct 2007 21:43:41 -0400
Subject: [Distutils] Distutils ignoring INSTALL_SCHEMES (or: How to put
 data files in PURELIB)
In-Reply-To: <4702F097.90805@underwares.org>
References: <47026B4F.1080701@underwares.org>	<20071002165116.407653A407A@sparrow.telecommunity.com>	<470285B2.1030900@underwares.org>	<20071002203542.68B3D3A40A5@sparrow.telecommunity.com>
	<4702F097.90805@underwares.org>
Message-ID: <4702F3CD.5000703@underwares.org>

Alexandre Gauthier a ?crit :
> Phillip J. Eby a ?crit :
>   
>> At 01:53 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>>     
>>> Phillip J. Eby a ?crit :
>>>       
>>>> At 12:01 PM 10/2/2007 -0400, Alexandre Gauthier wrote:
>>>>         
>>>>> Hello there. I'm currently trying to package python bindings for a
>>>>> library. The bindings are currently compiled in an obscure way, so 
>>>>> I end
>>>>> up with the following
>>>>>
>>>>> libmylib\__init__.py
>>>>> libmylib\mylib.pyd
>>>>> libmylib\dep.dll
>>>>> mylib.py
>>>>>
>>>>> Where mylib.py is the SWIG interface for mylib.pyd.
>>>>>
>>>>> Since I cannot have distutils compile the bindings at all, I'd like to
>>>>> just install the pyd and dll as "data files" along with the .py in
>>>>> "site-packages". That can be accomplished with the following:
>>>>>
>>>>> for scheme in INSTALL_SCHEMES.values():
>>>>>     scheme['data'] = scheme['purelib']
>>>>>           
>>>> Don't do this.  If you are using Python 2.4 or above, use this 
>>>> option in setup():
>>>>
>>>> setup(
>>>>     package_data = {'mylib': ['mylib.pyd', 'dep.dll']},
>>>>     ...
>>>> )
>>>>         
>>> Thanks, but I tried this as well, and it doesn't seem to work...
>>>
>>> setup(
>>>    .......
>>>    py_modules = ['mylib'],
>>>    packages = ['libmylib'],
>>>    package_data = {'libmylib': ['_mylib.pyd', 'dep.dll']},
>>> )
>>>
>>> It only installs the package, the module but the two files I 
>>> specified are nowhere to be found...
>>> Perhaps I am doing something wrong....?
>>>       
>> Did you delete the build/ directory and re-build?
>>
>>     
> Yes I did, I also added a MANIFEST.in file including *.dll and *.pyd. It 
> doesn't seem to work at all! The package_data section seems to have 
> absolutely no effect! This is the output:
>
>  >python setup.py bdist_wininst
>
>   
*snip*

Bad practice to reply to myself, but I think I just figured it out. the 
problem lies in the fact that I did not specify package_dir, which 
_magically makes any paths in package_data relative to that_. I didn't 
know that! :) I wish the build process would complain about wrongly 
referred files, though...

Thanks for your help :)

From jim at zope.com  Wed Oct  3 16:26:40 2007
From: jim at zope.com (Jim Fulton)
Date: Wed, 3 Oct 2007 10:26:40 -0400
Subject: [Distutils] setuptools development cycle
Message-ID: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>


I'm a little bit worried about setuptools development cycle.  We seem  
to be stalled at a 0.6 pre-release that is quite stable and widely  
used in production.  The next feature release, 0.7, seems to  
anticipate a major refactoring and major new features.  I'm a bit  
worried about this both from a fear of potential disruption, and a  
need for incremental feature development.

I propose that the grand re-factoring of setuptools planned for 0.7  
be moved off the trunk and to a 2.x release.  0.6 should be marked  
final.  Is it on the table to remove features from setuptools?  If  
not, then I think it should setuptools should get a 1.0 release.  (I  
do still think that setuptools, while wonderful, is too complex, so  
I'd love to see it simplified.)  I'd then like to see incremental  
feature development in the 1.x line.

I'd be interested in hearing Phillip's vision for setuptools' future.

Jim

--
Jim Fulton
Zope Corporation



From pje at telecommunity.com  Wed Oct  3 19:06:42 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 03 Oct 2007 13:06:42 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>
Message-ID: <20071003170416.5C6B93A407A@sparrow.telecommunity.com>

At 10:26 AM 10/3/2007 -0400, Jim Fulton wrote:
>I'm a little bit worried about setuptools development cycle.  We seem
>to be stalled at a 0.6 pre-release that is quite stable and widely
>used in production.  The next feature release, 0.7, seems to
>anticipate a major refactoring and major new features.  I'm a bit
>worried about this both from a fear of potential disruption, and a
>need for incremental feature development.
>
>I propose that the grand re-factoring of setuptools planned for 0.7
>be moved off the trunk and to a 2.x release.  0.6 should be marked
>final.

This is coming soon, but I want to finish some ez_setup improvements 
first.  There will be a "known issues" list to cover things like the 
incomplete/broken FTP support; I've given up on trying to keep 
hacking it into 0.6.


>  Is it on the table to remove features from setuptools?

Yes - and most are *already* removed from the 0.7 trunk.  That was 
the main reason for the branch.

Other (relatively minor) refactorings expected in 0.7 are to make URL 
handlers for easy_install pluggable, and to add build-time plugin 
options (so that people can implement custom build steps).

The biggest feature additions in 0.7 would be support for 
uninstallation, package inspection, virtual environment management, 
and ability to easy_install eggs using "classic/development" (i.e., 
.egg-info) installation layout.

Other new features planned for 0.7 include "or-ed" requirements, 
build/install of shared libraries, and "standard extras" (a way to 
specify to easy_install a set of extras that should be installed if 
they are defined by the targets).

None of this is what I'd consider "grand" refactoring; they're all 
either new features or minor refactorings to make things 
pluggable.  The most complex of them is probably the URL handler one, 
and only because the existing URL handling in 
setuptools.package_index is so hosed.

Now, if you include pkg_resources in, I would rather like to refactor 
the way the global objects (working set and resource manager) are 
handled, but I don't know how practical or even possible it 
is.  There are other things in pkg_resources that could use 
refactoring, but I'm not sure I dare.


From jim at zope.com  Wed Oct  3 19:12:49 2007
From: jim at zope.com (Jim Fulton)
Date: Wed, 3 Oct 2007 13:12:49 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <20071003170416.5C6B93A407A@sparrow.telecommunity.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>
	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>
Message-ID: <97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>


On Oct 3, 2007, at 1:06 PM, Phillip J. Eby wrote:

> At 10:26 AM 10/3/2007 -0400, Jim Fulton wrote:
>> I'm a little bit worried about setuptools development cycle.  We seem
>> to be stalled at a 0.6 pre-release that is quite stable and widely
>> used in production.  The next feature release, 0.7, seems to
>> anticipate a major refactoring and major new features.  I'm a bit
>> worried about this both from a fear of potential disruption, and a
>> need for incremental feature development.
>>
>> I propose that the grand re-factoring of setuptools planned for 0.7
>> be moved off the trunk and to a 2.x release.  0.6 should be marked
>> final.
>
> This is coming soon, but I want to finish some ez_setup  
> improvements first.  There will be a "known issues" list to cover  
> things like the incomplete/broken FTP support; I've given up on  
> trying to keep hacking it into 0.6.

I wonder what "this" you are referring to.

>
>>  Is it on the table to remove features from setuptools?
>
> Yes - and most are *already* removed from the 0.7 trunk.  That was  
> the main reason for the branch.

I'm confused on a number of counts.  Is the 0.7 "trunk" the same as  
the setuptools trunk? Is there also a branch for 0.7?

Is there a list of removed features somewhere? Do we get any input?

> Other (relatively minor) refactorings expected in 0.7 are to make  
> URL handlers for easy_install pluggable, and to add build-time  
> plugin options (so that people can implement custom build steps).
>
> The biggest feature additions in 0.7 would be support for  
> uninstallation, package inspection, virtual environment management,  
> and ability to easy_install eggs using "classic/ 
> development" (i.e., .egg-info) installation layout.
>
> Other new features planned for 0.7 include "or-ed" requirements,  
> build/install of shared libraries, and "standard extras" (a way to  
> specify to easy_install a set of extras that should be installed if  
> they are defined by the targets).
>
> None of this is what I'd consider "grand" refactoring; they're all  
> either new features or minor refactorings to make things  
> pluggable.  The most complex of them is probably the URL handler  
> one, and only because the existing URL handling in  
> setuptools.package_index is so hosed.
>
> Now, if you include pkg_resources in, I would rather like to  
> refactor the way the global objects (working set and resource  
> manager) are handled, but I don't know how practical or even  
> possible it is.  There are other things in pkg_resources that could  
> use refactoring, but I'm not sure I dare.

"Grand" is simply the impression I had.  The list of features  above  
is extensive though. Some of the items seem fairly big, or maybe I  
just can't tell what they are. Do you plan to try to get all of them  
into the next feature release? Or do you plan them a list of ideas  
for future releases.

Jim

--
Jim Fulton
Zope Corporation



From zooko at zooko.com  Wed Oct  3 21:20:01 2007
From: zooko at zooko.com (zooko)
Date: Wed, 3 Oct 2007 13:20:01 -0600
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
	your current address space in order to learn its version number
In-Reply-To: <20071002234240.135FC3A407A@sparrow.telecommunity.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
	<60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
	<20071002234240.135FC3A407A@sparrow.telecommunity.com>
Message-ID: <85ECDCA8-1EB3-413B-9480-B685AD4E3E33@zooko.com>

On Oct 2, 2007, at 5:41 PM, Phillip J. Eby wrote:

> So the subprocess and the duplication of code from pkg_resources is  
> unnecessary, since it does not fix the problem when the code is run  
> via easy_install.

Okay, how's this:

Regards,

Zooko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ez_setup.py
Type: text/x-python-script
Size: 9405 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20071003/01c57cb3/attachment.bin 

From pje at telecommunity.com  Wed Oct  3 21:37:39 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 03 Oct 2007 15:37:39 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>
	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>
	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
Message-ID: <20071003193502.0D83D3A407A@sparrow.telecommunity.com>

At 01:12 PM 10/3/2007 -0400, Jim Fulton wrote:
>On Oct 3, 2007, at 1:06 PM, Phillip J. Eby wrote:
>>At 10:26 AM 10/3/2007 -0400, Jim Fulton wrote:
>>>0.6 should be marked
>>>final.
>>
>>This is coming soon, but I want to finish some ez_setup
>>improvements first.  There will be a "known issues" list to cover
>>things like the incomplete/broken FTP support; I've given up on
>>trying to keep hacking it into 0.6.
>
>I wonder what "this" you are referring to.

"0.6 should be marked final."


>>>  Is it on the table to remove features from setuptools?
>>
>>Yes - and most are *already* removed from the 0.7 trunk.  That was
>>the main reason for the branch.
>
>I'm confused on a number of counts.  Is the 0.7 "trunk" the same as
>the setuptools trunk? Is there also a branch for 0.7?
>
>Is there a list of removed features somewhere? Do we get any input?

Yes, no, no, and maybe, respectively.  :)


>"Grand" is simply the impression I had.  The list of features  above
>is extensive though. Some of the items seem fairly big, or maybe I
>just can't tell what they are. Do you plan to try to get all of them
>into the next feature release?

They'll probably all appear over the course of a long string of 
alphas.  I don't have a detailed implementation plan yet.

The current status of setuptools is basically this: my initial 
creation was to scratch various distutils-related itches.  After OSAF 
became my client, my distutils-related itches got a lot 
bigger.  :)  OSAF funding got it to where it is today, but for all 
practical purposes both mine and OSAF's itches are fairly-well 
scratched, so I don't have much call to work on it these days -- I 
spend more time *supporting* it than working on it.  And OSAF's goals 
for the next year or so will likely not justify much in the way of 
focused development.

So, unless I end up with other client(s) who have setuptools-related 
needs, I'm unlikely to have much time available for setuptools 
development in the next year.  I could probably knock out everything 
but the biggest 0.7 features in a month, if that was all I had to 
work on.  But the odds of that month being one of the next 12 on the 
calendar seems slim right now.


From zooko at zooko.com  Wed Oct  3 21:48:52 2007
From: zooko at zooko.com (zooko)
Date: Wed, 3 Oct 2007 13:48:52 -0600
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
	your current address space in order to learn its version number
In-Reply-To: <85ECDCA8-1EB3-413B-9480-B685AD4E3E33@zooko.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
	<60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
	<20071002234240.135FC3A407A@sparrow.telecommunity.com>
	<85ECDCA8-1EB3-413B-9480-B685AD4E3E33@zooko.com>
Message-ID: <C8A8FBE3-419A-4A63-994B-861AAA488EC3@zooko.com>

>> So the subprocess and the duplication of code from pkg_resources  
>> is unnecessary, since it does not fix the problem when the code is  
>> run via easy_install.
>
> Okay, how's this:
>
> Regards,
>
> Zooko
>
> <ez_setup.py>
> _

Oh, I'm sorry -- that one still has subprocess.  Please stay tuned  
for something closer to what you suggested.

Regards,

Zooko


From zooko at zooko.com  Wed Oct  3 21:51:49 2007
From: zooko at zooko.com (zooko)
Date: Wed, 3 Oct 2007 13:51:49 -0600
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
	your current address space in order to learn its version number
In-Reply-To: <C8A8FBE3-419A-4A63-994B-861AAA488EC3@zooko.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
	<60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
	<20071002234240.135FC3A407A@sparrow.telecommunity.com>
	<85ECDCA8-1EB3-413B-9480-B685AD4E3E33@zooko.com>
	<C8A8FBE3-419A-4A63-994B-861AAA488EC3@zooko.com>
Message-ID: <B8E9FC9F-4E5D-4893-91BE-D22491E9E81D@zooko.com>

Okay, this still uses subprocess but doesn't duplicate parse_version 
() from pkg_resources.  Unlike the previous one that I posted, this  
one works because it does "import subprocess" at the top...

Regards,

Zooko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ez_setup.py
Type: text/x-python-script
Size: 9417 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20071003/feefc7a9/attachment.bin 

From laurent.ploix at gmail.com  Wed Oct  3 22:05:51 2007
From: laurent.ploix at gmail.com (Laurent Ploix)
Date: Wed, 3 Oct 2007 22:05:51 +0200
Subject: [Distutils] setuptools development cycle
In-Reply-To: <97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>
	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>
	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
Message-ID: <8e4ee2be0710031305p7cec235j3e7c75bbf2d2a767@mail.gmail.com>

Hi,

I think easy_install should try to have a look at what Maven2 did. I _know_
this is never a good idea to give some java examples in a python list, but
maven2 has some very interesting concepts, most of them being absolutely
language agnostic. (note: Maven2, not Maven1). In fact, I think Maven2 could
be implemented in any language (except that almost all examples and plugins
are about java... too bad :-( ). May be there is something to learn from
their experience.

First, there is the POM. This is the equivalent of the setup.py, where we
put all the description of the project. We find the authors names, the code
location, the tests location, the artifacts we can create, the dependencies,
etc. What is really interesting is that this description is really _only_ a
description. There is absolutely no "action" (script). The POM is really
conceptually close to setup.py, without any action in it. It contains the
structure of the project.

Then come the plugins. I think they are the equivalent of setuptools
extensions. And really, what makes Maven so nice is really the set of
plugins. Nothing else (IMHO). A few examples that are really nice: Having a
fully available Eclipse project ready, with all dependencies downloaded in
the local cache and included in the classpath is just one command away ("mvn
eclipse"). Ok, it means a few other things, such as an artifact repository,
but it's nice anyway. Testing is "mvn test", building is "mvn build", etc.
(Yes I know, that's similar to some setuptools commands)

So basically, I really think that setup.py should benefit from this
experience:

- Turn setup.py into a real description-only file (no commands), or invent
another file

- Have a local repository of eggs, _not_ included in the python path by
default

- Get rid of the site-package hell: find a nice way to start a python with a
predefined set of eggs (yes, the equivalent of naming all the eggs in the
python path, but in a more simple way, such as "python
--python_path_description=myconfig", myconfig being an alias to a set of
eggs)

- Manage the dependencies by downloading the eggs in the local repository
(fully independent from python itself)

- Extract everything from the core setuptools which could be in a plugin
(everything which does not read the description of the project and calls the
plugins)

- Create a set of plugins to deal with most common use cases, such as
packaging eggs, compiling libraries, handling special types of files etc...

- And create a nice wiki tutorial to explain how to create the best plugins
you have ever dreamed of

- Let others write the plugins for you

Actually, I believe the plugin orientation is already chosen ? (
http://mail.python.org/pipermail/distutils-sig/2007-January/007113.html )

And I know that finding time is the most difficult part of it...

My 2 cents.

2007/10/3, Jim Fulton <jim at zope.com>:
>
>
> On Oct 3, 2007, at 1:06 PM, Phillip J. Eby wrote:
>
> > At 10:26 AM 10/3/2007 -0400, Jim Fulton wrote:
> >> I'm a little bit worried about setuptools development cycle.  We seem
> >> to be stalled at a 0.6 pre-release that is quite stable and widely
> >> used in production.  The next feature release, 0.7, seems to
> >> anticipate a major refactoring and major new features.  I'm a bit
> >> worried about this both from a fear of potential disruption, and a
> >> need for incremental feature development.
> >>
> >> I propose that the grand re-factoring of setuptools planned for 0.7
> >> be moved off the trunk and to a 2.x release.  0.6 should be marked
> >> final
> >
> > This is coming soon, but I want to finish some ez_setup
> > improvements first.  There will be a "known issues" list to cover
> > things like the incomplete/broken FTP support; I've given up on
> > trying to keep hacking it into 0.6.
>
> I wonder what "this" you are referring to.
>
> >
> >>  Is it on the table to remove features from setuptools?
> >
> > Yes - and most are *already* removed from the 0.7 trunk.  That was
> > the main reason for the branch.
>
> I'm confused on a number of counts.  Is the 0.7 "trunk" the same as
> the setuptools trunk? Is there also a branch for 0.7?
>
> Is there a list of removed features somewhere? Do we get any input?
>
> > Other (relatively minor) refactorings expected in 0.7 are to make
> > URL handlers for easy_install pluggable, and to add build-time
> > plugin options (so that people can implement custom build steps).
> >
> > The biggest feature additions in 0.7 would be support for
> > uninstallation, package inspection, virtual environment management,
> > and ability to easy_install eggs using "classic/
> > development" (i.e., .egg-info) installation layout.
> >
> > Other new features planned for 0.7 include "or-ed" requirements,
> > build/install of shared libraries, and "standard extras" (a way to
> > specify to easy_install a set of extras that should be installed if
> > they are defined by the targets).
> >
> > None of this is what I'd consider "grand" refactoring; they're all
> > either new features or minor refactorings to make things
> > pluggable.  The most complex of them is probably the URL handler
> > one, and only because the existing URL handling in
> > setuptools.package_index is so hosed.
> >
> > Now, if you include pkg_resources in, I would rather like to
> > refactor the way the global objects (working set and resource
> > manager) are handled, but I don't know how practical or even
> > possible it is.  There are other things in pkg_resources that could
> > use refactoring, but I'm not sure I dare.
>
> "Grand" is simply the impression I had.  The list of features  above
> is extensive though. Some of the items seem fairly big, or maybe I
> just can't tell what they are. Do you plan to try to get all of them
> into the next feature release? Or do you plan them a list of ideas
> for future releases.
>
> Jim
>
> --
> Jim Fulton
> Zope Corporation
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Laurent Ploix
http://lauploix.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071003/ad99cd53/attachment.htm 

From zooko at zooko.com  Thu Oct  4 00:57:12 2007
From: zooko at zooko.com (zooko)
Date: Wed, 3 Oct 2007 16:57:12 -0600
Subject: [Distutils] extending setuptools to use other revision control
	tools for --tag-svn-revision ?
Message-ID: <5FAC9158-BE48-4E3D-9EA3-A5D470DC865B@zooko.com>

Folks:

The allmydata.org tahoe project uses setuptools and the darcs  
revision control tool [1].

We've long since written a custom script to generate the version  
number from the revision control history.  With this we can update  
our release version number in exactly one place -- the revision  
control tool -- and the script produces the Python module's  
__version__ attribute as well as the setup.py's "version" argument.   
The script also produces the equivalent of "revision numbers" (which  
in darcs is the count of patches that have been applied since the  
last release tag).

You can see the details here: [2, 3, 4, 5].

The question is: is there a way to extend setuptools to do something  
like this for revision control tools other than svn?

Thank you for your time.

Regards,

Zooko

[1] http://darcs.net
[2] http://allmydata.org/trac/tahoe/browser/misc/make-version.py
[3] http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py
[4] http://allmydata.org/trac/tahoe/browser/setup.py
[5] http://allmydata.org/trac/tahoe/browser/Makefile


From zooko at allmydata.com  Thu Oct  4 00:38:43 2007
From: zooko at allmydata.com (Zooko O'Whielacronx At Work)
Date: Wed, 3 Oct 2007 16:38:43 -0600
Subject: [Distutils] setuptools darcs plugin
Message-ID: <EFCE7089-194C-4638-980C-F38273AB98E4@allmydata.com>

Folks:

If you use the darcs revision control tool [1], then you might like  
the setuptools darcs plugin [2] that I just wrote, which makes it so  
that setuptools by default includes all of your revision-controlled  
files in the tarballs it produces.  This makes setuptools treat darcs  
the same way that it currently treats, I think, svn and cvs.

There are also comparable setuptools plugins for bzr [3] and monotone  
[4].

Regards,

Zooko

[1] http://darcs.net
[2] http://pypi.python.org/pypi/setuptools_darcs_plugin
[3] http://pypi.python.org/pypi/setuptoolsbzr
[4] http://pypi.python.org/pypi/setuptools_mtn

From a.badger at gmail.com  Thu Oct  4 01:11:05 2007
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 03 Oct 2007 16:11:05 -0700
Subject: [Distutils] Patch for minor easy_install problem
Message-ID: <47042189.4020408@gmail.com>

It looks like this fix to easy_isntall:
'''
0.6c5
         * Fixed .dll files on Cygwin not having executable permisions 
when an egg is installed unzipped.
'''

introduced a minor bug.  From 0.6c5 on, installing an egg unzipped makes 
all the files executable.

Attaching a patch that only makes .dll's executable.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setuptools-executable.patch
Type: text/x-patch
Size: 734 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20071003/957ee7a8/attachment.bin 

From pje at telecommunity.com  Thu Oct  4 01:20:35 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 03 Oct 2007 19:20:35 -0400
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
 your current address space in order to learn its version number
In-Reply-To: <B8E9FC9F-4E5D-4893-91BE-D22491E9E81D@zooko.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
	<60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
	<20071002234240.135FC3A407A@sparrow.telecommunity.com>
	<85ECDCA8-1EB3-413B-9480-B685AD4E3E33@zooko.com>
	<C8A8FBE3-419A-4A63-994B-861AAA488EC3@zooko.com>
	<B8E9FC9F-4E5D-4893-91BE-D22491E9E81D@zooko.com>
Message-ID: <20071003231757.35F7E3A407A@sparrow.telecommunity.com>

At 01:51 PM 10/3/2007 -0600, zooko wrote:
>Okay, this still uses subprocess but doesn't duplicate parse_version 
>() from pkg_resources.  Unlike the previous one that I posted, this
>one works because it does "import subprocess" at the top...

...which is why it won't work with Python 2.3.  The subprocess module 
wasn't added until 2.4.

Luckily, the subprocess is unnecessary; it's sufficient to:

     del sys.modules['pkg_resources']

after upgrading setuptools, as long as it wasn't there to start with.


From zooko at zooko.com  Thu Oct  4 23:00:48 2007
From: zooko at zooko.com (zooko)
Date: Thu, 4 Oct 2007 15:00:48 -0600
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
	your current address space in order to learn its version number
In-Reply-To: <20071003231757.35F7E3A407A@sparrow.telecommunity.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
	<60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
	<20071002234240.135FC3A407A@sparrow.telecommunity.com>
	<85ECDCA8-1EB3-413B-9480-B685AD4E3E33@zooko.com>
	<C8A8FBE3-419A-4A63-994B-861AAA488EC3@zooko.com>
	<B8E9FC9F-4E5D-4893-91BE-D22491E9E81D@zooko.com>
	<20071003231757.35F7E3A407A@sparrow.telecommunity.com>
Message-ID: <7308292A-F89C-417A-A75B-AF88DD3CAAC8@zooko.com>

On Oct 3, 2007, at 5:20 PM, Phillip J. Eby wrote:

>     del sys.modules['pkg_resources']
>
> after upgrading setuptools, as long as it wasn't there to start with.

There's something about this that I don't understand.  How is  
deleting the name from sys.modules different from reloading it, which  
as you already explained [1] is not going to work?

I can think of two approaches that will work for python >= 2.3:

1.  Import setuptools to get a copy of its __version__ attribute,  
import pkg_resources to use its parse_version() function, then del  
them from sys.modules.  (As above, I don't understand how deleting  
them from sys.modules and then importing them is different from  
reloading them.)

2.  Use os.system() instead of subprocess() to get the version of the  
installed setuptools, include a copy of the parse_version() function  
from pkg_resources.

The second approach seems clean and robust to me, and I would be  
happy to submit a patch that does it if you are interested in seeing  
one.

Regards,

Zooko

[1] http://mail.python.org/pipermail/distutils-sig/2007-September/ 
008309.html



From tseaver at palladion.com  Thu Oct  4 23:31:49 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 04 Oct 2007 17:31:49 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <20071003193502.0D83D3A407A@sparrow.telecommunity.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
	<20071003193502.0D83D3A407A@sparrow.telecommunity.com>
Message-ID: <47055BC5.9060605@palladion.com>

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

Phillip J. Eby wrote:

>>>>  Is it on the table to remove features from setuptools?
>>> Yes - and most are *already* removed from the 0.7 trunk.  That was
>>> the main reason for the branch.
>> I'm confused on a number of counts.  Is the 0.7 "trunk" the same as
>> the setuptools trunk? Is there also a branch for 0.7?
>>
>> Is there a list of removed features somewhere? Do we get any input?
> 
> Yes, no, no, and maybe, respectively.  :)

I've just done a comparison of the changelogs for the 0.6 branch and the
trunk, since the 0.6 branch was committed (nearly 18 months ago,
2006-04-14).  I'm attaching the analysis, but the summary would be that
I don't see any work unique to the trunk, beyond perhaps some prep work
for the goal of including setuptools in the standard library for Python
2.5.  Basically, all real feature changes and bug fixes have been
backported to the 0.6 branch.

At this point, would we be better off moving aside the current trunk,
and making a new trunk from the 0.6 branch after getting 0.6 finally
released?  We would then "cherry pick" any remaining important changes
from the old trunk, while moving forward on top of a codebase which is
actually getting used.


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

iD8DBQFHBVvF+gerLs4ltQ4RAqm6AKCxTntjqv9H3ciK++9TKqdcVpPqxwCfeRu7
XIjK9x3S+CTdMY3npCDdbPE=
=gmO6
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setuptools-archaeology.stx
Url: http://mail.python.org/pipermail/distutils-sig/attachments/20071004/7d15dfb1/attachment.txt 

From tseaver at palladion.com  Thu Oct  4 23:31:49 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 04 Oct 2007 17:31:49 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <20071003193502.0D83D3A407A@sparrow.telecommunity.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
	<20071003193502.0D83D3A407A@sparrow.telecommunity.com>
Message-ID: <47055BC5.9060605@palladion.com>

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

Phillip J. Eby wrote:

>>>>  Is it on the table to remove features from setuptools?
>>> Yes - and most are *already* removed from the 0.7 trunk.  That was
>>> the main reason for the branch.
>> I'm confused on a number of counts.  Is the 0.7 "trunk" the same as
>> the setuptools trunk? Is there also a branch for 0.7?
>>
>> Is there a list of removed features somewhere? Do we get any input?
> 
> Yes, no, no, and maybe, respectively.  :)

I've just done a comparison of the changelogs for the 0.6 branch and the
trunk, since the 0.6 branch was committed (nearly 18 months ago,
2006-04-14).  I'm attaching the analysis, but the summary would be that
I don't see any work unique to the trunk, beyond perhaps some prep work
for the goal of including setuptools in the standard library for Python
2.5.  Basically, all real feature changes and bug fixes have been
backported to the 0.6 branch.

At this point, would we be better off moving aside the current trunk,
and making a new trunk from the 0.6 branch after getting 0.6 finally
released?  We would then "cherry pick" any remaining important changes
from the old trunk, while moving forward on top of a codebase which is
actually getting used.


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

iD8DBQFHBVvF+gerLs4ltQ4RAqm6AKCxTntjqv9H3ciK++9TKqdcVpPqxwCfeRu7
XIjK9x3S+CTdMY3npCDdbPE=
=gmO6
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setuptools-archaeology.stx
Url: http://mail.python.org/pipermail/distutils-sig/attachments/20071004/7d15dfb1/attachment-0003.txt 

From pje at telecommunity.com  Fri Oct  5 02:41:14 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 04 Oct 2007 20:41:14 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <47055BC5.9060605@palladion.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>
	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>
	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
	<20071003193502.0D83D3A407A@sparrow.telecommunity.com>
	<47055BC5.9060605@palladion.com>
Message-ID: <20071005003835.AB5373A407A@sparrow.telecommunity.com>

At 05:31 PM 10/4/2007 -0400, Tres Seaver wrote:
>At this point, would we be better off moving aside the current trunk,
>and making a new trunk from the 0.6 branch after getting 0.6 finally
>released?

No way am I going to do the 2.5 work over again, so at least this 
particular portion of "we" would not be better off.  :)


From ygingras at ygingras.net  Fri Oct  5 15:34:11 2007
From: ygingras at ygingras.net (Yannick Gingras)
Date: Fri, 05 Oct 2007 09:34:11 -0400
Subject: [Distutils] Bugfix for hg.setuptools
Message-ID: <874ph5znvw.fsf@enceladus.ygingras.net>


The Mercurial plugin for Setuptools available here:

  http://cheeseshop.python.org/pypi/hg.setuptools/

will render setuptool unusable outside of a Mercurial repository.

Here is a patch to solve the problem:

  http://ygingras.net/files/hg.setuptools-without-a-repo.diff

and a patched release:

  http://ygingras.net/files/hg.setuptools-0.1.1.tar.gz
  http://ygingras.net/files/hg.setuptools-0.1.1.zip
  http://ygingras.net/files/hg.setuptools-0.1.1-py2.4.egg
  http://ygingras.net/files/hg.setuptools-0.1.1-py2.5.egg

I submitted the patch to the maintainer but I'm still without news from
him.  I hope this will help anyone who wants to use the plugin before
an official bugfix release is out.

-- 
Yannick Gingras

From ygingras at ygingras.net  Fri Oct  5 15:34:11 2007
From: ygingras at ygingras.net (Yannick Gingras)
Date: Fri, 05 Oct 2007 09:34:11 -0400
Subject: [Distutils] Bugfix for hg.setuptools
Message-ID: <874ph5znvw.fsf@enceladus.ygingras.net>


The Mercurial plugin for Setuptools available here:

  http://cheeseshop.python.org/pypi/hg.setuptools/

will render setuptool unusable outside of a Mercurial repository.

Here is a patch to solve the problem:

  http://ygingras.net/files/hg.setuptools-without-a-repo.diff

and a patched release:

  http://ygingras.net/files/hg.setuptools-0.1.1.tar.gz
  http://ygingras.net/files/hg.setuptools-0.1.1.zip
  http://ygingras.net/files/hg.setuptools-0.1.1-py2.4.egg
  http://ygingras.net/files/hg.setuptools-0.1.1-py2.5.egg

I submitted the patch to the maintainer but I'm still without news from
him.  I hope this will help anyone who wants to use the plugin before
an official bugfix release is out.

-- 
Yannick Gingras

From tseaver at palladion.com  Fri Oct  5 21:48:07 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 05 Oct 2007 15:48:07 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <20071005003835.AB5373A407A@sparrow.telecommunity.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>	<20071003193502.0D83D3A407A@sparrow.telecommunity.com>	<47055BC5.9060605@palladion.com>
	<20071005003835.AB5373A407A@sparrow.telecommunity.com>
Message-ID: <470694F7.7090302@palladion.com>

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

Phillip J. Eby wrote:
> At 05:31 PM 10/4/2007 -0400, Tres Seaver wrote:
>> At this point, would we be better off moving aside the current trunk,
>> and making a new trunk from the 0.6 branch after getting 0.6 finally
>> released?
> 
> No way am I going to do the 2.5 work over again, so at least this 
> particular portion of "we" would not be better off.  :)

I was really trying to get an enumeration of the stuff done on that
branch which was not already backported.  For instance, there are a half
dozen or so 0.6 branch checkins which talk about backporting 2.5
compatibility fixes:  are there others not ported?

The real source of my worry is that anything which is on the trunk but
*not* on the 0.6 branch is potentially bitrotting, as nobody (AFAIK) is
actually using the trunk at this point.  Given that your itch is
currently scratched (I assume by 0.6?), I don't know who is able to help
maintain the trunk at all.

Here are the changelog messages from the trunk which I could not
identify as being ported (back or forward) to the 0.6 branch:

 - (r45403) Don't eagerly import namespace packages.

 - (r45405) Work toward inclusion in Python 2.5

 - (445514) Back/sideport a bunch of 2.5 modules (pkutil, pydoc,
   doctest) for use in 2.3 / 2.4.

 - (r45515,45517,45519,45521,45554) Python 2.5 compatibility changes

 - (r45719,45720) Added "internals" documentation

 - (r50538) Tweak docs for subversion release stuff to make better use
   of new options.

 - (r50536) Update aliases for easier release using new options

 - (r50562) Crosslink "Creating your own package index" to the new docs.

 - (r50921) Sync pkgutil from Python trunk

 - (r51931) Retain 2.3/2.4 compatibility as well...

 - (r51930) Python 2.5 compatibility fix

 - (r53309) Don't double-upload .exe files under Python 2.5.  :(

 - (r53645) Match Python 2.5 pydoc

 - (r54966) es Setting svn:eol properties everywhere where they weren't
   set yet.

I can't figure out from checkin comments (and a few diffs) exactly how
much of this stuff is "feature removal" (which your earlier message said
had been mostly done already), versus fixes to make it run under Python
2.5 (doesn't the 0.6 branch work fine under 2.5?), versus cleanups to
make the Python stdlib folks happy (or whatver).


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

iD8DBQFHBpT3+gerLs4ltQ4RAn44AKDaBqLrP9Pdx5DhMcDcASFywbNfPACfcjT1
7DmQZghfUqJnOzb9zx4UveE=
=bIDH
-----END PGP SIGNATURE-----

From tseaver at palladion.com  Fri Oct  5 21:48:07 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 05 Oct 2007 15:48:07 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <20071005003835.AB5373A407A@sparrow.telecommunity.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>	<20071003193502.0D83D3A407A@sparrow.telecommunity.com>	<47055BC5.9060605@palladion.com>
	<20071005003835.AB5373A407A@sparrow.telecommunity.com>
Message-ID: <470694F7.7090302@palladion.com>

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

Phillip J. Eby wrote:
> At 05:31 PM 10/4/2007 -0400, Tres Seaver wrote:
>> At this point, would we be better off moving aside the current trunk,
>> and making a new trunk from the 0.6 branch after getting 0.6 finally
>> released?
> 
> No way am I going to do the 2.5 work over again, so at least this 
> particular portion of "we" would not be better off.  :)

I was really trying to get an enumeration of the stuff done on that
branch which was not already backported.  For instance, there are a half
dozen or so 0.6 branch checkins which talk about backporting 2.5
compatibility fixes:  are there others not ported?

The real source of my worry is that anything which is on the trunk but
*not* on the 0.6 branch is potentially bitrotting, as nobody (AFAIK) is
actually using the trunk at this point.  Given that your itch is
currently scratched (I assume by 0.6?), I don't know who is able to help
maintain the trunk at all.

Here are the changelog messages from the trunk which I could not
identify as being ported (back or forward) to the 0.6 branch:

 - (r45403) Don't eagerly import namespace packages.

 - (r45405) Work toward inclusion in Python 2.5

 - (445514) Back/sideport a bunch of 2.5 modules (pkutil, pydoc,
   doctest) for use in 2.3 / 2.4.

 - (r45515,45517,45519,45521,45554) Python 2.5 compatibility changes

 - (r45719,45720) Added "internals" documentation

 - (r50538) Tweak docs for subversion release stuff to make better use
   of new options.

 - (r50536) Update aliases for easier release using new options

 - (r50562) Crosslink "Creating your own package index" to the new docs.

 - (r50921) Sync pkgutil from Python trunk

 - (r51931) Retain 2.3/2.4 compatibility as well...

 - (r51930) Python 2.5 compatibility fix

 - (r53309) Don't double-upload .exe files under Python 2.5.  :(

 - (r53645) Match Python 2.5 pydoc

 - (r54966) es Setting svn:eol properties everywhere where they weren't
   set yet.

I can't figure out from checkin comments (and a few diffs) exactly how
much of this stuff is "feature removal" (which your earlier message said
had been mostly done already), versus fixes to make it run under Python
2.5 (doesn't the 0.6 branch work fine under 2.5?), versus cleanups to
make the Python stdlib folks happy (or whatver).


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

iD8DBQFHBpT3+gerLs4ltQ4RAn44AKDaBqLrP9Pdx5DhMcDcASFywbNfPACfcjT1
7DmQZghfUqJnOzb9zx4UveE=
=bIDH
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Sat Oct  6 00:13:46 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 05 Oct 2007 18:13:46 -0400
Subject: [Distutils] patches: ez_setup.py: don't import setuptools into
 your current address space in order to learn its version number
In-Reply-To: <7308292A-F89C-417A-A75B-AF88DD3CAAC8@zooko.com>
References: <3E6E0CC5-FF5D-4127-A4EA-730786508910@zooko.com>
	<20070927164853.16CB93A407B@sparrow.telecommunity.com>
	<63A5DBA9-C3E7-484D-A282-5D64C1D118A9@zooko.com>
	<60C10A33-A977-4204-AFF0-142ED752D953@zooko.com>
	<20071002234240.135FC3A407A@sparrow.telecommunity.com>
	<85ECDCA8-1EB3-413B-9480-B685AD4E3E33@zooko.com>
	<C8A8FBE3-419A-4A63-994B-861AAA488EC3@zooko.com>
	<B8E9FC9F-4E5D-4893-91BE-D22491E9E81D@zooko.com>
	<20071003231757.35F7E3A407A@sparrow.telecommunity.com>
	<7308292A-F89C-417A-A75B-AF88DD3CAAC8@zooko.com>
Message-ID: <20071005221106.EE6723A407B@sparrow.telecommunity.com>

At 03:00 PM 10/4/2007 -0600, zooko wrote:
>On Oct 3, 2007, at 5:20 PM, Phillip J. Eby wrote:
>
> >     del sys.modules['pkg_resources']
> >
> > after upgrading setuptools, as long as it wasn't there to start with.
>
>There's something about this that I don't understand.  How is
>deleting the name from sys.modules different from reloading it, which
>as you already explained [1] is not going to work?

This won't work for that either, so that's not why I'm suggesting 
deleting it.  The reason I'm suggesting it for this scenario is to 
ensure that pkg_resources initializes with clean module contents, 
which won't happen in a reload().


>I can think of two approaches that will work for python >= 2.3:
>
>1.  Import setuptools to get a copy of its __version__ attribute,

It's not necessary to import setuptools.  Using 
pkg_resources.require() is sufficient to do the job, and will get the 
actual version (including dev-r### tags).  The only reason ez_setup 
uses __version__ is to find a *legacy* setuptools (i.e. version 
0.0.1) -- and that is the only thing __version__ should be used for.

>import pkg_resources to use its parse_version() function, then del
>them from sys.modules.  (As above, I don't understand how deleting
>them from sys.modules and then importing them is different from
>reloading them.)

With regard to whether it's safe to do it, there is no 
difference.  If they were in sys.modules to start with, it's not safe 
to reload() or delete them.  If they *weren't* there, then it's okay 
to reload() or delete them.


>2.  Use os.system() instead of subprocess() to get the version of the
>installed setuptools, include a copy of the parse_version() function
>from pkg_resources.

It's not necessary to do that, because it doesn't help to have 
another process.  If setuptools or pkg_resources are already in 
sys.modules when a setup.py runs, it's already too late to upgrade safely.


From pje at telecommunity.com  Sat Oct  6 00:19:17 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 05 Oct 2007 18:19:17 -0400
Subject: [Distutils] setuptools development cycle
In-Reply-To: <470694F7.7090302@palladion.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>
	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>
	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
	<20071003193502.0D83D3A407A@sparrow.telecommunity.com>
	<47055BC5.9060605@palladion.com>
	<20071005003835.AB5373A407A@sparrow.telecommunity.com>
	<470694F7.7090302@palladion.com>
Message-ID: <20071005221638.5EAF93A407B@sparrow.telecommunity.com>

At 03:48 PM 10/5/2007 -0400, Tres Seaver wrote:
>Phillip J. Eby wrote:
> > At 05:31 PM 10/4/2007 -0400, Tres Seaver wrote:
> >> At this point, would we be better off moving aside the current trunk,
> >> and making a new trunk from the 0.6 branch after getting 0.6 finally
> >> released?
> >
> > No way am I going to do the 2.5 work over again, so at least this
> > particular portion of "we" would not be better off.  :)
>
>I was really trying to get an enumeration of the stuff done on that
>branch which was not already backported.  For instance, there are a half
>dozen or so 0.6 branch checkins which talk about backporting 2.5
>compatibility fixes:  are there others not ported?

The 2.5 work I'm referring to was about consolidation, code sharing 
with the stdlib, and re-organization more than it was about 
compatibility fixes (which of course were backported).


>The real source of my worry is that anything which is on the trunk but
>*not* on the 0.6 branch is potentially bitrotting, as nobody (AFAIK) is
>actually using the trunk at this point.

I use it almost exclusively, and that's where all the development is 
done -- which is why 99% of the changes appear on the trunk first, 
then get ported to 0.6.  I also know there are a few people who work 
off the trunk, although of course it's not nearly as widespread.


>I can't figure out from checkin comments (and a few diffs) exactly how
>much of this stuff is "feature removal" (which your earlier message said
>had been mostly done already),

There may be some things I've forgotten to remove as yet, but 
anything that the docs (or code) issues warnings about changing, is 
either already changed in the trunk, or should be.


From kyosohma at gmail.com  Sat Oct  6 15:16:35 2007
From: kyosohma at gmail.com (Mike)
Date: Sat, 6 Oct 2007 08:16:35 -0500
Subject: [Distutils] bdist_wininst TypeError
Message-ID: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>

Hi,

I was typing out the distutils package this morning and hit a wall
within a few minutes of running it. I got it using the "Easy Install"
script found here:

http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install

To test the package, I tried using it on PyCrypto, found here:

http://www.amk.ca/python/code/crypto.html

After unzipping that package to a temporary directory, I ran distutils
from the command line as follows:

L:\Temp\pycrypto-2.0.1>python setup.py bdist_wininst

Here's the traceback that gave me:

L:\Temp\pycrypto-2.0.1>python setup.py bdist_wininst
running bdist_wininst
running build
running build_py
running build_ext
Traceback (most recent call last):
  File "setup.py", line 164, in ?
    core.setup(**kw)
  File "L:\Python24\lib\distutils\core.py", line 149, in setup
    dist.run_commands()
  File "L:\Python24\lib\distutils\dist.py", line 946, in run_commands
    self.run_command(cmd)
  File "L:\Python24\lib\distutils\dist.py", line 966, in run_command
    cmd_obj.run()
  File "l:\python24\lib\site-packages\setuptools-0.6c7-py2.4.egg\setuptools\comm
and\bdist_wininst.py", line 37, in run
    _bdist_wininst.run(self)
  File "L:\Python24\lib\distutils\command\bdist_wininst.py", line 107, in run
    self.run_command('build')
  File "L:\Python24\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "L:\Python24\lib\distutils\dist.py", line 966, in run_command
    cmd_obj.run()
  File "L:\Python24\lib\distutils\command\build.py", line 112, in run
    self.run_command(cmd_name)
  File "L:\Python24\lib\distutils\cmd.py", line 333, in run_command
    self.distribution.run_command(command)
  File "L:\Python24\lib\distutils\dist.py", line 966, in run_command
    cmd_obj.run()
  File "L:\Python24\lib\distutils\command\build_ext.py", line 279, in run
    self.build_extensions()
  File "setup.py", line 117, in build_extensions
    build_ext.build_extensions(self)
  File "L:\Python24\lib\distutils\command\build_ext.py", line 402, in build_exte
nsions
    self.check_extensions_list(self.extensions)
  File "L:\Python24\lib\distutils\command\build_ext.py", line 304, in check_exte
nsions_list
    (ext_name, build_info) = ext
TypeError: unpack non-sequence


The only information I can find about this is an ongoing dispute about
some Pyrex version causing this issue:
http://mail.python.org/pipermail/distutils-sig/2007-September/008211.html

I am using Python 2.4, NOT Pyrex. I am on Windows XP 2. Any help would
be appreciated.

Mike

From pje at telecommunity.com  Sat Oct  6 16:56:20 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 06 Oct 2007 10:56:20 -0400
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.co
 m>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
Message-ID: <20071006145340.3612F3A407A@sparrow.telecommunity.com>

At 08:16 AM 10/6/2007 -0500, Mike wrote:
>I was typing out the distutils package this morning and hit a wall
>within a few minutes of running it.

The current version of distutils is already included with every 
version of Python; you just installed a broken out-of-date version of 
them.  Delete what you installed (presumably a distutils-*.egg file 
or directory), and your system should work again.


From kyosohma at gmail.com  Sat Oct  6 21:25:08 2007
From: kyosohma at gmail.com (Mike)
Date: Sat, 6 Oct 2007 14:25:08 -0500
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <20071006145340.3612F3A407A@sparrow.telecommunity.com>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
Message-ID: <b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>

Hi,

That's what I thought, but before I installed the distutils package
manually, I got this:

L:\Temp\pycrypto-2.0.1>python setup.py
Traceback (most recent call last):
  File "setup.py", line 8, in ?
    from setuptools import setup
ImportError: No module named setuptools


And I get that now that I've deleted the distutils-egg file. Do I need
to download setuptools from some place?

Mike


On 10/6/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 08:16 AM 10/6/2007 -0500, Mike wrote:
> >I was typing out the distutils package this morning and hit a wall
> >within a few minutes of running it.
>
> The current version of distutils is already included with every
> version of Python; you just installed a broken out-of-date version of
> them.  Delete what you installed (presumably a distutils-*.egg file
> or directory), and your system should work again.
>
>

From pje at telecommunity.com  Sun Oct  7 05:48:20 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 06 Oct 2007 23:48:20 -0400
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.co
 m>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
Message-ID: <20071007034540.25D1C3A407B@sparrow.telecommunity.com>

At 02:25 PM 10/6/2007 -0500, Mike wrote:
>Hi,
>
>That's what I thought, but before I installed the distutils package
>manually, I got this:
>
>L:\Temp\pycrypto-2.0.1>python setup.py
>Traceback (most recent call last):
>   File "setup.py", line 8, in ?
>     from setuptools import setup
>ImportError: No module named setuptools
>
>
>And I get that now that I've deleted the distutils-egg file. Do I need
>to download setuptools from some place?

Distutils comes with Python, setuptools does not.  For setuptools 
installation info, see:

    http://pypi.python.org/pypi/setuptools



From kyosohma at gmail.com  Sun Oct  7 14:05:40 2007
From: kyosohma at gmail.com (Mike)
Date: Sun, 7 Oct 2007 07:05:40 -0500
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <20071007034540.25D1C3A407B@sparrow.telecommunity.com>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
	<20071007034540.25D1C3A407B@sparrow.telecommunity.com>
Message-ID: <b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.com>

Phillip,

On 10/6/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 02:25 PM 10/6/2007 -0500, Mike wrote:
> >Hi,
> >
> >That's what I thought, but before I installed the distutils package
> >manually, I got this:
> >
> >L:\Temp\pycrypto-2.0.1>python setup.py
> >Traceback (most recent call last):
> >   File "setup.py", line 8, in ?
> >     from setuptools import setup
> >ImportError: No module named setuptools
> >
> >
> >And I get that now that I've deleted the distutils-egg file. Do I need
> >to download setuptools from some place?
>
> Distutils comes with Python, setuptools does not.  For setuptools
> installation info, see:
>
>     http://pypi.python.org/pypi/setuptools
>

I'm usually not this dense when it comes to Python. I'm just new to
the distribution process. I did as you said and now I'm back to the
first error I posted. I deleted the distutils-egg and the
setuptools-egg directories. Maybe that "Easy Setup" somehow overwrote
some of the original installation too?

Thanks for all your help.

Mike

From pje at telecommunity.com  Sun Oct  7 18:12:11 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 07 Oct 2007 12:12:11 -0400
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.co
 m>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
	<20071007034540.25D1C3A407B@sparrow.telecommunity.com>
	<b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.com>
Message-ID: <20071007160932.326EA3A407A@sparrow.telecommunity.com>

At 07:05 AM 10/7/2007 -0500, Mike wrote:
>Phillip,
>
>On 10/6/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 02:25 PM 10/6/2007 -0500, Mike wrote:
> > >Hi,
> > >
> > >That's what I thought, but before I installed the distutils package
> > >manually, I got this:
> > >
> > >L:\Temp\pycrypto-2.0.1>python setup.py
> > >Traceback (most recent call last):
> > >   File "setup.py", line 8, in ?
> > >     from setuptools import setup
> > >ImportError: No module named setuptools
> > >
> > >
> > >And I get that now that I've deleted the distutils-egg file. Do I need
> > >to download setuptools from some place?
> >
> > Distutils comes with Python, setuptools does not.  For setuptools
> > installation info, see:
> >
> >     http://pypi.python.org/pypi/setuptools
> >
>
>I'm usually not this dense when it comes to Python. I'm just new to
>the distribution process. I did as you said and now I'm back to the
>first error I posted. I deleted the distutils-egg and the
>setuptools-egg directories.

Try this:

python -c "import distutils; print distutils.__version__, distutils.__file__"

This should print a version and a filename.  The filename should be 
something like 'c:\Python24\Lib\distutils\...' (*without* 
site-packages between the Lib and distutils), and the version should 
be 1.0.3 or higher.

If the location is different, you haven't uninstalled it 
correctly.  If the location is correct but the version is less than 
1.0.3, you installed the distutils over the version that came with 
Python, and will have to reinstall Python to fix it.


From kyosohma at gmail.com  Sun Oct  7 18:55:58 2007
From: kyosohma at gmail.com (Mike)
Date: Sun, 7 Oct 2007 11:55:58 -0500
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <20071007160932.326EA3A407A@sparrow.telecommunity.com>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
	<20071007034540.25D1C3A407B@sparrow.telecommunity.com>
	<b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.com>
	<20071007160932.326EA3A407A@sparrow.telecommunity.com>
Message-ID: <b3fa43300710070955x3f2aa8a4nc22e36b638fe70bf@mail.gmail.com>

On 10/7/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 07:05 AM 10/7/2007 -0500, Mike wrote:
> >Phillip,
> >
> >On 10/6/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > > At 02:25 PM 10/6/2007 -0500, Mike wrote:
> > > >Hi,
> > > >
> > > >That's what I thought, but before I installed the distutils package
> > > >manually, I got this:
> > > >
> > > >L:\Temp\pycrypto-2.0.1>python setup.py
> > > >Traceback (most recent call last):
> > > >   File "setup.py", line 8, in ?
> > > >     from setuptools import setup
> > > >ImportError: No module named setuptools
> > > >
> > > >
> > > >And I get that now that I've deleted the distutils-egg file. Do I need
> > > >to download setuptools from some place?
> > >
> > > Distutils comes with Python, setuptools does not.  For setuptools
> > > installation info, see:
> > >
> > >     http://pypi.python.org/pypi/setuptools
> > >
> >
> >I'm usually not this dense when it comes to Python. I'm just new to
> >the distribution process. I did as you said and now I'm back to the
> >first error I posted. I deleted the distutils-egg and the
> >setuptools-egg directories.
>
> Try this:
>
> python -c "import distutils; print distutils.__version__, distutils.__file__"
>
> This should print a version and a filename.  The filename should be
> something like 'c:\Python24\Lib\distutils\...' (*without*
> site-packages between the Lib and distutils), and the version should
> be 1.0.3 or higher.
>
> If the location is different, you haven't uninstalled it
> correctly.  If the location is correct but the version is less than
> 1.0.3, you installed the distutils over the version that came with
> Python, and will have to reinstall Python to fix it.
>
>

Here is what was returned:

2.4.1 L:\Python24\lib\distutils\__init__.py

I did notice that if I try running Python from the command line, it
loads the ActiveState version of Python 2.4.3 rather than the "normal"
2.4.3 version. I don't suppose that could be the problem,  could it? I
checked the path that ActiveState uses and it points to the same
location though...

I'm at a loss.

Mike

From pje at telecommunity.com  Sun Oct  7 23:06:02 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 07 Oct 2007 17:06:02 -0400
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <b3fa43300710070955x3f2aa8a4nc22e36b638fe70bf@mail.gmail.co
 m>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
	<20071007034540.25D1C3A407B@sparrow.telecommunity.com>
	<b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.com>
	<20071007160932.326EA3A407A@sparrow.telecommunity.com>
	<b3fa43300710070955x3f2aa8a4nc22e36b638fe70bf@mail.gmail.com>
Message-ID: <20071007210322.0340A3A407A@sparrow.telecommunity.com>

At 11:55 AM 10/7/2007 -0500, Mike wrote:
>On 10/7/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > Try this:
> >
> > python -c "import distutils; print distutils.__version__, 
> distutils.__file__"
> >
> > This should print a version and a filename.  The filename should be
> > something like 'c:\Python24\Lib\distutils\...' (*without*
> > site-packages between the Lib and distutils), and the version should
> > be 1.0.3 or higher.
> >
> > If the location is different, you haven't uninstalled it
> > correctly.  If the location is correct but the version is less than
> > 1.0.3, you installed the distutils over the version that came with
> > Python, and will have to reinstall Python to fix it.
> >
> >
>
>Here is what was returned:
>
>2.4.1 L:\Python24\lib\distutils\__init__.py

Then this version of Python should have a usable version of the distutils.

>I did notice that if I try running Python from the command line, it
>loads the ActiveState version of Python 2.4.3 rather than the "normal"
>2.4.3 version. I don't suppose that could be the problem,  could it?

Since I don't know what pythons you've been running for what, I have no idea.


From kyosohma at gmail.com  Mon Oct  8 00:01:14 2007
From: kyosohma at gmail.com (Mike)
Date: Sun, 7 Oct 2007 17:01:14 -0500
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <20071007210322.0340A3A407A@sparrow.telecommunity.com>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
	<20071007034540.25D1C3A407B@sparrow.telecommunity.com>
	<b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.com>
	<20071007160932.326EA3A407A@sparrow.telecommunity.com>
	<b3fa43300710070955x3f2aa8a4nc22e36b638fe70bf@mail.gmail.com>
	<20071007210322.0340A3A407A@sparrow.telecommunity.com>
Message-ID: <b3fa43300710071501s26442e5eoc83b4b581cccfef6@mail.gmail.com>

On 10/7/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 11:55 AM 10/7/2007 -0500, Mike wrote:
> >On 10/7/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > > Try this:
> > >
> > > python -c "import distutils; print distutils.__version__,
> > distutils.__file__"
> > >
> > > This should print a version and a filename.  The filename should be
> > > something like 'c:\Python24\Lib\distutils\...' (*without*
> > > site-packages between the Lib and distutils), and the version should
> > > be 1.0.3 or higher.
> > >
> > > If the location is different, you haven't uninstalled it
> > > correctly.  If the location is correct but the version is less than
> > > 1.0.3, you installed the distutils over the version that came with
> > > Python, and will have to reinstall Python to fix it.
> > >
> > >
> >
> >Here is what was returned:
> >
> >2.4.1 L:\Python24\lib\distutils\__init__.py
>
> Then this version of Python should have a usable version of the distutils.
>
> >I did notice that if I try running Python from the command line, it
> >loads the ActiveState version of Python 2.4.3 rather than the "normal"
> >2.4.3 version. I don't suppose that could be the problem,  could it?
>
> Since I don't know what pythons you've been running for what, I have no idea.
>
>

Ok. I uninstalled everything related to Python including my ctypes and
wxPython installations. I reinstalled Python 2.4.3 and setuptools
0.6c7. It still gives me the TypeError as before.

Also, now it won't recognize "python" as a command name. While I can
start python's command line terminal by going to Start, Run, and
typing "python", if I open a command window and type the following:

python setup.py bdist_wininst

I get

'python' is not recognized as an internal or external command,
operable program or batch file.

Unless I actually type out the path to the python executable. Maybe
there's something wrong with the PyCrypto module itself. I don't know.
I guess I'll post this to the c.l.py group too.

Sorry to bother you. Thanks for your help.

Mike

From pje at telecommunity.com  Mon Oct  8 00:12:51 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 07 Oct 2007 18:12:51 -0400
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <b3fa43300710071501s26442e5eoc83b4b581cccfef6@mail.gmail.co
 m>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
	<20071007034540.25D1C3A407B@sparrow.telecommunity.com>
	<b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.com>
	<20071007160932.326EA3A407A@sparrow.telecommunity.com>
	<b3fa43300710070955x3f2aa8a4nc22e36b638fe70bf@mail.gmail.com>
	<20071007210322.0340A3A407A@sparrow.telecommunity.com>
	<b3fa43300710071501s26442e5eoc83b4b581cccfef6@mail.gmail.com>
Message-ID: <20071007221011.AA6DE3A407A@sparrow.telecommunity.com>

At 05:01 PM 10/7/2007 -0500, Mike wrote:
>Ok. I uninstalled everything related to Python including my ctypes and
>wxPython installations. I reinstalled Python 2.4.3 and setuptools
>0.6c7. It still gives me the TypeError as before.
>
>Also, now it won't recognize "python" as a command name. While I can
>start python's command line terminal by going to Start, Run, and
>typing "python", if I open a command window and type the following:
>
>python setup.py bdist_wininst
>
>I get
>
>'python' is not recognized as an internal or external command,
>operable program or batch file.
>
>Unless I actually type out the path to the python executable. Maybe
>there's something wrong with the PyCrypto module itself.

It works fine for me.  What's appears to be wrong is that you have 
(or had) more than one Python installation, and I suspect the one you 
uninstalled was not the one that you were using.


>  I don't know.
>I guess I'll post this to the c.l.py group too.

I wouldn't bother until you find out what other Python(s) are 
installed on your system and get clear about which ones you're 
running.  I tried installing PyCrypto from the same page you spoke 
of, and it worked fine for me using Python 2.4 on Windows.


From kyosohma at gmail.com  Mon Oct  8 00:28:50 2007
From: kyosohma at gmail.com (Mike)
Date: Sun, 7 Oct 2007 17:28:50 -0500
Subject: [Distutils] bdist_wininst TypeError
In-Reply-To: <20071007221011.AA6DE3A407A@sparrow.telecommunity.com>
References: <b3fa43300710060616s2a73bb0cmee00e6d7b119b38e@mail.gmail.com>
	<20071006145340.3612F3A407A@sparrow.telecommunity.com>
	<b3fa43300710061225y587d1c47ld974724e963bbbbb@mail.gmail.com>
	<20071007034540.25D1C3A407B@sparrow.telecommunity.com>
	<b3fa43300710070505q3fcc8ef0v40f0e19d652d0483@mail.gmail.com>
	<20071007160932.326EA3A407A@sparrow.telecommunity.com>
	<b3fa43300710070955x3f2aa8a4nc22e36b638fe70bf@mail.gmail.com>
	<20071007210322.0340A3A407A@sparrow.telecommunity.com>
	<b3fa43300710071501s26442e5eoc83b4b581cccfef6@mail.gmail.com>
	<20071007221011.AA6DE3A407A@sparrow.telecommunity.com>
Message-ID: <b3fa43300710071528y616cf422q3e3c6183f8889ed2@mail.gmail.com>

Phillip,

On 10/7/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 05:01 PM 10/7/2007 -0500, Mike wrote:
> >Ok. I uninstalled everything related to Python including my ctypes and
> >wxPython installations. I reinstalled Python 2.4.3 and setuptools
> >0.6c7. It still gives me the TypeError as before.
> >
> >Also, now it won't recognize "python" as a command name. While I can
> >start python's command line terminal by going to Start, Run, and
> >typing "python", if I open a command window and type the following:
> >
> >python setup.py bdist_wininst
> >
> >I get
> >
> >'python' is not recognized as an internal or external command,
> >operable program or batch file.
> >
> >Unless I actually type out the path to the python executable. Maybe
> >there's something wrong with the PyCrypto module itself.
>
> It works fine for me.  What's appears to be wrong is that you have
> (or had) more than one Python installation, and I suspect the one you
> uninstalled was not the one that you were using.
>
>
> >  I don't know.
> >I guess I'll post this to the c.l.py group too.
>
> I wouldn't bother until you find out what other Python(s) are
> installed on your system and get clear about which ones you're
> running.  I tried installing PyCrypto from the same page you spoke
> of, and it worked fine for me using Python 2.4 on Windows.
>
>

I got it to work just now. I deleted the PyCrypto folder I had and
unzipped it again. I had been told that one needed to add the
following line to the setup.py file:

from setuptools import setup

Once I removed that, it worked like a charm. I am an utter fool. I
apologize for taking up so much of your time this weekend. Thanks
again for all your help.

Mike

From cadet.bramble at gmail.com  Mon Oct  8 07:48:14 2007
From: cadet.bramble at gmail.com (The Cadet)
Date: Mon, 8 Oct 2007 01:48:14 -0400
Subject: [Distutils] --help-commands option to easy_install not working
Message-ID: <bf7bbd70710072248o6fcf92b8ge72e39cd2daf2f73@mail.gmail.com>

Hi,

I wanted to get more help on the command line for ``easy_install``
commands. Running ``easy_install --help`` tells me::

    Common commands: (see '--help-commands' for more)

but the ``--help-commands`` option does not seem to work::

    $ easy_install --help-commands
    usage: easy_install [options] requirement_or_url ...
       or: easy_install --help

    error: option --help-commands not recognized

I'm using ``setuptools-0.6c7-py2.5.egg``.

Is this something that's already been fixed?

I checked the docs at
http://peak.telecommunity.com/DevCenter/EasyInstall , but the only
mention of ``--help-commands`` was in the 0.6a10 section where it said
"Fixed the annoying --help-commands wart.". No idea what that means.

Thanks.

From laurihallila at gmail.com  Mon Oct  8 09:06:05 2007
From: laurihallila at gmail.com (Lauri Hallila)
Date: Mon, 8 Oct 2007 10:06:05 +0300
Subject: [Distutils] Incompatibility issue with setuptools 0.6c7-py2.4
	and workingenv-0.6.5-py2.4
In-Reply-To: <3f02fd7f0710080001w74f8aab2ud3d594781a0e92d2@mail.gmail.com>
References: <3f02fd7f0710080001w74f8aab2ud3d594781a0e92d2@mail.gmail.com>
Message-ID: <3f02fd7f0710080006i70420d8fs49d2284bb7ce26ec@mail.gmail.com>

It seems that the message was blocked by moderator because of my e-mail
being too big... I'll just copy-paste how I fixed the problem in
easy_install.py here:

empty_pat = re.compile(r'^[\t ]*\r?$')
comment_pat = re.compile(r'[\t ]*#')

...

        if os.path.exists(sitepy):
            log.debug("Checking existing site.py in %s", self.install_dir)
            f = open(sitepy, 'rb')
            current = f.read()
            f.close()
            distutils_error = False
            lines = current.split("\n")

            for line in lines:
                if empty_pat.match(line) or comment_pat.match(line):
                    continue
                else:
                    if not line.startswith('def __boot():'):
                        distutils_error = True
                    break

            if distutils_error:
                raise DistutilsError(
                    "%s is not a setuptools-generated site.py; please"
                    " remove it." % sitepy
                )

On 10/8/07, Lauri Hallila <laurihallila at gmail.com> wrote:
>
> Hello!
>
> I noticed a small problem in setuptools... workingenv (version 0.6.5-py2.4),
> in some instances, adds a comment-line "# Duplicating setuptools'
> site.py..." into the beginning of site.py (workingenv.py , line 1214).
> Problem is that easy_install.py checks if the existing file site.py starts
> with "def __boot():", and if it doesn't, it raises an error.
>
> I fixed the problem in my own environment by skipping empty and
> comment-lines in easy_install.py (fixed file attached).
>
> I just thought to inform you of the problem... feel free to take my fix
> into setuptools if you like my way to fix the problem.
>
>
> Best regards,
> Lauri Hallila
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071008/ae240e17/attachment-0001.htm 

From pje at telecommunity.com  Mon Oct  8 13:25:19 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 08 Oct 2007 07:25:19 -0400
Subject: [Distutils] Incompatibility issue with setuptools 0.6c7-py2.4
 and workingenv-0.6.5-py2.4
In-Reply-To: <3f02fd7f0710080006i70420d8fs49d2284bb7ce26ec@mail.gmail.co
 m>
References: <3f02fd7f0710080001w74f8aab2ud3d594781a0e92d2@mail.gmail.com>
	<3f02fd7f0710080006i70420d8fs49d2284bb7ce26ec@mail.gmail.com>
Message-ID: <20071008112239.1A1213A407A@sparrow.telecommunity.com>

At 10:06 AM 10/8/2007 +0300, Lauri Hallila wrote:
>On 10/8/07, Lauri Hallila 
><<mailto:laurihallila at gmail.com>laurihallila at gmail.com> wrote:
>Hello!
>
>I noticed a small problem in setuptools... workingenv (version 
>0.6.5-py2.4), in some instances, adds a comment-line "# Duplicating 
>setuptools' site.py..." into the beginning of site.py (workingenv.py 
>, line 1214). Problem is that easy_install.py checks if the existing 
>file site.py starts with "def __boot():", and if it doesn't, it 
>raises an error.
>
>I fixed the problem in my own environment by skipping empty and 
>comment-lines in easy_install.py (fixed file attached).
>
>I just thought to inform you of the problem... feel free to take my 
>fix into setuptools if you like my way to fix the problem.

Unless you're on a Mac, you should probably upgrade from workingenv 
to virtualenv:

   http://pypi.python.org/pypi/virtualenv/

Virtualenv does not patch setuptools, and so can't have this problem.


From pje at telecommunity.com  Mon Oct  8 13:30:12 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 08 Oct 2007 07:30:12 -0400
Subject: [Distutils] --help-commands option to easy_install not working
In-Reply-To: <bf7bbd70710072248o6fcf92b8ge72e39cd2daf2f73@mail.gmail.com
 >
References: <bf7bbd70710072248o6fcf92b8ge72e39cd2daf2f73@mail.gmail.com>
Message-ID: <20071008112731.98A873A407A@sparrow.telecommunity.com>

At 01:48 AM 10/8/2007 -0400, The Cadet wrote:
>I checked the docs at
>http://peak.telecommunity.com/DevCenter/EasyInstall , but the only
>mention of ``--help-commands`` was in the 0.6a10 section where it said
>"Fixed the annoying --help-commands wart.". No idea what that means.

The wart is that --help-commands is ever displayed in the first 
place, because it's a distutils command that easy_install doesn't support.

In other words, --help-commands really isn't a valid option to 
easy_install; never was and never will be.  However, it appears that 
there is distutils code that was added in Python 2.5 that displays it 
even when I'm trying to prevent it from doing so.  (If you run 
easy_install for Python 2.3 or 2.4, the --help-commands option doesn't appear.)

I'll look into suppressing the output from Python 2.5, especially 
since it lists additional options that don't make sense for easy_install.


From pje at telecommunity.com  Mon Oct  8 13:54:08 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 08 Oct 2007 07:54:08 -0400
Subject: [Distutils] --help-commands option to easy_install not working
In-Reply-To: <20071008112731.98A873A407A@sparrow.telecommunity.com>
References: <bf7bbd70710072248o6fcf92b8ge72e39cd2daf2f73@mail.gmail.com>
	<20071008112731.98A873A407A@sparrow.telecommunity.com>
Message-ID: <20071008115127.0EA1F3A407A@sparrow.telecommunity.com>

At 07:30 AM 10/8/2007 -0400, Phillip J. Eby wrote:
>At 01:48 AM 10/8/2007 -0400, The Cadet wrote:
> >I checked the docs at
> >http://peak.telecommunity.com/DevCenter/EasyInstall , but the only
> >mention of ``--help-commands`` was in the 0.6a10 section where it said
> >"Fixed the annoying --help-commands wart.". No idea what that means.
>
>The wart is that --help-commands is ever displayed in the first
>place, because it's a distutils command that easy_install doesn't support.
>
>In other words, --help-commands really isn't a valid option to
>easy_install; never was and never will be.  However, it appears that
>there is distutils code that was added in Python 2.5 that displays it
>even when I'm trying to prevent it from doing so.  (If you run
>easy_install for Python 2.3 or 2.4, the --help-commands option 
>doesn't appear.)
>
>I'll look into suppressing the output from Python 2.5, especially
>since it lists additional options that don't make sense for easy_install.

This is now fixed in SVN; you can use ``easy_install 
setuptools==dev06`` to get a copy.


From laurihallila at gmail.com  Mon Oct  8 09:01:03 2007
From: laurihallila at gmail.com (Lauri Hallila)
Date: Mon, 8 Oct 2007 10:01:03 +0300
Subject: [Distutils] Incompatibility issue with setuptools 0.6c7-py2.4 and
	workingenv-0.6.5-py2.4
Message-ID: <3f02fd7f0710080001w74f8aab2ud3d594781a0e92d2@mail.gmail.com>

Hello!

I noticed a small problem in setuptools... workingenv (version 0.6.5-py2.4),
in some instances, adds a comment-line "# Duplicating setuptools' site.py..."
into the beginning of site.py (workingenv.py, line 1214). Problem is that
easy_install.py checks if the existing file site.py starts with "def
__boot():", and if it doesn't, it raises an error.

I fixed the problem in my own environment by skipping empty and
comment-lines in easy_install.py (fixed file attached).

I just thought to inform you of the problem... feel free to take my fix into
setuptools if you like my way to fix the problem.


Best regards,
Lauri Hallila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071008/d41190ab/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: easy_install.py
Type: text/x-python
Size: 61698 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20071008/d41190ab/attachment-0001.py 

From ianb at colorstudy.com  Mon Oct  8 21:39:21 2007
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 08 Oct 2007 14:39:21 -0500
Subject: [Distutils] Incompatibility issue with setuptools 0.6c7-py2.4
 and workingenv-0.6.5-py2.4
In-Reply-To: <20071008112239.1A1213A407A@sparrow.telecommunity.com>
References: <3f02fd7f0710080001w74f8aab2ud3d594781a0e92d2@mail.gmail.com>	<3f02fd7f0710080006i70420d8fs49d2284bb7ce26ec@mail.gmail.com>
	<20071008112239.1A1213A407A@sparrow.telecommunity.com>
Message-ID: <470A8769.2060109@colorstudy.com>

Phillip J. Eby wrote:
> At 10:06 AM 10/8/2007 +0300, Lauri Hallila wrote:
>> On 10/8/07, Lauri Hallila 
>> <<mailto:laurihallila at gmail.com>laurihallila at gmail.com> wrote:
>> Hello!
>>
>> I noticed a small problem in setuptools... workingenv (version 
>> 0.6.5-py2.4), in some instances, adds a comment-line "# Duplicating 
>> setuptools' site.py..." into the beginning of site.py (workingenv.py 
>> , line 1214). Problem is that easy_install.py checks if the existing 
>> file site.py starts with "def __boot():", and if it doesn't, it 
>> raises an error.
>>
>> I fixed the problem in my own environment by skipping empty and 
>> comment-lines in easy_install.py (fixed file attached).
>>
>> I just thought to inform you of the problem... feel free to take my 
>> fix into setuptools if you like my way to fix the problem.
> 
> Unless you're on a Mac, you should probably upgrade from workingenv 
> to virtualenv:
> 
>    http://pypi.python.org/pypi/virtualenv/
> 
> Virtualenv does not patch setuptools, and so can't have this problem.

Yeah, it's this problem in particular that became basically 
insurmountable.  Which seems odd -- it doesn't look like a hard problem. 
  But it was very hard.

It will also work on a Mac if you use a custom-built Python.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers

From ianb at colorstudy.com  Mon Oct  8 21:40:38 2007
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 08 Oct 2007 14:40:38 -0500
Subject: [Distutils] setuptools development cycle
In-Reply-To: <8e4ee2be0710031305p7cec235j3e7c75bbf2d2a767@mail.gmail.com>
References: <36312C59-CD1B-43A0-B72D-3121C56D6C37@zope.com>	<20071003170416.5C6B93A407A@sparrow.telecommunity.com>	<97BF147B-0A8B-44FA-8B0F-8377F5A201A3@zope.com>
	<8e4ee2be0710031305p7cec235j3e7c75bbf2d2a767@mail.gmail.com>
Message-ID: <470A87B6.1000302@colorstudy.com>

Laurent Ploix wrote:
> Hi,
> 
> I think easy_install should try to have a look at what Maven2 did. I 
> _know_ this is never a good idea to give some java examples in a python 
> list, but maven2 has some very interesting concepts, most of them being 
> absolutely language agnostic. (note: Maven2, not Maven1). In fact, I 
> think Maven2 could be implemented in any language (except that almost 
> all examples and plugins are about java... too bad :-( ). May be there 
> is something to learn from their experience.
> 
> First, there is the POM. This is the equivalent of the setup.py, where 
> we put all the description of the project. We find the authors names, 
> the code location, the tests location, the artifacts we can create, the 
> dependencies, etc. What is really interesting is that this description 
> is really _only_ a description. There is absolutely no "action" 
> (script). The POM is really conceptually close to setup.py, without any 
> action in it. It contains the structure of the project.
> 
> Then come the plugins. I think they are the equivalent of setuptools 
> extensions. And really, what makes Maven so nice is really the set of 
> plugins. Nothing else (IMHO). A few examples that are really nice: 
> Having a fully available Eclipse project ready, with all dependencies 
> downloaded in the local cache and included in the classpath is just one 
> command away ("mvn eclipse"). Ok, it means a few other things, such as 
> an artifact repository, but it's nice anyway. Testing is "mvn test", 
> building is "mvn build", etc. (Yes I know, that's similar to some 
> setuptools commands)
> 
> So basically, I really think that setup.py should benefit from this 
> experience:
> 
> - Turn setup.py into a real description-only file (no commands), or 
> invent another file

For backward compatibility this doesn't really work.  Potentially you 
could have a setup.py:

"""
from mavon_style_lib import setup

setup(__file__)
"""

And have that function read the description-only file.

I personally would prefer, say, PKG-INFO to be the canonical source of 
information instead of setup.py.  But then, I also find it handy 
sometimes to generate long_description from a segment of a text file in 
my documentation.  That's easy currently, and would be much harder with 
a description-only file.

> - Have a local repository of eggs, _not_ included in the python path by 
> default

If you easy_install -m then they won't be on the python path.  But it's 
all very fuzzy; I don't think many people make good use of -m in 
deployments.  I know I don't.

> - Get rid of the site-package hell: find a nice way to start a python 
> with a predefined set of eggs (yes, the equivalent of naming all the 
> eggs in the python path, but in a more simple way, such as "python 
> --python_path_description=myconfig", myconfig being an alias to a set of 
> eggs)

This is what zc.buildout and virtualenv do, more or less.  zc.buildout 
includes building the initial set of eggs; in virtualenv I'll be 
suggesting poach-eggs (https://svn.openplans.org/svn/PoachEggs/trunk) to 
install a set of packages.

> - Manage the dependencies by downloading the eggs in the local 
> repository (fully independent from python itself)

In buildutils I've added a bundle command, which kind of does this -- 
collecting all the eggs for a particular package.  You do this with 
"python setup.py bundle".  Buildutils is available with "hg clone 
https://www.knowledgetap.com/hg/buildutils/" (sorry it's not fully 
released at the moment).

> - Extract everything from the core setuptools which could be in a plugin 
> (everything which does not read the description of the project and calls 
> the plugins)

Setuptools already self-provides lots of its functionality as plugins. 
I don't see any need to extract these into separate packages.

> - Create a set of plugins to deal with most common use cases, such as 
> packaging eggs, compiling libraries, handling special types of files etc...
> 
> - And create a nice wiki tutorial to explain how to create the best 
> plugins you have ever dreamed of

This needs some work; I'd like to make a paster create template in 
buildutils for creating setuptools' extensions.  It would be pretty 
small.  It's not terribly hard to write a setuptools' extension now, 
though you do have to deal with the somewhat crufty interface of 
distutils commands.  It's not really so bad, though.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers

From ianb at colorstudy.com  Mon Oct  8 21:45:32 2007
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 08 Oct 2007 14:45:32 -0500
Subject: [Distutils] install_recommends proposal
In-Reply-To: <20070926223824.GA31300@fridge.pov.lt>
References: <fddlqi$pdt$1@sea.gmane.org>
	<fdebnt$d4p$1@sea.gmane.org>	<fdeg1v$sb6$1@sea.gmane.org>
	<20070926223824.GA31300@fridge.pov.lt>
Message-ID: <470A88DC.1050303@colorstudy.com>

Marius Gedminas wrote:
> On Wed, Sep 26, 2007 at 10:38:49PM +0200, Martijn Faassen wrote:
>> I understand how the name "install_recommends" could be confusing 
>> terminology
> 
> Yes it is
> 
>> given the way package managers use the term 'recommended 
>> packages', which means extra that you could install too to get more 
>> features. "install_prefers" instead?
>>
>> An alternative would be to expand the syntax of install_requires and 
>> extra_require to allow the recommended version number hint. Something 
>> like this:
>>
>> install_requires = [
>>     'foo (1.2.1)',
>>     'bar >= 1.3 (1.3.2)',
>>    ]
> 
> A really human-readable version would be:
> 
>   install_requires = [
>       'foo (prefer 1.2.1)',
>       'bar >= 1.3 (prefer 1.3.2)',
>      ]

This is kind of an old thread, but I personally would really like 
install_recommends.  One use case is to recommend packages that are not 
strictly required.  E.g., I have WSGI applications that work well with 
PasteScript for serving the application, but PasteScript isn't actually 
required.  This leads to an awkward situation where I have to choose 
whether to require a package that isn't actually needed (e.g., it's 
never imported anywhere), or leave it out and confuse people who install 
the application.  If preferred versions were part of install_requires, I 
don't see how I could achieve this.

The workingenv requirements, and now poach-eggs, try to solve this by 
installing a description of packages instead of just a single package, 
but this would make that mostly unnecessary.


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers

From ianb at colorstudy.com  Mon Oct  8 23:15:17 2007
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 08 Oct 2007 16:15:17 -0500
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <46FAB739.2030203@palladion.com>
References: <46FAB739.2030203@palladion.com>
Message-ID: <470A9DE5.6020707@colorstudy.com>

Tres Seaver wrote:
> When building a virtual environment, I'd like to be able to store
> global distutils configuration options which are custom to that
> environment.  However, both setuptools and distutils expect to
> read / write that file relative to the directory of
> 'distutils.__file__', which is located in the *source*
> environment under virtualenv 0.8.4::

This should be working in virtualenv trunk; I had to switch up the way 
sys.path was constructed some, because the way it was the system path 
came before the virtualenv path, so a virtual distutils wouldn't be seen.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers

From pje at telecommunity.com  Tue Oct  9 00:24:49 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 08 Oct 2007 18:24:49 -0400
Subject: [Distutils] install_recommends proposal
In-Reply-To: <470A88DC.1050303@colorstudy.com>
References: <fddlqi$pdt$1@sea.gmane.org> <fdebnt$d4p$1@sea.gmane.org>
	<fdeg1v$sb6$1@sea.gmane.org> <20070926223824.GA31300@fridge.pov.lt>
	<470A88DC.1050303@colorstudy.com>
Message-ID: <20071008222210.11E723A407A@sparrow.telecommunity.com>

At 02:45 PM 10/8/2007 -0500, Ian Bicking wrote:
>Marius Gedminas wrote:
> > On Wed, Sep 26, 2007 at 10:38:49PM +0200, Martijn Faassen wrote:
> >> I understand how the name "install_recommends" could be confusing
> >> terminology
> >
> > Yes it is
> >
> >> given the way package managers use the term 'recommended
> >> packages', which means extra that you could install too to get more
> >> features. "install_prefers" instead?
> >>
> >> An alternative would be to expand the syntax of install_requires and
> >> extra_require to allow the recommended version number hint. Something
> >> like this:
> >>
> >> install_requires = [
> >>     'foo (1.2.1)',
> >>     'bar >= 1.3 (1.3.2)',
> >>    ]
> >
> > A really human-readable version would be:
> >
> >   install_requires = [
> >       'foo (prefer 1.2.1)',
> >       'bar >= 1.3 (prefer 1.3.2)',
> >      ]
>
>This is kind of an old thread, but I personally would really like
>install_recommends.  One use case is to recommend packages that are not
>strictly required.  E.g., I have WSGI applications that work well with
>PasteScript for serving the application, but PasteScript isn't actually
>required.  This leads to an awkward situation where I have to choose
>whether to require a package that isn't actually needed (e.g., it's
>never imported anywhere), or leave it out and confuse people who install
>the application.  If preferred versions were part of install_requires, I
>don't see how I could achieve this.

That's what 'extras_require' is for; you can always have an extra 
named 'recommended', and then install 'Foo[recommended]' to get all 
the recommended stuff.

This is a very different use case than the original request of this 
thread (which is really just preferred packages/versions within 
requirement specs).


From tseaver at palladion.com  Tue Oct  9 18:05:10 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 09 Oct 2007 12:05:10 -0400
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <470A9DE5.6020707@colorstudy.com>
References: <46FAB739.2030203@palladion.com> <470A9DE5.6020707@colorstudy.com>
Message-ID: <470BA6B6.7040509@palladion.com>

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

Ian Bicking wrote:
> Tres Seaver wrote:
>> When building a virtual environment, I'd like to be able to store
>> global distutils configuration options which are custom to that
>> environment.  However, both setuptools and distutils expect to
>> read / write that file relative to the directory of
>> 'distutils.__file__', which is located in the *source*
>> environment under virtualenv 0.8.4::
> 
> This should be working in virtualenv trunk; I had to switch up the way 
> sys.path was constructed some, because the way it was the system path 
> came before the virtualenv path, so a virtual distutils wouldn't be seen.

Cool. Where is the trunk SVN, by the way?


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

iD8DBQFHC6a2+gerLs4ltQ4RAoAjAJ9yKKrATx+luUHypC7dEnlrZuAzwACfaMmt
99D5MVArj2L4HXilr9Bx2bA=
=3cr9
-----END PGP SIGNATURE-----

From tseaver at palladion.com  Tue Oct  9 18:05:10 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 09 Oct 2007 12:05:10 -0400
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <470A9DE5.6020707@colorstudy.com>
References: <46FAB739.2030203@palladion.com> <470A9DE5.6020707@colorstudy.com>
Message-ID: <470BA6B6.7040509@palladion.com>

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

Ian Bicking wrote:
> Tres Seaver wrote:
>> When building a virtual environment, I'd like to be able to store
>> global distutils configuration options which are custom to that
>> environment.  However, both setuptools and distutils expect to
>> read / write that file relative to the directory of
>> 'distutils.__file__', which is located in the *source*
>> environment under virtualenv 0.8.4::
> 
> This should be working in virtualenv trunk; I had to switch up the way 
> sys.path was constructed some, because the way it was the system path 
> came before the virtualenv path, so a virtual distutils wouldn't be seen.

Cool. Where is the trunk SVN, by the way?


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

iD8DBQFHC6a2+gerLs4ltQ4RAoAjAJ9yKKrATx+luUHypC7dEnlrZuAzwACfaMmt
99D5MVArj2L4HXilr9Bx2bA=
=3cr9
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Tue Oct  9 20:01:44 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 09 Oct 2007 14:01:44 -0400
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <470BA6B6.7040509@palladion.com>
References: <46FAB739.2030203@palladion.com> <470A9DE5.6020707@colorstudy.com>
	<470BA6B6.7040509@palladion.com>
Message-ID: <20071009175905.33B143A407C@sparrow.telecommunity.com>

At 12:05 PM 10/9/2007 -0400, Tres Seaver wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Ian Bicking wrote:
> > Tres Seaver wrote:
> >> When building a virtual environment, I'd like to be able to store
> >> global distutils configuration options which are custom to that
> >> environment.  However, both setuptools and distutils expect to
> >> read / write that file relative to the directory of
> >> 'distutils.__file__', which is located in the *source*
> >> environment under virtualenv 0.8.4::
> >
> > This should be working in virtualenv trunk; I had to switch up the way
> > sys.path was constructed some, because the way it was the system path
> > came before the virtualenv path, so a virtual distutils wouldn't be seen.
>
>Cool. Where is the trunk SVN, by the way?

By the way, at OSAF we had a similar issue recently with needing a 
local distutils.cfg; the recipe for creating a simple "virtual 
distutils" in case anyone needs it is:

distutils.py:
__path__ = ['/path/to/the/real/distutils']  # yes, it ends with 'distutils'
from distutils.__init__ import __version__, __revision__, __doc__

You can then put a distutils.cfg alongside it, in a directory that's 
on sys.path *before* the real disutils.  (And you'll need, of course, 
to know where the real distutils is.)


From tseaver at palladion.com  Tue Oct  9 20:43:39 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 09 Oct 2007 14:43:39 -0400
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <20071009175905.33B143A407C@sparrow.telecommunity.com>
References: <46FAB739.2030203@palladion.com>
	<470A9DE5.6020707@colorstudy.com>	<470BA6B6.7040509@palladion.com>
	<20071009175905.33B143A407C@sparrow.telecommunity.com>
Message-ID: <470BCBDB.1080600@palladion.com>

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

Phillip J. Eby wrote:

> By the way, at OSAF we had a similar issue recently with needing a 
> local distutils.cfg; the recipe for creating a simple "virtual 
> distutils" in case anyone needs it is:
> 
> distutils.py:
> __path__ = ['/path/to/the/real/distutils']  # yes, it ends with 'distutils'
> from distutils.__init__ import __version__, __revision__, __doc__
> 
> You can then put a distutils.cfg alongside it, in a directory that's 
> on sys.path *before* the real disutils.  (And you'll need, of course, 
> to know where the real distutils is.)

Cool, thanks.  That solution (importing the other names into the virtual
module) probably suppresses some weird edge-case bugs I hadn't stumbled
over in mine yet.

Ian, I withdraw my "motion" in favor of Phillip's "friendly amendment." ;)


Ters.
- --
===================================================================
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

iD8DBQFHC8vb+gerLs4ltQ4RAneYAJ0UHSF3x4uqDZZvjfvGCKwRdtHh7wCgsZzX
N+kqXa5CllJ3PQW+cHqtotM=
=w+Vh
-----END PGP SIGNATURE-----

From tseaver at palladion.com  Tue Oct  9 20:43:39 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 09 Oct 2007 14:43:39 -0400
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <20071009175905.33B143A407C@sparrow.telecommunity.com>
References: <46FAB739.2030203@palladion.com>
	<470A9DE5.6020707@colorstudy.com>	<470BA6B6.7040509@palladion.com>
	<20071009175905.33B143A407C@sparrow.telecommunity.com>
Message-ID: <470BCBDB.1080600@palladion.com>

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

Phillip J. Eby wrote:

> By the way, at OSAF we had a similar issue recently with needing a 
> local distutils.cfg; the recipe for creating a simple "virtual 
> distutils" in case anyone needs it is:
> 
> distutils.py:
> __path__ = ['/path/to/the/real/distutils']  # yes, it ends with 'distutils'
> from distutils.__init__ import __version__, __revision__, __doc__
> 
> You can then put a distutils.cfg alongside it, in a directory that's 
> on sys.path *before* the real disutils.  (And you'll need, of course, 
> to know where the real distutils is.)

Cool, thanks.  That solution (importing the other names into the virtual
module) probably suppresses some weird edge-case bugs I hadn't stumbled
over in mine yet.

Ian, I withdraw my "motion" in favor of Phillip's "friendly amendment." ;)


Ters.
- --
===================================================================
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

iD8DBQFHC8vb+gerLs4ltQ4RAneYAJ0UHSF3x4uqDZZvjfvGCKwRdtHh7wCgsZzX
N+kqXa5CllJ3PQW+cHqtotM=
=w+Vh
-----END PGP SIGNATURE-----


From ianb at colorstudy.com  Tue Oct  9 22:59:28 2007
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 09 Oct 2007 15:59:28 -0500
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <470BA6B6.7040509@palladion.com>
References: <46FAB739.2030203@palladion.com> <470A9DE5.6020707@colorstudy.com>
	<470BA6B6.7040509@palladion.com>
Message-ID: <470BEBB0.5090401@colorstudy.com>

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ian Bicking wrote:
>> Tres Seaver wrote:
>>> When building a virtual environment, I'd like to be able to store
>>> global distutils configuration options which are custom to that
>>> environment.  However, both setuptools and distutils expect to
>>> read / write that file relative to the directory of
>>> 'distutils.__file__', which is located in the *source*
>>> environment under virtualenv 0.8.4::
>> This should be working in virtualenv trunk; I had to switch up the way 
>> sys.path was constructed some, because the way it was the system path 
>> came before the virtualenv path, so a virtual distutils wouldn't be seen.
> 
> Cool. Where is the trunk SVN, by the way?

At http://svn.colorstudy.com/virtualenv/trunk


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
             : Write code, do good : http://topp.openplans.org/careers

From tseaver at palladion.com  Tue Oct  9 23:12:57 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 09 Oct 2007 17:12:57 -0400
Subject: [Distutils] Enabling local distutils.cfg usage
In-Reply-To: <470BEBB0.5090401@colorstudy.com>
References: <46FAB739.2030203@palladion.com> <470A9DE5.6020707@colorstudy.com>
	<470BA6B6.7040509@palladion.com> <470BEBB0.5090401@colorstudy.com>
Message-ID: <470BEED9.8000808@palladion.com>

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

Ian Bicking wrote:
> Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ian Bicking wrote:
>>> Tres Seaver wrote:
>>>> When building a virtual environment, I'd like to be able to store
>>>> global distutils configuration options which are custom to that
>>>> environment.  However, both setuptools and distutils expect to
>>>> read / write that file relative to the directory of
>>>> 'distutils.__file__', which is located in the *source*
>>>> environment under virtualenv 0.8.4::
>>> This should be working in virtualenv trunk; I had to switch up the way 
>>> sys.path was constructed some, because the way it was the system path 
>>> came before the virtualenv path, so a virtual distutils wouldn't be seen.
>> Cool. Where is the trunk SVN, by the way?
> 
> At http://svn.colorstudy.com/virtualenv/trunk

Thanks.  Here's a small bugfix:

Index: virtualenv.py
===================================================================
- --- virtualenv.py       (revision 3045)
+++ virtualenv.py       (working copy)
@@ -482,7 +482,7 @@
             call_subprocess(
                 ["install_name_tool", "-change",
                  os.path.join(sys.prefix, 'Python'),
- -                 os.path.abspath(os.path.join(frmdir, 'Python'))
+                 os.path.abspath(os.path.join(frmdir, 'Python')),
                  py_executable])
         except:
             logger.fatal(




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

iD8DBQFHC+7Z+gerLs4ltQ4RAsXtAJ0e1RNCYl1CuzeCv3L6RTv6ykGj1ACfXCFE
ieg5WNgGbMah4PDFAAzLAm0=
=8+ZX
-----END PGP SIGNATURE-----

From me at rpatterson.net  Thu Oct 11 02:24:39 2007
From: me at rpatterson.net (Ross Patterson)
Date: Wed, 10 Oct 2007 17:24:39 -0700
Subject: [Distutils] zc.buildout and ez_setup
Message-ID: <87wstuebw8.fsf@superfluity.lefae.org>

A projects which using ez_setup in its setup.py as described in:

http://peak.telecommunity.com/DevCenter/setuptools#id23

...seems not to play nicely with zc.buildout.

To reproduce make an empty directory and download ez_setup.py and
bootstrap.py into it:

http://peak.telecommunity.com/dist/ez_setup.py
http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py

Then make an empty setup.py::

    #!/usr/bin/env python
    import ez_setup
    ez_setup.use_setuptools()
    
    from setuptools import setup
    
    setup(name='foo')

Make an empty buildout.cfg::

    [buildout]
    develop = .

Then bootstrap buildout::

    $ python bootstrap.py -v

Finally run buildout.  Note that an error occurs importing ez_setup::
      
    $ bin/buildout -v
    Installing 'zc.buildout', 'setuptools'.
    We have the best distribution that satisfies 'zc.buildout'.
    Picked: zc.buildout = 1.0.0b30
    We have the best distribution that satisfies 'setuptools'.
    Picked: setuptools = 0.6c7
    Develop: '/tmp/foo/.'
    Traceback (most recent call last):
      File "/tmp/tmpsDYTIA", line 10, in ?
        execfile('/tmp/foo/./setup.py')
      File "/tmp/foo/./setup.py", line 2, in ?
        import ez_setup
    ImportError: No module named ez_setup
    While:
      Installing.
      Processing develop directory '/tmp/foo/.'.
    
    An internal error occured due to a bug in either zc.buildout or in a
    recipe being used:
    
    AssertionError:

Should I post this report anywhere else?

Ross


From jim at zope.com  Thu Oct 11 15:41:06 2007
From: jim at zope.com (Jim Fulton)
Date: Thu, 11 Oct 2007 09:41:06 -0400
Subject: [Distutils] zc.buildout and ez_setup
In-Reply-To: <87wstuebw8.fsf@superfluity.lefae.org>
References: <87wstuebw8.fsf@superfluity.lefae.org>
Message-ID: <25205AB3-D967-4EF6-B24D-FB4ECF657B09@zope.com>


On Oct 10, 2007, at 8:24 PM, Ross Patterson wrote:
...
> Should I post this report anywhere else?

Yes:

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

Jim

--
Jim Fulton
Zope Corporation



From tseaver at palladion.com  Thu Oct 11 22:07:30 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 11 Oct 2007 16:07:30 -0400
Subject: [Distutils] Dependency extensions
Message-ID: <felvpt$maj$1@sea.gmane.org>

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

I have use cases for a couple of extensions to how requirements are
spelled in a setuptools-enabled project.

Overriding Requirements
- -----------------------

I would like to be able to require package 'bar', but override one or
more of its dependencies (typically, 'bar' has over-strict version
qualifiers, which I need to relax).

I can imagine spelling such an override by including the overridden
project with a qualifier, e.g.: in foo/setup.py:

   install_requires=['bar',
                     '!baz==1.3', #override bar's spec of 1.2.4
                    ]

The "bang" here is borrowed loosely from CSS;  other spellings might be
clearer.

Another spelling might be to pass 'nodeps' or something as a suffix to
the overly-strict package, e,g,::

   install_requires=['bar (nodeps=baz)',
                     'baz==1.3',
                    ]


In general, I think the principal that the "most dependent" package wins
would be a reasonable policy, although not backward compatible at this
point.


Pinning Download Pages
- ----------------------

I would like to be able to "pin" a given package to a particular index /
download page, rather than searching the standard locations.

I could imagine either supplying the "pinned" find_url as a suffix, e.g.:

   install_requires=['baz (http://example.com/download-baz-here/)',
                    ]

Or else supplying a mapping which is used for the pinned URLs::

   install_requires=['baz'],
   pinned_urls={'baz': 'http://example.com/download-baz-here'}

The second might be easier to implement, but feels clunkier.

Thoughts?


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

iD8DBQFHDoKC+gerLs4ltQ4RAqR0AJ99D44ob2Od0WecAW05E+MGcDruOgCgo7zV
q7XZxbyhFeh9engIsX0p/Rs=
=9bFP
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Thu Oct 11 23:02:20 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 11 Oct 2007 17:02:20 -0400
Subject: [Distutils] Dependency extensions
In-Reply-To: <felvpt$maj$1@sea.gmane.org>
References: <felvpt$maj$1@sea.gmane.org>
Message-ID: <20071011205940.B464C3A407A@sparrow.telecommunity.com>

At 04:07 PM 10/11/2007 -0400, Tres Seaver wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I have use cases for a couple of extensions to how requirements are
>spelled in a setuptools-enabled project.

You should probably include them, then.  You only sent the 
specifications for how you'd like to implement *solutions* for the 
problems posed by your use cases.  ;-)

In other words, you didn't explain why it is you think you know 
better than the package owner what version his package needs, or why 
the existing dependency URL features don't do what you want.


From tseaver at palladion.com  Thu Oct 11 23:20:24 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 11 Oct 2007 17:20:24 -0400
Subject: [Distutils] Dependency extensions
In-Reply-To: <20071011205940.B464C3A407A@sparrow.telecommunity.com>
References: <felvpt$maj$1@sea.gmane.org>
	<20071011205940.B464C3A407A@sparrow.telecommunity.com>
Message-ID: <470E9398.5070207@palladion.com>

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

Phillip J. Eby wrote:
> At 04:07 PM 10/11/2007 -0400, Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I have use cases for a couple of extensions to how requirements are
>> spelled in a setuptools-enabled project.
> 
> You should probably include them, then.  You only sent the 
> specifications for how you'd like to implement *solutions* for the 
> problems posed by your use cases.  ;-)
> 
> In other words, you didn't explain why it is you think you know 
> better than the package owner what version his package needs, or why 
> the existing dependency URL features don't do what you want.


In the case of overrides, I have seen lots of cases where project
authors have overspecified dependencies in their requirements for a
given distribution, mostly because they don't want to have to support
their package configurations they don't test.  I'm fine with that line
of thought, as long as I have a way to reuse their packaged stuff in
combination with mine, where I *do* test with a different version than
they do:  in such a case, if my package can signal to setuptools that
*my* specification should win, I can use their code without forking a
new distribution.

Working around such a problem today typically requires hand-editing the
'requires.txt' for the over-strict package after installing it.  Setup
tools provides no way to install an over-strict package as a dependency
without propagating those constraints.

Pinning a package to a given repository is a common packaging
requirement (yum and apt both support it).  The driver there is the need
to maintain a "known good" configuration, where some packages (at least)
are installed from a repository whose maintainers are more reliable /
trustworthy than others.  (e.g., some maintainers are pretty sloppy
about re-releasing packages "in place", or even removing them).


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

iD8DBQFHDpOY+gerLs4ltQ4RAseJAJ0T16bFz/mLSPIZq95wUsGKBaUeiwCg1Ag2
RA+Q12lRKThc02ZHzy4dG2c=
=+0UV
-----END PGP SIGNATURE-----

From tseaver at palladion.com  Thu Oct 11 23:20:24 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 11 Oct 2007 17:20:24 -0400
Subject: [Distutils] Dependency extensions
In-Reply-To: <20071011205940.B464C3A407A@sparrow.telecommunity.com>
References: <felvpt$maj$1@sea.gmane.org>
	<20071011205940.B464C3A407A@sparrow.telecommunity.com>
Message-ID: <470E9398.5070207@palladion.com>

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

Phillip J. Eby wrote:
> At 04:07 PM 10/11/2007 -0400, Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I have use cases for a couple of extensions to how requirements are
>> spelled in a setuptools-enabled project.
> 
> You should probably include them, then.  You only sent the 
> specifications for how you'd like to implement *solutions* for the 
> problems posed by your use cases.  ;-)
> 
> In other words, you didn't explain why it is you think you know 
> better than the package owner what version his package needs, or why 
> the existing dependency URL features don't do what you want.


In the case of overrides, I have seen lots of cases where project
authors have overspecified dependencies in their requirements for a
given distribution, mostly because they don't want to have to support
their package configurations they don't test.  I'm fine with that line
of thought, as long as I have a way to reuse their packaged stuff in
combination with mine, where I *do* test with a different version than
they do:  in such a case, if my package can signal to setuptools that
*my* specification should win, I can use their code without forking a
new distribution.

Working around such a problem today typically requires hand-editing the
'requires.txt' for the over-strict package after installing it.  Setup
tools provides no way to install an over-strict package as a dependency
without propagating those constraints.

Pinning a package to a given repository is a common packaging
requirement (yum and apt both support it).  The driver there is the need
to maintain a "known good" configuration, where some packages (at least)
are installed from a repository whose maintainers are more reliable /
trustworthy than others.  (e.g., some maintainers are pretty sloppy
about re-releasing packages "in place", or even removing them).


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

iD8DBQFHDpOY+gerLs4ltQ4RAseJAJ0T16bFz/mLSPIZq95wUsGKBaUeiwCg1Ag2
RA+Q12lRKThc02ZHzy4dG2c=
=+0UV
-----END PGP SIGNATURE-----


From me at rpatterson.net  Fri Oct 12 05:08:02 2007
From: me at rpatterson.net (Ross Patterson)
Date: Thu, 11 Oct 2007 20:08:02 -0700
Subject: [Distutils] zc.buildout and ez_setup
References: <87wstuebw8.fsf@superfluity.lefae.org>
	<25205AB3-D967-4EF6-B24D-FB4ECF657B09@zope.com>
Message-ID: <878x6981yl.fsf@superfluity.lefae.org>

Jim Fulton <jim at zope.com> writes:

> On Oct 10, 2007, at 8:24 PM, Ross Patterson wrote:
> ...
>> Should I post this report anywhere else?
>
> Yes:
>
>    https://launchpad.net/zc.buildout/+filebug

Done.

Ross


From pje at telecommunity.com  Sat Oct 13 15:19:37 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 13 Oct 2007 09:19:37 -0400
Subject: [Distutils] Package in both setup_requires and install_requires
 will not be installed
In-Reply-To: <fcn3d0$p1f$1@sea.gmane.org>
References: <fchm0n$2da$1@sea.gmane.org>
 <fcn3d0$p1f$1@sea.gmane.org>
Message-ID: <20071013131657.5B1CC3A407A@sparrow.telecommunity.com>

At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
>Michael Hoffman wrote:
>
> > If you specify a package in setup_requires it will be built in the
> > current directory. But even if it is in install_requires as well, it
> > won't be installed because the requirement is already satisfied at setup
> > time by the package in the build directory.
>
>I came up with this workaround:
>
>from setuptools.command.install import install
>
>class SubprocessEasyInstall(install):
>      def run(self):
>          install.run(self)
>
>          args = [sys.executable, "-m", "easy_install"] + setup_requires
>          check_call(args)
>
>And in the setup() call, ensure you include:
>
>cmdclass=dict(install=SubprocessEasyInstall)
>
>This will easy_install the setup_requires in a separate process which is
>unpolluted by the distributions already downloaded during setup.

Don't do this.  It will do evil things if for example someone runs 
"setup.py install --help", or uses indeed any options or arguments to 
'install' at all.

It will also break the bdist_rpm, bdist_wininst, and other commands, 
which invoke 'install' as a subcommand, with various options set.


From b3i4old02 at sneakemail.com  Sat Oct 13 22:26:07 2007
From: b3i4old02 at sneakemail.com (Michael Hoffman)
Date: Sat, 13 Oct 2007 21:26:07 +0100
Subject: [Distutils] Package in both setup_requires and install_requires
 will not be installed
In-Reply-To: <20071013131657.5B1CC3A407A@sparrow.telecommunity.com>
References: <fchm0n$2da$1@sea.gmane.org> <fcn3d0$p1f$1@sea.gmane.org>
	<20071013131657.5B1CC3A407A@sparrow.telecommunity.com>
Message-ID: <fer9l3$jf7$1@ger.gmane.org>

Phillip J. Eby wrote:
> At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
>> Michael Hoffman wrote:
>>
>>> If you specify a package in setup_requires it will be built in the
>>> current directory. But even if it is in install_requires as well, it
>>> won't be installed because the requirement is already satisfied at setup
>>> time by the package in the build directory.
>> I came up with this workaround:
>>
>>from setuptools.command.install import install
>> class SubprocessEasyInstall(install):
>>      def run(self):
>>          install.run(self)
>>
>>          args = [sys.executable, "-m", "easy_install"] + setup_requires
>>          check_call(args)
>>
>> And in the setup() call, ensure you include:
>>
>> cmdclass=dict(install=SubprocessEasyInstall)
>>
>> This will easy_install the setup_requires in a separate process which is
>> unpolluted by the distributions already downloaded during setup.
> 
> Don't do this.  It will do evil things if for example someone runs 
> "setup.py install --help", or uses indeed any options or arguments to 
> 'install' at all.
> 
> It will also break the bdist_rpm, bdist_wininst, and other commands, 
> which invoke 'install' as a subcommand, with various options set.

Would you like to suggest a better workaround? I'd rather avoid doing 
this but the even consequences you outline are better to me than 
``setup.py install`` failing to install the specified prerequisites.

Thanks,
Michael


From pje at telecommunity.com  Sat Oct 13 23:36:53 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 13 Oct 2007 17:36:53 -0400
Subject: [Distutils] Package in both setup_requires and install_requires
 will not be installed
In-Reply-To: <fer9l3$jf7$1@ger.gmane.org>
References: <fchm0n$2da$1@sea.gmane.org> <fcn3d0$p1f$1@sea.gmane.org>
	<20071013131657.5B1CC3A407A@sparrow.telecommunity.com>
	<fer9l3$jf7$1@ger.gmane.org>
Message-ID: <20071013213417.118C43A407A@sparrow.telecommunity.com>

At 09:26 PM 10/13/2007 +0100, Michael Hoffman wrote:
>Phillip J. Eby wrote:
> > At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
> >> Michael Hoffman wrote:
> >>
> >>> If you specify a package in setup_requires it will be built in the
> >>> current directory. But even if it is in install_requires as well, it
> >>> won't be installed because the requirement is already satisfied at setup
> >>> time by the package in the build directory.
> >> I came up with this workaround:
> >>
> >>from setuptools.command.install import install
> >> class SubprocessEasyInstall(install):
> >>      def run(self):
> >>          install.run(self)
> >>
> >>          args = [sys.executable, "-m", "easy_install"] + setup_requires
> >>          check_call(args)
> >>
> >> And in the setup() call, ensure you include:
> >>
> >> cmdclass=dict(install=SubprocessEasyInstall)
> >>
> >> This will easy_install the setup_requires in a separate process which is
> >> unpolluted by the distributions already downloaded during setup.
> >
> > Don't do this.  It will do evil things if for example someone runs
> > "setup.py install --help", or uses indeed any options or arguments to
> > 'install' at all.
> >
> > It will also break the bdist_rpm, bdist_wininst, and other commands,
> > which invoke 'install' as a subcommand, with various options set.
>
>Would you like to suggest a better workaround?

Well, you could do something similar, but look at do_egg_install in 
setuptools.command.install to see how to construct a good command 
line for the child process.

The full fix is going to be a lot more complicated, unfortunately.


From b3i4old02 at sneakemail.com  Sat Oct 13 23:47:47 2007
From: b3i4old02 at sneakemail.com (Michael Hoffman)
Date: Sat, 13 Oct 2007 22:47:47 +0100
Subject: [Distutils] Package in both setup_requires and install_requires
 will not be installed
In-Reply-To: <20071013213417.118C43A407A@sparrow.telecommunity.com>
References: <fchm0n$2da$1@sea.gmane.org>
	<fcn3d0$p1f$1@sea.gmane.org>	<20071013131657.5B1CC3A407A@sparrow.telecommunity.com>	<fer9l3$jf7$1@ger.gmane.org>
	<20071013213417.118C43A407A@sparrow.telecommunity.com>
Message-ID: <feree8$ulp$1@ger.gmane.org>

Phillip J. Eby wrote:
> At 09:26 PM 10/13/2007 +0100, Michael Hoffman wrote:
>> Phillip J. Eby wrote:
>>> At 12:42 AM 9/18/2007 +0100, Michael Hoffman wrote:
>>>> Michael Hoffman wrote:
>>>>
>>>>> If you specify a package in setup_requires it will be built in the
>>>>> current directory. But even if it is in install_requires as well, it
>>>>> won't be installed because the requirement is already satisfied at setup
>>>>> time by the package in the build directory.
>>>> I came up with this workaround:
>>>>
>>> >from setuptools.command.install import install
>>>> class SubprocessEasyInstall(install):
>>>>      def run(self):
>>>>          install.run(self)
>>>>
>>>>          args = [sys.executable, "-m", "easy_install"] + setup_requires
>>>>          check_call(args)
>>>>
>>>> And in the setup() call, ensure you include:
>>>>
>>>> cmdclass=dict(install=SubprocessEasyInstall)
>>>>
>>>> This will easy_install the setup_requires in a separate process which is
>>>> unpolluted by the distributions already downloaded during setup.
>>> Don't do this.  It will do evil things if for example someone runs
>>> "setup.py install --help", or uses indeed any options or arguments to
>>> 'install' at all.
>>>
>>> It will also break the bdist_rpm, bdist_wininst, and other commands,
>>> which invoke 'install' as a subcommand, with various options set.
>> Would you like to suggest a better workaround?
> 
> Well, you could do something similar, but look at do_egg_install in 
> setuptools.command.install to see how to construct a good command 
> line for the child process.

Alright, I've added this to the to-do list for my app.

> The full fix is going to be a lot more complicated, unfortunately.

Yes, that's too bad.


From intothemist at gmail.com  Sun Oct 14 19:42:12 2007
From: intothemist at gmail.com (andy nicholson)
Date: Sun, 14 Oct 2007 19:42:12 +0200
Subject: [Distutils] error with bittorrent and twisted
Message-ID: <675946ff0710141042o34780169k76de9e2e557590f5@mail.gmail.com>

hi
im trying to package 5.0.9 bittorrent
(http://download.bittorrent.com/dl/) , as well as twisted (2.5) using
setuptools.

On install i get an error for bittorrent :

...
Searching for BitTorrent>=5.0,<6
Reading http://download.bittorrent.com/dl/
Best match: BitTorrent 5.0.9
Downloading http://download.bittorrent.com/dl/BitTorrent-5.0.9.tar.gz
Processing BitTorrent-5.0.9.tar.gz
Running BitTorrent-5.0.9/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-7A9E17/BitTorrent-5.0.9/egg-dist-tmp-1kUjWw
error: SandboxViolation: mkdir('/home/andy/.bittorrent', 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.
--

I get another error for Twisted :
Searching for Twisted>=2.5
Reading http://download.bittorrent.com/dl/
Reading http://cheeseshop.python.org/pypi/Twisted/
Reading http://twistedmatrix.com/
Reading http://cheeseshop.python.org/pypi/Twisted/2.5.0
Best match: Twisted 2.5.0
Downloading http://tmrc.mit.edu/mirror/twisted/Twisted/2.5/Twisted-2.5.0.tar.bz2
Processing Twisted-2.5.0.tar.bz2
Running Twisted-2.5.0/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-c7WTc2/Twisted-2.5.0/egg-dist-tmp-hIcXuu
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'bdist_egg'
Error: Subprocess exited with result 1 for project core
error: Setup script exited with 1

---

any hints?
thanks
-- 
Andy Nicholson

+44 774 733 4891 [ .uk ]

+61 406 306 715 [ .au ]

From exarkun at divmod.com  Mon Oct 15 20:40:29 2007
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Mon, 15 Oct 2007 14:40:29 -0400
Subject: [Distutils] error with bittorrent and twisted
In-Reply-To: <675946ff0710141042o34780169k76de9e2e557590f5@mail.gmail.com>
Message-ID: <20071015184029.8162.1784474688.divmod.quotient.23320@ohm>

On Sun, 14 Oct 2007 19:42:12 +0200, andy nicholson <intothemist at gmail.com> wrote:
> [snip]
>
>I get another error for Twisted :
>Searching for Twisted>=2.5
>Reading http://download.bittorrent.com/dl/
>Reading http://cheeseshop.python.org/pypi/Twisted/
>Reading http://twistedmatrix.com/
>Reading http://cheeseshop.python.org/pypi/Twisted/2.5.0
>Best match: Twisted 2.5.0
>Downloading http://tmrc.mit.edu/mirror/twisted/Twisted/2.5/Twisted-2.5.0.tar.bz2
>Processing Twisted-2.5.0.tar.bz2
>Running Twisted-2.5.0/setup.py -q bdist_egg --dist-dir
>/tmp/easy_install-c7WTc2/Twisted-2.5.0/egg-dist-tmp-hIcXuu
>usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>   or: setup.py --help [cmd1 cmd2 ...]
>   or: setup.py --help-commands
>   or: setup.py cmd --help
>
>error: invalid command 'bdist_egg'
>Error: Subprocess exited with result 1 for project core
>error: Setup script exited with 1
>
>---
>
>any hints?
>thanks

setuptools is not compatible with Twisted 2.5: 

  http://twistedmatrix.com/trac/ticket/1286

This could be fixed by making changes to Twisted's setup.py (as someone
has tried to do for #1286).  Other than this, I don't think there's
anything you can do to make it work.

Jean-Paul

From hjebbers at gmail.com  Tue Oct 16 00:22:21 2007
From: hjebbers at gmail.com (henk-jan ebbers)
Date: Tue, 16 Oct 2007 00:22:21 +0200
Subject: [Distutils] windows installer and setuptools
Message-ID: <4713E81D.1000300@gmail.com>

2 questions:

1. Can I use the (great) dependency handling of setuptools in a windows 
installer, eg by packing a python egg in a windows installer?

2. When I make a windows installer (bdist_wininst) I assumed the windows 
installer is python-version independent.  (BTW, I use setuptools.)
But, when making the installer with python 2.4, and installing with 
python 2.5, my package is installed in the right place (python 2.5), but 
the egg-info is installed as bots-1.1.0-py2.4.egg-info.
As far as I can see, this is not a problem for running my application.
But, is this how this is supposed to be?

--
Kind regard,
Henk-Jan Ebbers

From pje at telecommunity.com  Tue Oct 16 02:21:13 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 15 Oct 2007 20:21:13 -0400
Subject: [Distutils] windows installer and setuptools
In-Reply-To: <4713E81D.1000300@gmail.com>
References: <4713E81D.1000300@gmail.com>
Message-ID: <20071016001832.AD32F3A408F@sparrow.telecommunity.com>

At 12:22 AM 10/16/2007 +0200, henk-jan ebbers wrote:
>2 questions:
>
>1. Can I use the (great) dependency handling of setuptools in a windows
>installer, eg by packing a python egg in a windows installer?

No.  It's an either-or thing.  However, easy_install *can* resolve 
dependencies using bdist_wininst downloads.


>2. When I make a windows installer (bdist_wininst) I assumed the windows
>installer is python-version independent.  (BTW, I use setuptools.)
>But, when making the installer with python 2.4, and installing with
>python 2.5, my package is installed in the right place (python 2.5), but
>the egg-info is installed as bots-1.1.0-py2.4.egg-info.
>As far as I can see, this is not a problem for running my application.

It would be if something else depended on it.

>But, is this how this is supposed to be?

No.  Setuptools should always mark its windows installers as Python 
version-specific, as they are not portable, even if the package 
doesn't contain extensions.


From pje at telecommunity.com  Tue Oct 16 06:42:53 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 16 Oct 2007 00:42:53 -0400
Subject: [Distutils] windows installer and setuptools
In-Reply-To: <47143D97.803@gmail.com>
References: <4713E81D.1000300@gmail.com>
	<20071016001832.AD32F3A408F@sparrow.telecommunity.com>
	<47143D97.803@gmail.com>
Message-ID: <20071016044012.7CCE63A407C@sparrow.telecommunity.com>

At 06:27 AM 10/16/2007 +0200, henk-jan ebbers wrote:
>Phillip J. Eby wrote:
>>At 12:22 AM 10/16/2007 +0200, henk-jan ebbers wrote:
>>>2 questions:
>>>
>>>1. Can I use the (great) dependency handling of setuptools in a windows
>>>installer, eg by packing a python egg in a windows installer?
>>No.  It's an either-or thing.  However, easy_install *can* resolve 
>>dependencies using bdist_wininst downloads.
>>
>>>2. When I make a windows installer (bdist_wininst) I assumed the windows
>>>installer is python-version independent.  (BTW, I use setuptools.)
>>>But, when making the installer with python 2.4, and installing with
>>>python 2.5, my package is installed in the right place (python 2.5), but
>>>the egg-info is installed as bots-1.1.0-py2.4.egg-info.
>>>As far as I can see, this is not a problem for running my application.
>>It would be if something else depended on it.
>>
>>>But, is this how this is supposed to be?
>>No.  Setuptools should always mark its windows installers as Python 
>>version-specific, as they are not portable, even if the package 
>>doesn't contain extensions.
>Thanks for answering
>but is this an error?
>in disutils?

It's a setuptools error if it wrote the .exe without including py2.4 
in the filename.

Otherwise, it's operator error if you installed a py2.4 .exe into 
Python 2.5.  :)


From pje at telecommunity.com  Tue Oct 16 14:42:57 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 16 Oct 2007 08:42:57 -0400
Subject: [Distutils] windows installer and setuptools
In-Reply-To: <4714AEEB.5050205@gmail.com>
References: <4713E81D.1000300@gmail.com>
	<20071016001832.AD32F3A408F@sparrow.telecommunity.com>
	<47143D97.803@gmail.com>
	<20071016044012.7CCE63A407C@sparrow.telecommunity.com>
	<4714AEEB.5050205@gmail.com>
Message-ID: <20071016124016.34B913A408F@sparrow.telecommunity.com>

At 02:30 PM 10/16/2007 +0200, henk-jan ebbers wrote:
>But aren't python windows installers supposed to be python-version 
>independent?

Not if they contain extensions, or are built by setuptools.

>(but then, I do not understand why a (pure) python egg is version dependent).

1. Because it contains compiled bytecode, which is Python version dependent.
2. Because it may contain different contents or dependencies, based 
on the Python version.

#2 is also why setuptools builds version-dependent bdist_wininst installers.

(By the way, please stop emailing me off-list; I don't support 
setuptools except via the distutils-sig mailing list.)


From matt at matt-good.net  Wed Oct 17 05:03:25 2007
From: matt at matt-good.net (Matt Good)
Date: Tue, 16 Oct 2007 20:03:25 -0700
Subject: [Distutils] Dependency extensions
In-Reply-To: <470E9398.5070207@palladion.com>
References: <felvpt$maj$1@sea.gmane.org>
	<20071011205940.B464C3A407A@sparrow.telecommunity.com>
	<470E9398.5070207@palladion.com>
Message-ID: <C831C1ED-0BF8-428A-87D1-ED10EFD0793C@matt-good.net>

On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Phillip J. Eby wrote:
>> At 04:07 PM 10/11/2007 -0400, Tres Seaver wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I have use cases for a couple of extensions to how requirements are
>>> spelled in a setuptools-enabled project.
>>
>> You should probably include them, then.  You only sent the
>> specifications for how you'd like to implement *solutions* for the
>> problems posed by your use cases.  ;-)
>>
>> In other words, you didn't explain why it is you think you know
>> better than the package owner what version his package needs, or why
>> the existing dependency URL features don't do what you want.
>
>
> In the case of overrides, I have seen lots of cases where project
> authors have overspecified dependencies in their requirements for a
> given distribution, mostly because they don't want to have to support
> their package configurations they don't test.  I'm fine with that line
> of thought, as long as I have a way to reuse their packaged stuff in
> combination with mine, where I *do* test with a different version than
> they do

Just because you tested your app against "bar" 1.4 and "baz" 1.3  
doesn't mean that every feature of "bar" will work with "baz" 1.3.   
Another app could break because it uses a feature of "bar" that  
doesn't work with that version of "baz" and the authors of one of  
those packages will get the bug report about it instead of you.  If  
you're willing to help with the testing the author might be willing  
to relax the requirements, but trying to override another package's  
requirements is likely to lead to problems.

-- Matt

http://five.sentenc.es

From tseaver at palladion.com  Wed Oct 17 12:44:23 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 17 Oct 2007 06:44:23 -0400
Subject: [Distutils] Dependency extensions
In-Reply-To: <C831C1ED-0BF8-428A-87D1-ED10EFD0793C@matt-good.net>
References: <felvpt$maj$1@sea.gmane.org>	<20071011205940.B464C3A407A@sparrow.telecommunity.com>	<470E9398.5070207@palladion.com>
	<C831C1ED-0BF8-428A-87D1-ED10EFD0793C@matt-good.net>
Message-ID: <4715E787.80600@palladion.com>

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

Matt Good wrote:
> On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:
>
>> authors have overspecified dependencies in their requirements for a
>> given distribution, mostly because they don't want to have to support
>> their package configurations they don't test.  I'm fine with that line
>> of thought, as long as I have a way to reuse their packaged stuff in
>> combination with mine, where I *do* test with a different version than
>> they do
>
> Just because you tested your app against "bar" 1.4 and "baz" 1.3
> doesn't mean that every feature of "bar" will work with "baz" 1.3.
> Another app could break because it uses a feature of "bar" that
> doesn't work with that version of "baz" and the authors of one of
> those packages will get the bug report about it instead of you.  If
> you're willing to help with the testing the author might be willing
> to relax the requirements, but trying to override another package's
> requirements is likely to lead to problems.

I agree that this might be problematic in a setup where different
applications share the 'site-packages' directory.  Conflicts of this
sort drove the development of "virtual_python" / "virtualenv" setups,
which make it trivial to isolate separate applications' package sets.


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

iD8DBQFHFeeH+gerLs4ltQ4RAl4UAKDDZy32Tl2SWcdqzzP8U+QyWuKaAgCg0DuS
BoetwylWptg1HmAdcxGL8lo=
=Ys+B
-----END PGP SIGNATURE-----

From tseaver at palladion.com  Wed Oct 17 12:44:23 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 17 Oct 2007 06:44:23 -0400
Subject: [Distutils] Dependency extensions
In-Reply-To: <C831C1ED-0BF8-428A-87D1-ED10EFD0793C@matt-good.net>
References: <felvpt$maj$1@sea.gmane.org>	<20071011205940.B464C3A407A@sparrow.telecommunity.com>	<470E9398.5070207@palladion.com>
	<C831C1ED-0BF8-428A-87D1-ED10EFD0793C@matt-good.net>
Message-ID: <4715E787.80600@palladion.com>

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

Matt Good wrote:
> On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:
>
>> authors have overspecified dependencies in their requirements for a
>> given distribution, mostly because they don't want to have to support
>> their package configurations they don't test.  I'm fine with that line
>> of thought, as long as I have a way to reuse their packaged stuff in
>> combination with mine, where I *do* test with a different version than
>> they do
>
> Just because you tested your app against "bar" 1.4 and "baz" 1.3
> doesn't mean that every feature of "bar" will work with "baz" 1.3.
> Another app could break because it uses a feature of "bar" that
> doesn't work with that version of "baz" and the authors of one of
> those packages will get the bug report about it instead of you.  If
> you're willing to help with the testing the author might be willing
> to relax the requirements, but trying to override another package's
> requirements is likely to lead to problems.

I agree that this might be problematic in a setup where different
applications share the 'site-packages' directory.  Conflicts of this
sort drove the development of "virtual_python" / "virtualenv" setups,
which make it trivial to isolate separate applications' package sets.


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

iD8DBQFHFeeH+gerLs4ltQ4RAl4UAKDDZy32Tl2SWcdqzzP8U+QyWuKaAgCg0DuS
BoetwylWptg1HmAdcxGL8lo=
=Ys+B
-----END PGP SIGNATURE-----


From dobesv at gmail.com  Fri Oct 19 04:45:15 2007
From: dobesv at gmail.com (Dobes Vandermeer)
Date: Thu, 18 Oct 2007 19:45:15 -0700
Subject: [Distutils] setup.py develop and egg_info conflicting
Message-ID: <7324d9a20710181945m3c9c4d5dlaa3b22d6b5ccc6c4@mail.gmail.com>

If I do a setup.py develop, it installs a bunch of scripts I'm using.

Then, for deployment, I use setup.py egg_info --tag-svn-revision.

Unfortunately, now the scripts won't work; they report

pkg_resources.DistributionNotFound: ...

So I have to run setup.py develop again before I can use the scripts.

Is there a workaround for this?

From dobesv at gmail.com  Sat Oct 20 08:10:08 2007
From: dobesv at gmail.com (Dobes Vandermeer)
Date: Fri, 19 Oct 2007 23:10:08 -0700
Subject: [Distutils] "activate" script for virtualenv
In-Reply-To: <930E196B-7BB8-4490-8708-3E9CF41F56D5@matt-good.net>
References: <930E196B-7BB8-4490-8708-3E9CF41F56D5@matt-good.net>
Message-ID: <7324d9a20710192310k3b06b742ub84276859657d148@mail.gmail.com>

I thought virtualenv came with an activate/deactivate script - why not
run bin/activate and then deactivate when you're done?  Or am I
misunderstanding what you mean by virtualenv ?

On 9/28/07, Matt Good <matt at matt-good.net> wrote:
> I just set up a little script so that I can activate a particular
> virtualenv and easily exit it.  Basically it just invokes a new bash
> subshell and sets the PATH to include the current bin dir:
>
> mgood at sjl-dev1:~/python-envs/trac$ cat activate
> bash --init-file .bash_init
> mgood at sjl-dev1:~/python-envs/trac$ cat .bash_init
> . ~/.bash_profile
> export PATH="`pwd`/bin:$PATH"
>
> So running ./activate will set up your path in the subshell, and
> exiting will restore your normal PATH.  I don't really like running
> ~/.bash_profile again b/c I actually end up with it re-adding some
> stuff that's already in the PATH, but otherwise I lost my normal
> prompt coloring.  Someone with more bash-fu know how to fix that?
>
> mgood at sjl-dev1:~/python-envs/trac$ which python
> /usr/local/bin/python
> mgood at sjl-dev1:~/python-envs/trac$ ./activate
> mgood at sjl-dev1:~/python-envs/trac$ which python
> /home/mgood/python-envs/trac/bin/python
> mgood at sjl-dev1:~/python-envs/trac$ exit
> mgood at sjl-dev1:~/python-envs/trac$ which python
> /usr/local/bin/python
>
> -- Matt
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From matt at matt-good.net  Sun Oct 21 00:42:31 2007
From: matt at matt-good.net (Matt Good)
Date: Sat, 20 Oct 2007 15:42:31 -0700
Subject: [Distutils] "activate" script for virtualenv
In-Reply-To: <7324d9a20710192310k3b06b742ub84276859657d148@mail.gmail.com>
References: <930E196B-7BB8-4490-8708-3E9CF41F56D5@matt-good.net>
	<7324d9a20710192310k3b06b742ub84276859657d148@mail.gmail.com>
Message-ID: <C2EA550A-9A2E-4E37-9C8C-AB91D1480229@matt-good.net>

On Oct 19, 2007, at 11:10 PM, Dobes Vandermeer wrote:

> I thought virtualenv came with an activate/deactivate script - why not
> run bin/activate and then deactivate when you're done?  Or am I
> misunderstanding what you mean by virtualenv ?

It does now, but not at the time I wrote the script.  Thanks to Ian  
for adding that.

-- Matt

From pje at telecommunity.com  Tue Oct 23 02:08:38 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 22 Oct 2007 20:08:38 -0400
Subject: [Distutils] Dependency extensions
In-Reply-To: <4715E787.80600@palladion.com>
References: <felvpt$maj$1@sea.gmane.org>
	<20071011205940.B464C3A407A@sparrow.telecommunity.com>
	<470E9398.5070207@palladion.com>
	<C831C1ED-0BF8-428A-87D1-ED10EFD0793C@matt-good.net>
	<4715E787.80600@palladion.com>
Message-ID: <20071023000554.E79473A4069@sparrow.telecommunity.com>

At 06:44 AM 10/17/2007 -0400, Tres Seaver wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Matt Good wrote:
> > On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:
> >
> >> authors have overspecified dependencies in their requirements for a
> >> given distribution, mostly because they don't want to have to support
> >> their package configurations they don't test.  I'm fine with that line
> >> of thought, as long as I have a way to reuse their packaged stuff in
> >> combination with mine, where I *do* test with a different version than
> >> they do
> >
> > Just because you tested your app against "bar" 1.4 and "baz" 1.3
> > doesn't mean that every feature of "bar" will work with "baz" 1.3.
> > Another app could break because it uses a feature of "bar" that
> > doesn't work with that version of "baz" and the authors of one of
> > those packages will get the bug report about it instead of you.  If
> > you're willing to help with the testing the author might be willing
> > to relax the requirements, but trying to override another package's
> > requirements is likely to lead to problems.
>
>I agree that this might be problematic in a setup where different
>applications share the 'site-packages' directory.  Conflicts of this
>sort drove the development of "virtual_python" / "virtualenv" setups,
>which make it trivial to isolate separate applications' package sets.

Then perhaps such overrides should be used mainly for virtual 
environments, where you can prioritize *whose* requirements should 
take precedence.  That is, if you are installing 'foo' into a 
virtualenv intended only for the running of 'foo', then it might be 
reasonable for its requirements to take precedence.

However, ISTM that the "right" solution (for some value of "right") 
is that packagers who wish to overspecify their dependencies should 
create virtual packages for that purpose, rather than baking 
fixed-version requirements into the base package.


From graham.carlyle at maplecroft.net  Tue Oct 23 10:58:08 2007
From: graham.carlyle at maplecroft.net (Graham Carlyle)
Date: Tue, 23 Oct 2007 09:58:08 +0100
Subject: [Distutils] easy_install of django sdist tarball omits data files
Message-ID: <1193129888.12729.16.camel@charon>

Hi

I've been trying to install a sdist tarball of a django svn snapshot
using easy_install but some of the packages data files (the admin
contrib app templates) aren't being installed. I've looked at the
easy_install web page and can't see anything that may help me install
these data files.

I'm doing this as part of a deployment script that uses easy_install to
install a web apps dependencies into a particular directory. 

Is this a misuse of easy install? django's setup.py doesn't use
setuptools and so easy_install seems to be creating an sdist_egg on the
fly. I'm working round this by just scripting untarring, & "setup.py
install" etc. directly which is ok but it would be simpler if i could
just call easy_install for all my apps dependencies.

thanks,
Graham


From sklein at cpcug.org  Tue Oct 23 16:37:43 2007
From: sklein at cpcug.org (Stanley A. Klein)
Date: Tue, 23 Oct 2007 10:37:43 -0400 (EDT)
Subject: [Distutils] [Enthought-dev] Building Fedora RPMs
In-Reply-To: <471D2F1F.2050900@enthought.com>
References: <mailman.417.1193037737.10539.enthought-dev@mail.enthought.com> 
	<43295.207.188.248.157.1193075290.squirrel@www.cpcug.org> 
	<471CE9C1.4060009@enthought.com> 
	<35694.207.188.248.157.1193087767.squirrel@www.cpcug.org> 
	<471D2F1F.2050900@enthought.com>
Message-ID: <36288.207.188.248.157.1193150263.squirrel@www.cpcug.org>

On Mon, 2007-10-22 at 18:15 -0500, Dave Peterson wrote:
> Stanley A. Klein wrote:

> > Other failures included:
> >
> > endo - unpackaged pyc and pyo files (looks like a setup.py issue)
> >
>
> I get rpms built for this just fine.  Are you sure you have no local 
changes?
>

The problem with this one may be a setuptools issue.

The failure in doing the bdist_rpm is on a file endo.py, which is
identified to setuptools in the setup.py as a script.  The file is
originally in enthought/endo/scripts.  The pyc and pyo files get built
there properly because of the [install] optimize=1 option in setup.cfg.
However, the INSTALLED_FILES also lists a /usr/bin/endo.py without the pyc
and pyo files.  The Fedora rpm system causes those optimization files to
be built unbeknownst to setuptools, which then causes the installed but
unpackaged files error.

I tried declaring the pyc and pyo files in the script statement, but at
that point they don't exist and I got an error to that effect.

There is probably a workaround, like commenting out the scripts
statement in the setup.py and providing rpm a post-install script to copy
endo.* into /usr/bin.  However, it would create separate setup.py files
for rpm and non-rpm packaging.


Stan Klein


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20071023/ed5b2786/attachment.htm 

From pje at telecommunity.com  Tue Oct 23 17:28:19 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 23 Oct 2007 11:28:19 -0400
Subject: [Distutils] [Enthought-dev] Building Fedora RPMs
In-Reply-To: <36288.207.188.248.157.1193150263.squirrel@www.cpcug.org>
References: <mailman.417.1193037737.10539.enthought-dev@mail.enthought.com>
	<43295.207.188.248.157.1193075290.squirrel@www.cpcug.org>
	<471CE9C1.4060009@enthought.com>
	<35694.207.188.248.157.1193087767.squirrel@www.cpcug.org>
	<471D2F1F.2050900@enthought.com>
	<36288.207.188.248.157.1193150263.squirrel@www.cpcug.org>
Message-ID: <20071023152538.8DF4F3A40A4@sparrow.telecommunity.com>

At 10:37 AM 10/23/2007 -0400, Stanley A. Klein wrote:
>On Mon, 2007-10-22 at 18:15 -0500, Dave Peterson wrote:
> > Stanley A. Klein wrote:
>
> > > Other failures included:
> > >
> > > endo - unpackaged pyc and pyo files (looks like a setup.py issue)
> > >
> >
> > I get rpms built for this just fine.  Are you sure you have no local
>changes?
> >
>
>The problem with this one may be a setuptools issue.
>
>The failure in doing the bdist_rpm is on a file endo.py, which is
>identified to setuptools in the setup.py as a script.  The file is
>originally in enthought/endo/scripts.  The pyc and pyo files get built
>there properly because of the [install] optimize=1 option in setup.cfg.
>However, the INSTALLED_FILES also lists a /usr/bin/endo.py without the pyc
>and pyo files.  The Fedora rpm system causes those optimization files to
>be built unbeknownst to setuptools, which then causes the installed but
>unpackaged files error.
>
>I tried declaring the pyc and pyo files in the script statement, but at
>that point they don't exist and I got an error to that effect.
>
>There is probably a workaround, like commenting out the scripts
>statement in the setup.py and providing rpm a post-install script to copy
>endo.* into /usr/bin.  However, it would create separate setup.py files
>for rpm and non-rpm packaging.

Better still, take off the '.py' on the 'endo' script, and/or use 
setuptools' script generation support.


From dpeterson at enthought.com  Tue Oct 23 17:58:08 2007
From: dpeterson at enthought.com (Dave Peterson)
Date: Tue, 23 Oct 2007 10:58:08 -0500
Subject: [Distutils] [Enthought-dev] Building Fedora RPMs
In-Reply-To: <20071023152538.8DF4F3A40A4@sparrow.telecommunity.com>
References: <mailman.417.1193037737.10539.enthought-dev@mail.enthought.com>
	<43295.207.188.248.157.1193075290.squirrel@www.cpcug.org>
	<471CE9C1.4060009@enthought.com>
	<35694.207.188.248.157.1193087767.squirrel@www.cpcug.org>
	<471D2F1F.2050900@enthought.com>
	<36288.207.188.248.157.1193150263.squirrel@www.cpcug.org>
	<20071023152538.8DF4F3A40A4@sparrow.telecommunity.com>
Message-ID: <471E1A10.9010608@enthought.com>

Phillip J. Eby wrote:
> At 10:37 AM 10/23/2007 -0400, Stanley A. Klein wrote:
>> On Mon, 2007-10-22 at 18:15 -0500, Dave Peterson wrote:
>> > Stanley A. Klein wrote:
>>
>> > > Other failures included:
>> > >
>> > > endo - unpackaged pyc and pyo files (looks like a setup.py issue)
>> > >
>> >
>> > I get rpms built for this just fine.  Are you sure you have no local
>> changes?
>> >
>>
>> The problem with this one may be a setuptools issue.
>>
>> The failure in doing the bdist_rpm is on a file endo.py, which is
>> identified to setuptools in the setup.py as a script.  The file is
>> originally in enthought/endo/scripts.  The pyc and pyo files get built
>> there properly because of the [install] optimize=1 option in setup.cfg.
>> However, the INSTALLED_FILES also lists a /usr/bin/endo.py without 
>> the pyc
>> and pyo files.  The Fedora rpm system causes those optimization files to
>> be built unbeknownst to setuptools, which then causes the installed but
>> unpackaged files error.
>>
>> I tried declaring the pyc and pyo files in the script statement, but at
>> that point they don't exist and I got an error to that effect.
>>
>> There is probably a workaround, like commenting out the scripts
>> statement in the setup.py and providing rpm a post-install script to 
>> copy
>> endo.* into /usr/bin.  However, it would create separate setup.py files
>> for rpm and non-rpm packaging.
>
> Better still, take off the '.py' on the 'endo' script, and/or use 
> setuptools' script generation support.
>
I'll take a stab at switching it to use the setuptools script support.

-- Dave


From dpeterson at enthought.com  Tue Oct 23 21:03:00 2007
From: dpeterson at enthought.com (Dave Peterson)
Date: Tue, 23 Oct 2007 14:03:00 -0500
Subject: [Distutils] [Enthought-dev] Building Fedora RPMs
In-Reply-To: <20071023152538.8DF4F3A40A4@sparrow.telecommunity.com>
References: <mailman.417.1193037737.10539.enthought-dev@mail.enthought.com>
	<43295.207.188.248.157.1193075290.squirrel@www.cpcug.org>
	<471CE9C1.4060009@enthought.com>
	<35694.207.188.248.157.1193087767.squirrel@www.cpcug.org>
	<471D2F1F.2050900@enthought.com>
	<36288.207.188.248.157.1193150263.squirrel@www.cpcug.org>
	<20071023152538.8DF4F3A40A4@sparrow.telecommunity.com>
Message-ID: <471E4564.6060606@enthought.com>

Phillip J. Eby wrote:
> At 10:37 AM 10/23/2007 -0400, Stanley A. Klein wrote:
>> On Mon, 2007-10-22 at 18:15 -0500, Dave Peterson wrote:
>> > Stanley A. Klein wrote:
>>
>> > > Other failures included:
>> > >
>> > > endo - unpackaged pyc and pyo files (looks like a setup.py issue)
>> > >
>> >
>> > I get rpms built for this just fine.  Are you sure you have no local
>> changes?
>> >
>>
>> The problem with this one may be a setuptools issue.
>>
>> The failure in doing the bdist_rpm is on a file endo.py, which is
>> identified to setuptools in the setup.py as a script.  The file is
>> originally in enthought/endo/scripts.  The pyc and pyo files get built
>> there properly because of the [install] optimize=1 option in setup.cfg.
>> However, the INSTALLED_FILES also lists a /usr/bin/endo.py without 
>> the pyc
>> and pyo files.  The Fedora rpm system causes those optimization files to
>> be built unbeknownst to setuptools, which then causes the installed but
>> unpackaged files error.
>>
>> I tried declaring the pyc and pyo files in the script statement, but at
>> that point they don't exist and I got an error to that effect.
>>
>> There is probably a workaround, like commenting out the scripts
>> statement in the setup.py and providing rpm a post-install script to 
>> copy
>> endo.* into /usr/bin.  However, it would create separate setup.py files
>> for rpm and non-rpm packaging.
>
> Better still, take off the '.py' on the 'endo' script, and/or use 
> setuptools' script generation support.
>

Thanks for pointing that out! 

I've just gotten the time to try modifing the endo project to use the 
setuptools' script generation -- went pretty easily btw.   I can now 
successfully do a bdist_rpm on my CentOS5 system.

-- Dave




From sklein at cpcug.org  Tue Oct 23 21:11:58 2007
From: sklein at cpcug.org (Stanley A. Klein)
Date: Tue, 23 Oct 2007 15:11:58 -0400 (EDT)
Subject: [Distutils] [Enthought-dev] Building Fedora RPMs
In-Reply-To: <471E1A10.9010608@enthought.com>
References: <mailman.417.1193037737.10539.enthought-dev@mail.enthought.com>
	<43295.207.188.248.157.1193075290.squirrel@www.cpcug.org>
	<471CE9C1.4060009@enthought.com>
	<35694.207.188.248.157.1193087767.squirrel@www.cpcug.org>
	<471D2F1F.2050900@enthought.com>
	<36288.207.188.248.157.1193150263.squirrel@www.cpcug.org>
	<20071023152538.8DF4F3A40A4@sparrow.telecommunity.com>
	<471E1A10.9010608@enthought.com>
Message-ID: <39540.207.188.248.157.1193166718.squirrel@www.cpcug.org>


On Tue, October 23, 2007 11:58 am, Dave Peterson wrote:
> Phillip J. Eby wrote:
>> At 10:37 AM 10/23/2007 -0400, Stanley A. Klein wrote:
>>> On Mon, 2007-10-22 at 18:15 -0500, Dave Peterson wrote:
>>> > Stanley A. Klein wrote:
>>>
>>> > > Other failures included:
>>> > >
>>> > > endo - unpackaged pyc and pyo files (looks like a setup.py issue)
>>> > >
>>> >
>>> > I get rpms built for this just fine.  Are you sure you have no local
>>> changes?
>>> >
>>>
>>> The problem with this one may be a setuptools issue.
>>>
>>> The failure in doing the bdist_rpm is on a file endo.py, which is
>>> identified to setuptools in the setup.py as a script.  The file is
>>> originally in enthought/endo/scripts.  The pyc and pyo files get built
>>> there properly because of the [install] optimize=1 option in setup.cfg.
>>> However, the INSTALLED_FILES also lists a /usr/bin/endo.py without
>>> the pyc
>>> and pyo files.  The Fedora rpm system causes those optimization files
>>> to
>>> be built unbeknownst to setuptools, which then causes the installed but
>>> unpackaged files error.
>>>
>>> I tried declaring the pyc and pyo files in the script statement, but at
>>> that point they don't exist and I got an error to that effect.
>>>
>>> There is probably a workaround, like commenting out the scripts
>>> statement in the setup.py and providing rpm a post-install script to
>>> copy
>>> endo.* into /usr/bin.  However, it would create separate setup.py files
>>> for rpm and non-rpm packaging.
>>
>> Better still, take off the '.py' on the 'endo' script, and/or use
>> setuptools' script generation support.
>>
> I'll take a stab at switching it to use the setuptools script support.


>From what Phillip says, all it might require is changing the name from
endo.py to endo in both enthought/endo/scripts and the script statement in
the setup.py file.  The file already has a #!/usr/bin/python as its first
line, so I think it can run as a command without producing the .pyo and
.pyc files in /usr/bin that bother SE-Linux.

I tried to do that and build the package, but I ran into problems of svn
and setuptools remembering what was there before and I got worse errors.
:-(  I've had problems like that before.


Stan Klein


-- 



From optilude at gmx.net  Thu Oct 25 02:28:14 2007
From: optilude at gmx.net (Martin Aspeli)
Date: Thu, 25 Oct 2007 01:28:14 +0100
Subject: [Distutils] buildout and console scripts in dependencies
Message-ID: <ffonvg$fi2$1@ger.gmane.org>

Hi,

I have a buildout which looks like this:

[buildout]
parts =
     repoze

find-links =
     http://dist.repoze.org

eggs =
     repoze.plone

develop =

[repoze]
recipe = zc.recipe.egg
eggs =
     ${buildout:eggs}

Here, repoze.plone is an egg depending on a bunch of other eggs. Some of 
those dependencies, such as PasteScript and repoze.zope2, have 
console_scripts entry points.

With the buildout above, I don't get any console scripts though. To get 
that, I have ot list the eggs with dependencies explicitly in the 
zc.recipe.egg part:

[buildout]
parts =
     repoze

find-links =
     http://dist.repoze.org

eggs =
     repoze.plone

develop =

[repoze]
recipe = zc.recipe.egg
eggs =
     ${buildout:eggs}
     repoze.zope2
     PasteScript

Is this a bug or feature? It's certainly a bit annoying, since I now 
have to work out which packages have the console scripts I need. :)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


From jim at zope.com  Thu Oct 25 15:29:17 2007
From: jim at zope.com (Jim Fulton)
Date: Thu, 25 Oct 2007 09:29:17 -0400
Subject: [Distutils] buildout and console scripts in dependencies
In-Reply-To: <ffonvg$fi2$1@ger.gmane.org>
References: <ffonvg$fi2$1@ger.gmane.org>
Message-ID: <A06755F8-AFB2-4051-9333-F882AF7C0C4A@zope.com>


On Oct 24, 2007, at 8:28 PM, Martin Aspeli wrote:
...
> Is this a bug or feature? It's certainly a bit annoying, since I now
> have to work out which packages have the console scripts I need. :)

This is a feature.  I would fine it annoying to have dependency  
scripts implicitly installed.

Generally, I would expect you to know which scripts you "need",   
<shrug/>

If someone wants to add a feature to install scripts fro  
dependencies, I would not object, but I can't justify spending time  
on this myself.

Jim

--
Jim Fulton
Zope Corporation



From pje at telecommunity.com  Fri Oct 26 04:25:23 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 25 Oct 2007 22:25:23 -0400
Subject: [Distutils] Setuptools pydoc problem
In-Reply-To: <4720C090.2000507@colorstudy.com>
References: <4720C090.2000507@colorstudy.com>
Message-ID: <20071026022238.D1A063A4093@sparrow.telecommunity.com>

At 11:13 AM 10/25/2007 -0500, Ian Bicking wrote:
>I'm getting this error with setuptools trunk and pydoc/help():
>
>>>>>import unittest
>>>>>help(unittest.main)
>>Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>   File 
>> "/usr/lib/python2.4/site-packages/setuptools-0.6c7-2.4.egg/site.py" 
>> , line 339, in __call__
>>
>>   File 
>> "/home/ianb/env/webdev/lib/python2.4/setuptools-0.7a1dev_r58373-py2.4.egg/pydoc.py", 
>> line 1645, in __call__
>>     self.help(request)
>>   File 
>> "/home/ianb/env/webdev/lib/python2.4/setuptools-0.7a1dev_r58373-py2.4.egg/pydoc.py", 
>> line 1689, in help
>>     else: doc(request, 'Help on %s:')
>>   File 
>> "/home/ianb/env/webdev/lib/python2.4/setuptools-0.7a1dev_r58373-py2.4.egg/pydoc.py", 
>> line 1468, in doc
>>     desc = describe(object)
>>   File 
>> "/home/ianb/env/webdev/lib/python2.4/setuptools-0.7a1dev_r58373-py2.4.egg/pydoc.py", 
>> line 1413, in describe
>>     if inspect.isgetsetdescriptor(thing):
>>AttributeError: 'module' object has no attribute 'isgetsetdescriptor'
>
>I'm guessing its something in Python 2.5's inspect but not 2.4.

Fixed.  (Please don't send setuptools bug reports to me in private 
email; the distutils-sig is where they go, to minimize duplicates, 
have a public record, and at least entertain the possibility that 
someone else might know of a fix, workaround, or be able to 
contribute a patch.)


From tim.terlegard at valentinewebsystems.se  Thu Oct 25 18:13:13 2007
From: tim.terlegard at valentinewebsystems.se (=?ISO-8859-1?Q?TIm_Terleg=E5rd?=)
Date: Thu, 25 Oct 2007 18:13:13 +0200
Subject: [Distutils] zc.buildout installing parts not asked for
Message-ID: <E0E52BB9-C3D8-4CED-A09E-0D7BF41B179E@valentinewebsystems.se>

When using zc.buildout I discovered that it installed a part that I  
didn't
specify in the 'parts' option. This happened because I referenced this
part somewhere else. Is this how it's supposed to be? I would prefer  
if it
only installs the parts I specify in parts. I don't see anything  
wrong with
reusing options from a part that I don't necessarily want to install.

This is a buildout.cfg that will reproduce it. The 'notusedinparts'  
part is
installed even if not specified in 'parts'. It's installed because of  
the
'dummy' option in the 'tok' section. Is this how it was meant to be?

[buildout]
develop = recipes
parts = tok

[tok]
recipe = recipes:debug
dummy = ${notusedinparts:someoption}

[notusedinparts]
recipe = recipes:debug
someoption = why

/Tim

From jim at zope.com  Sun Oct 28 14:24:42 2007
From: jim at zope.com (Jim Fulton)
Date: Sun, 28 Oct 2007 09:24:42 -0400
Subject: [Distutils] zc.buildout installing parts not asked for
In-Reply-To: <E0E52BB9-C3D8-4CED-A09E-0D7BF41B179E@valentinewebsystems.se>
References: <E0E52BB9-C3D8-4CED-A09E-0D7BF41B179E@valentinewebsystems.se>
Message-ID: <919DA7E8-AFC7-411E-AEE2-6A36AB9A7D93@zope.com>


On Oct 25, 2007, at 12:13 PM, TIm Terleg?rd wrote:

> When using zc.buildout I discovered that it installed a part that I
> didn't
> specify in the 'parts' option. This happened because I referenced this
> part somewhere else. Is this how it's supposed to be?

Yes.

Jim

--
Jim Fulton
Zope Corporation



From skip at pobox.com  Sun Oct 28 15:57:55 2007
From: skip at pobox.com (Skip Montanaro)
Date: Sun, 28 Oct 2007 14:57:55 +0000 (UTC)
Subject: [Distutils] Distributing doc files w/ distutils src pkg?
Message-ID: <loom.20071028T145655-610@post.gmane.org>

I have a simple setup.py file:

    #!/usr/bin/env python

    from distutils.core import setup
    setup(name='lockfile',
          author='Skip Montanaro',
          author_email='skip <at> pobox.com',
          maintainer='Skip Montanaro',
          maintainer_email='skip <at> pobox.com',
          url='http://www.webfast.com/~skip/python/',
          download_url='http://www.webfast.com/~skip/python/lockfile.tar.gz',
          version='0.1',
          py_modules=['lockfile'],
          data_files=[('doc', ['lockfile.rst'])],
          )

I've used the data_files arg to setup to note where the docs live.  Alas,
the sdist command doesn't include this in the tar file:

    % tar tfz dist/lockfile-0.1.tar.gz 
    lockfile-0.1/
    lockfile-0.1/lockfile.py
    lockfile-0.1/PKG-INFO
    lockfile-0.1/README
    lockfile-0.1/setup.py

I'm a complete distutils novice.  I can't for the life of me understand why
the doc directory isn't included in the tar file.  As far as I can tell
distutils has no explicit provision at all for distributing documentation,
which seems very weird.  What am I missing?




From tseaver at palladion.com  Sun Oct 28 16:58:05 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Sun, 28 Oct 2007 11:58:05 -0400
Subject: [Distutils] Distributing doc files w/ distutils src pkg?
In-Reply-To: <loom.20071028T145655-610@post.gmane.org>
References: <loom.20071028T145655-610@post.gmane.org>
Message-ID: <4724B18D.2090400@palladion.com>

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

Skip Montanaro wrote:
> I have a simple setup.py file:
> 
>     #!/usr/bin/env python
> 
>     from distutils.core import setup
>     setup(name='lockfile',
>           author='Skip Montanaro',
>           author_email='skip <at> pobox.com',
>           maintainer='Skip Montanaro',
>           maintainer_email='skip <at> pobox.com',
>           url='http://www.webfast.com/~skip/python/',
>           download_url='http://www.webfast.com/~skip/python/lockfile.tar.gz',
>           version='0.1',
>           py_modules=['lockfile'],
>           data_files=[('doc', ['lockfile.rst'])],
>           )
> 
> I've used the data_files arg to setup to note where the docs live.  Alas,
> the sdist command doesn't include this in the tar file:
> 
>     % tar tfz dist/lockfile-0.1.tar.gz 
>     lockfile-0.1/
>     lockfile-0.1/lockfile.py
>     lockfile-0.1/PKG-INFO
>     lockfile-0.1/README
>     lockfile-0.1/setup.py
> 
> I'm a complete distutils novice.  I can't for the life of me understand why
> the doc directory isn't included in the tar file.  As far as I can tell
> distutils has no explicit provision at all for distributing documentation,
> which seems very weird.  What am I missing?

Not a thing:  you are exactly correct (I don't understand it either).


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

iD8DBQFHJLGN+gerLs4ltQ4RAubwAKC/3EqMdGrsYZW4ylmNU43wgrocygCgxw0X
4xXPGbsC6mEP5TCJl/+W7yk=
=veTk
-----END PGP SIGNATURE-----

From tseaver at palladion.com  Sun Oct 28 16:58:05 2007
From: tseaver at palladion.com (Tres Seaver)
Date: Sun, 28 Oct 2007 11:58:05 -0400
Subject: [Distutils] Distributing doc files w/ distutils src pkg?
In-Reply-To: <loom.20071028T145655-610@post.gmane.org>
References: <loom.20071028T145655-610@post.gmane.org>
Message-ID: <4724B18D.2090400@palladion.com>

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

Skip Montanaro wrote:
> I have a simple setup.py file:
> 
>     #!/usr/bin/env python
> 
>     from distutils.core import setup
>     setup(name='lockfile',
>           author='Skip Montanaro',
>           author_email='skip <at> pobox.com',
>           maintainer='Skip Montanaro',
>           maintainer_email='skip <at> pobox.com',
>           url='http://www.webfast.com/~skip/python/',
>           download_url='http://www.webfast.com/~skip/python/lockfile.tar.gz',
>           version='0.1',
>           py_modules=['lockfile'],
>           data_files=[('doc', ['lockfile.rst'])],
>           )
> 
> I've used the data_files arg to setup to note where the docs live.  Alas,
> the sdist command doesn't include this in the tar file:
> 
>     % tar tfz dist/lockfile-0.1.tar.gz 
>     lockfile-0.1/
>     lockfile-0.1/lockfile.py
>     lockfile-0.1/PKG-INFO
>     lockfile-0.1/README
>     lockfile-0.1/setup.py
> 
> I'm a complete distutils novice.  I can't for the life of me understand why
> the doc directory isn't included in the tar file.  As far as I can tell
> distutils has no explicit provision at all for distributing documentation,
> which seems very weird.  What am I missing?

Not a thing:  you are exactly correct (I don't understand it either).


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

iD8DBQFHJLGN+gerLs4ltQ4RAubwAKC/3EqMdGrsYZW4ylmNU43wgrocygCgxw0X
4xXPGbsC6mEP5TCJl/+W7yk=
=veTk
-----END PGP SIGNATURE-----


From pje at telecommunity.com  Sun Oct 28 20:48:33 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 28 Oct 2007 15:48:33 -0400
Subject: [Distutils] Distributing doc files w/ distutils src pkg?
In-Reply-To: <loom.20071028T145655-610@post.gmane.org>
References: <loom.20071028T145655-610@post.gmane.org>
Message-ID: <20071028194546.3B5813A4069@sparrow.telecommunity.com>

At 02:57 PM 10/28/2007 +0000, Skip Montanaro wrote:
>I have a simple setup.py file:
>
>     #!/usr/bin/env python
>
>     from distutils.core import setup
>     setup(name='lockfile',
>           author='Skip Montanaro',
>           author_email='skip <at> pobox.com',
>           maintainer='Skip Montanaro',
>           maintainer_email='skip <at> pobox.com',
>           url='http://www.webfast.com/~skip/python/',
>           download_url='http://www.webfast.com/~skip/python/lockfile.tar.gz',
>           version='0.1',
>           py_modules=['lockfile'],
>           data_files=[('doc', ['lockfile.rst'])],
>           )
>
>I've used the data_files arg to setup to note where the docs live.  Alas,
>the sdist command doesn't include this in the tar file:
>
>     % tar tfz dist/lockfile-0.1.tar.gz
>     lockfile-0.1/
>     lockfile-0.1/lockfile.py
>     lockfile-0.1/PKG-INFO
>     lockfile-0.1/README
>     lockfile-0.1/setup.py
>
>I'm a complete distutils novice.  I can't for the life of me understand why
>the doc directory isn't included in the tar file.  As far as I can tell
>distutils has no explicit provision at all for distributing documentation,
>which seems very weird.  What am I missing?

A MANIFEST.in file specifying what to include.  Distutils requires 
one for docs.  Note that the data_files option is for *installing* 
data files to e.g. /usr/share; if you're doing that you should 
probably have a bit more structure to what you install there than 
just dumping lockfile.rst in /usr/share/doc (which is what I think 
the above setup does).

Distutils isn't very bright about putting things in an sdist unless 
you specify them in MANIFEST.in in some way.  Setuptools is a bit 
smarter, in that it includes stuff under revision control (CVS, svn, 
or anything you've installed a file finder plugin for.)


From skip at pobox.com  Sun Oct 28 23:36:05 2007
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 28 Oct 2007 17:36:05 -0500
Subject: [Distutils] Distributing doc files w/ distutils src pkg?
In-Reply-To: <20071028194546.3B5813A4069@sparrow.telecommunity.com>
References: <loom.20071028T145655-610@post.gmane.org>
	<20071028194546.3B5813A4069@sparrow.telecommunity.com>
Message-ID: <18213.3797.358938.559489@montanaro.dyndns.org>


    >> What am I missing? [from my distutils setup]

    Phillip> A MANIFEST.in file specifying what to include.  

Thanks.  I came up with this:

    include README MANIFEST lockfile.py setup.py
    recursive-include doc *.rst

which seems to build a proper .tar.gz file.

Skip

From ben at benfinney.id.au  Mon Oct 29 03:39:13 2007
From: ben at benfinney.id.au (Ben Finney)
Date: Mon, 29 Oct 2007 13:39:13 +1100
Subject: [Distutils] patch: Unused import of 'shutil'
Message-ID: <87sl3ufxv2.fsf@benfinney.id.au>

Howdy all,

As of version 0.6c7 (and likely earlier), 'ez_setup.py' causes
'pyflakes' to emit two warnings::

    $ pyflakes ./ez_setup.py
    ./ez_setup.py:117: 'shutil' imported but unused
    ./ez_setup.py:181: redefinition of unused 'main' from line 179

The latter is due to 'pyflakes' not handling an ImportError-based
import fallback, as documented in ticket 1499 in the pyflakes Trac
<URL:http://divmod.org/trac/ticket/1499>.

The former is fixed with this patch:

--- ez_setup.py 2007-10-29 13:36:24.000000000 +1100
+++ ez_setup.py 2007-10-29 13:36:37.000000000 +1100
@@ -114,7 +114,7 @@
     with a '/'). `to_dir` is the directory where the egg will be downloaded.
     `delay` is the number of seconds to pause before an actual download attempt.
     """
-    import urllib2, shutil
+    import urllib2
     egg_name = "setuptools-%s-py%s.egg" % (version,sys.version[:3])
     url = download_base + egg_name
     saveto = os.path.join(to_dir, egg_name)


-- 
 \      "Reichel's Law: A body on vacation tends to remain on vacation |
  `\         unless acted upon by an outside force."  -- Carol Reichel |
_o__)                                                                  |
Ben Finney


From ianb at colorstudy.com  Tue Oct 30 17:24:34 2007
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 30 Oct 2007 11:24:34 -0500
Subject: [Distutils] Object loading spec
Message-ID: <47275AC2.7040703@colorstudy.com>

I mentioned some time ago that it would be nice if everyone could agree 
how to configure object references.  Mostly I just had in mind having 
Paste Deploy and zc.buildout use the same syntax, but it's something 
that comes up in ad hoc situations often as well.

I wrote up a small implementation to push this idea forward a bit.  I'm 
hoping to get some feedback here.  In an unfortunate mishmash of 
syllables (name suggestions welcome) I named it obconfloader.  You can 
read the description here:
   http://svn.pythonpaste.org/ObConfLoader/trunk/docs/index.txt

I've also copied that description into this email.


Status & License
----------------

ObConfLoader is under an `MIT-style permissive license
<http://svn.pythonpaste.org/ObConfLoader/trunk/docs/license.txt>`_.
Discussion should occur on `distutils-sig
<http://www.python.org/community/sigs/current/distutils-sig/>`_;
please be sure to put "ObConfLoader" in the subject line.

The package is available in a `subversion repository
<http://svn.pythonpaste.org/ObConfLoader/trunk#egg=ObConfLoader>`_,
and the trunk can be installed with ``easy_install
ObConfLoader==dev``.  You can get a checkout with::

   svn co http://svn.pythonpaste.org/ObConfLoader/trunk ObConfLoader

Introduction
------------

ObConfLoader allows you to load objects from strings, typically for
use in config files (or from the command line, or other locations
where object references are necessary but the format is constrained).

It also allows you to utilize `Setuptools entry points
<http://peak.telecommunity.com/DevCenter/setuptools#entry-points>`_ to
make public objects that can be referenced.  The concept of an entry
point group, or API, allows backward compatibility when using entry
points.

The basic usage is very simple::

     from obconfloader import load_ob
     obj, ep_group = load_ob(a_string, ['mypackage.api'])
     assert ep_group is None or ep_group == 'mypackage.api'

This loads the object from the given string, returning the object and
the API it supports.  The second argument is a list of entry point
groups that you support.

You can support multiple entry point groups, or no groups (by leaving
out the second argument, or using None).  If you leave out the second
argument ``ep_group`` will always be None.

There are several possible exceptions:

``LoadError``:
     The parent of all other exceptions; a generic error.

``ConfigSyntaxError``:
     The string itself is malformed.

``BadGroupError``:
     The group given doesn't match up with an acceptable input group.

``NotFoundError``:
     The referenced object can't be found (something like
     DistributionNotFound, ImportError, AttributeError).

``PythonError``:
     Some error with a Python expression, Python syntax, etc.

Specification Format
--------------------

There are several formats for strings:

``file /path/to/file.py``
     This loads the given file, and returns the module object.

``file /path/to/file.py:dotted.name``
     This loads the given file, and returns the object ``dotted.name``
     inside it.

``file /path/to/file.py:dotted.name [entry.point.group]``
     This loads the object, and indicates that the object supports the
     group ``entry.point.group``.  This can be used when multiple APIs
     are supported, and the object doesn't use the default API.

``python module.name:dotted.name``
     This loads the module ``module.name``, and returns the
     ``dotted.name`` object.  Of course you can leave out
     ``dotted.name`` to return the module, and also add an entry point
     group.

``egg Distribution``
     This loads the distribution (the package) ``Distribution``, and
     gets the ``main`` entry point, with the given entry point group.

``egg Distribution:entry_point_name``
     Instead of the ``main`` entry point, this gets
     ``entry_point_name``.

Other Schemes
-------------

You can pass in a dictionary of extra schemes (besides ``file``,
``python``, and ``egg``) with the ``extra_schemes`` argument.  All
schemes are converted to lower case.  The signature of a loader is::

     def scheme_loader(string, groups, orig_string, position, group):
         if problem:
             raise LoadError("message", orig_string, position)
         return loaded_obj, group

The meaning of the arguments:

``string``:
     The string you should load, like
     ``"/path/to/file.py:dotted.name"``.  This leaves out the trailing
     group and the scheme.

``groups``:
     The entry point groups accepted.  Schemes besides ``egg`` probably
     will ignore this.

``orig_string``:
     The full string, with scheme.  Used primarily with any
     ``LoadError`` exceptions, to give the user back the full string
     they entered.

``position``:
     The position where the string was found; also used with
     exceptions.

``group``:
     If the string contained an explicit group, this will be that group
     (otherwise None).  If you don't have any explicit notion of groups
     then you can just do the return as in the example.

You should raise LoadError exceptions when at all possible; failures
generally *are* expected.

Open Issues
-----------

* Just using a different data source (like a database) for Python code
   instead of a file isn't super-easy (you'd have to provide some kind
   of extra scheme).  Maybe a little refactoring of ``load_file`` would
   make it easier.

* Possibly ``load_file`` itself should have some resource-finding
   pluggability.  This could be used to restrict the files that can be
   accessed.

* Disabling a scheme by setting ``extra_schemes=dict(file=None)``
   would be handy, but isn't clean now.

* The form ``python module.name.object.name`` *looks* reasonable, but it
   has to be ``python module.name:object.name``.  The error message
   isn't very helpful either (basically an import error).  Probably it
   should Just Work.

* I don't scan the system for extra kinds of schemes.  No
   pluggability.  I am shying away from doing complete entry point
   scans (e.g., with ``pkg_resources.iter_entry_points``) because of
   efficiency concerns.

* There's no way to indicate an egg entry point name without
   distribution.  Maybe ``egg *:ep_name`` should be allowed?  This is
   inefficient, but the ``*`` makes it *look* inefficient too.

* Should an implied scheme be allowed?  E.g., something like Buffet
   (a template abstraction layer) basically needs an object reference
   to the renderer.  Right now this *must* be an egg/entry point, but
   there's no reason it couldn't use other kinds of references.  But
   the ideal specification would just be ``Distribution``, not ``egg
   Distribution``.  A default scheme of egg would fix this.

* There's nothing for non-Python-object resources, like files or
   templates.  This is probably fine.

* There's no built-in indirection.  Ideally such indirection would
   happen in the config file or elsewhere in the system.

* Some exceptions are swallowed, though an attempt is made to swallow
   only the most boring exceptions.

* There are some FIXME's in the code.


From matt at matt-good.net  Tue Oct 30 17:30:06 2007
From: matt at matt-good.net (Matt Good)
Date: Tue, 30 Oct 2007 09:30:06 -0700
Subject: [Distutils] patch: Unused import of 'shutil'
In-Reply-To: <87sl3ufxv2.fsf@benfinney.id.au>
References: <87sl3ufxv2.fsf@benfinney.id.au>
Message-ID: <E33539CC-2A83-442F-9605-7715B31DC6C3@matt-good.net>

On Oct 28, 2007, at 7:39 PM, Ben Finney wrote:

> The latter is due to 'pyflakes' not handling an ImportError-based
> import fallback, as documented in ticket 1499 in the pyflakes Trac
> <URL:http://divmod.org/trac/ticket/1499>.

Heh, I had forgotten about that bug since it's been a year since I  
submitted it and now I hear about it twice in a week.  A coworker  
just emailed me to see if I was the "matt_good" that reported it  
since he was having the same problem.

-- Matt

From me at rpatterson.net  Tue Oct 30 23:34:33 2007
From: me at rpatterson.net (Ross Patterson)
Date: Tue, 30 Oct 2007 15:34:33 -0700
Subject: [Distutils] Ignoring site-packages when running zc.buildout tests
Message-ID: <87sl3skz9i.fsf@superfluity.lefae.org>

I have python-setuptools installed through my OS and zc.buildout
installed with easy_install.  I'd like to be able to ignore these when
running the zc.buildout tests (or tests for other projects that handle
distributions) so that the system packages don't interfere with the
testing environment.

Any ideas?  Should the zc.buildout tests be modified or should my
system?

Ross


From jim at zope.com  Tue Oct 30 23:48:35 2007
From: jim at zope.com (Jim Fulton)
Date: Tue, 30 Oct 2007 18:48:35 -0400
Subject: [Distutils] Ignoring site-packages when running zc.buildout
	tests
In-Reply-To: <87sl3skz9i.fsf@superfluity.lefae.org>
References: <87sl3skz9i.fsf@superfluity.lefae.org>
Message-ID: <BF2D2030-ADE7-42B0-B466-AE20EC6CED63@zope.com>


On Oct 30, 2007, at 6:34 PM, Ross Patterson wrote:

> I have python-setuptools installed through my OS and zc.buildout
> installed with easy_install.  I'd like to be able to ignore these when
> running the zc.buildout tests (or tests for other projects that handle
> distributions) so that the system packages don't interfere with the
> testing environment.
>
> Any ideas?

Your test runner could arrange that site-packages is excluded from  
sys.path.

I plan to add an option to the various egg-related recipes, including  
the test runner recipe, to exclude site-packages when looking for eggs.


>   Should the zc.buildout tests be modified or should my
> system?

Probably. Note that the zc.buildout tests only work when run from a  
zc.buildout checkout.  I need to fix this.

Also note that a number of the tests expect the name of the Python  
interpreter to be of the form: "pythonN.N". Some tests require Python  
2.3 to be around so they can test support for multiple interpreters.

In other words, the buildout tests are a bit of a pain to run,

Jim

--
Jim Fulton
Zope Corporation



From me at rpatterson.net  Tue Oct 30 23:52:46 2007
From: me at rpatterson.net (Ross Patterson)
Date: Tue, 30 Oct 2007 15:52:46 -0700
Subject: [Distutils] Ignoring site-packages when running zc.buildout
	tests
In-Reply-To: <BF2D2030-ADE7-42B0-B466-AE20EC6CED63@zope.com> (Jim Fulton's
	message of "Tue, 30 Oct 2007 18:48:35 -0400")
References: <87sl3skz9i.fsf@superfluity.lefae.org>
	<BF2D2030-ADE7-42B0-B466-AE20EC6CED63@zope.com>
Message-ID: <87odegkyf5.fsf@superfluity.lefae.org>

Jim Fulton <jim at zope.com> writes:

> On Oct 30, 2007, at 6:34 PM, Ross Patterson wrote:
>
>> I have python-setuptools installed through my OS and zc.buildout
>> installed with easy_install.  I'd like to be able to ignore these when
>> running the zc.buildout tests (or tests for other projects that handle
>> distributions) so that the system packages don't interfere with the
>> testing environment.
>>
>> Any ideas?
>
> Your test runner could arrange that site-packages is excluded from
> sys.path.
>
> I plan to add an option to the various egg-related recipes, including
> the test runner recipe, to exclude site-packages when looking for
> eggs.

Well then I think I'll wait for such.  Thanks.

>>   Should the zc.buildout tests be modified or should my
>> system?
>
> Probably. Note that the zc.buildout tests only work when run from a
> zc.buildout checkout.  I need to fix this.

FWIW, this is how I was running them and my system installed packages
were still causing test failures, unless I'm misunderstanding things.

Ross

From jim at zope.com  Wed Oct 31 00:01:33 2007
From: jim at zope.com (Jim Fulton)
Date: Tue, 30 Oct 2007 19:01:33 -0400
Subject: [Distutils] Ignoring site-packages when running zc.buildout
	tests
In-Reply-To: <87odegkyf5.fsf@superfluity.lefae.org>
References: <87sl3skz9i.fsf@superfluity.lefae.org>
	<BF2D2030-ADE7-42B0-B466-AE20EC6CED63@zope.com>
	<87odegkyf5.fsf@superfluity.lefae.org>
Message-ID: <9410CAC9-2815-425C-9538-EC017B0F6EC3@zope.com>


On Oct 30, 2007, at 6:52 PM, Ross Patterson wrote:

> Jim Fulton <jim at zope.com> writes:
>
>> On Oct 30, 2007, at 6:34 PM, Ross Patterson wrote:
>>>   Should the zc.buildout tests be modified or should my
>>> system?
>>
>> Probably. Note that the zc.buildout tests only work when run from a
>> zc.buildout checkout.  I need to fix this.
>
> FWIW, this is how I was running them and my system installed packages
> were still causing test failures, unless I'm misunderstanding things.

Sorry, I should have used 2 paragraphs.  I was simply pointing out  
some issues with the tests, independent of the specific issue you  
raised.

--
Jim Fulton
Zope Corporation



From me at rpatterson.net  Wed Oct 31 00:16:17 2007
From: me at rpatterson.net (Ross Patterson)
Date: Tue, 30 Oct 2007 16:16:17 -0700
Subject: [Distutils] Project tests and zc.buildout (was: Ignoring
	site-packages when running zc.buildout tests)
References: <87sl3skz9i.fsf@superfluity.lefae.org>
	<BF2D2030-ADE7-42B0-B466-AE20EC6CED63@zope.com>
	<87odegkyf5.fsf@superfluity.lefae.org>
	<9410CAC9-2815-425C-9538-EC017B0F6EC3@zope.com>
Message-ID: <874pg8kxby.fsf_-_@superfluity.lefae.org>

Jim Fulton <jim at zope.com> writes:

> On Oct 30, 2007, at 6:52 PM, Ross Patterson wrote:
>
>> Jim Fulton <jim at zope.com> writes:
>>
>>> On Oct 30, 2007, at 6:34 PM, Ross Patterson wrote:
>>>>   Should the zc.buildout tests be modified or should my
>>>> system?
>>>
>>> Probably. Note that the zc.buildout tests only work when run from a
>>> zc.buildout checkout.  I need to fix this.
>>
>> FWIW, this is how I was running them and my system installed packages
>> were still causing test failures, unless I'm misunderstanding things.
>
> Sorry, I should have used 2 paragraphs.  I was simply pointing out  
> some issues with the tests, independent of the specific issue you  
> raised.

Actually, that raises another questions I've been wanting to ask.  Is
there a good story for using a project buildout for running tests while
still supporting "python setup.py test" for the same project?  Is there
documentation or a good example of this somewhere?

On a somewhat related note, is there a paster script that does initial
testing buildout layout for a new project?  How about initial tests
layout for a new project?

Ross


From jim at zope.com  Wed Oct 31 00:36:02 2007
From: jim at zope.com (Jim Fulton)
Date: Tue, 30 Oct 2007 19:36:02 -0400
Subject: [Distutils] Project tests and zc.buildout (was: Ignoring
	site-packages when running zc.buildout tests)
In-Reply-To: <874pg8kxby.fsf_-_@superfluity.lefae.org>
References: <87sl3skz9i.fsf@superfluity.lefae.org>
	<BF2D2030-ADE7-42B0-B466-AE20EC6CED63@zope.com>
	<87odegkyf5.fsf@superfluity.lefae.org>
	<9410CAC9-2815-425C-9538-EC017B0F6EC3@zope.com>
	<874pg8kxby.fsf_-_@superfluity.lefae.org>
Message-ID: <0B890F15-5A63-486D-AFA1-09CCC899F0B9@zope.com>


On Oct 30, 2007, at 7:16 PM, Ross Patterson wrote:

> Jim Fulton <jim at zope.com> writes:
>
>> On Oct 30, 2007, at 6:52 PM, Ross Patterson wrote:
>>
>>> Jim Fulton <jim at zope.com> writes:
>>>
>>>> On Oct 30, 2007, at 6:34 PM, Ross Patterson wrote:
>>>>>   Should the zc.buildout tests be modified or should my
>>>>> system?
>>>>
>>>> Probably. Note that the zc.buildout tests only work when run from a
>>>> zc.buildout checkout.  I need to fix this.
>>>
>>> FWIW, this is how I was running them and my system installed  
>>> packages
>>> were still causing test failures, unless I'm misunderstanding  
>>> things.
>>
>> Sorry, I should have used 2 paragraphs.  I was simply pointing out
>> some issues with the tests, independent of the specific issue you
>> raised.
>
> Actually, that raises another questions I've been wanting to ask.  Is
> there a good story for using a project buildout for running tests  
> while
> still supporting "python setup.py test" for the same project?

No. The test command to setup is completely specific to that  
command.  The meta data to support it isn't available to anything else.

...

> On a somewhat related note, is there a paster script that does initial
> testing buildout layout for a new project?  How about initial tests
> layout for a new project?

I can't say anything about paster. I don't use it.

I'm not aware of anything.  The common layout is so simple, that  
automating it isn't all that attractive to me.  IMO, a template that  
gets copied around would be enough.  I even created one, but I don't  
remember where I put it. :)

Jim

--
Jim Fulton
Zope Corporation