From anthony at interlink.com.au  Tue Aug  1 17:04:43 2006
From: anthony at interlink.com.au (Anthony Baxter)
Date: Wed, 2 Aug 2006 01:04:43 +1000
Subject: [Distutils] python version information in .egg-info directory
	name
In-Reply-To: <44C12249.3030100@astraw.com>
References: <5.1.1.6.0.20060703130254.01f16878@sparrow.telecommunity.com>
	<5.1.1.6.0.20060704100338.01f22880@sparrow.telecommunity.com>
	<44C12249.3030100@astraw.com>
Message-ID: <200608020104.45167.anthony@interlink.com.au>

On Saturday 22 July 2006 04:51, Andrew Straw wrote:
> The problem he's trying to solve is that the new Debian Python
> policy allows a single directory tree of .py files (not the .pyc
> and .pyo files) to serve all installed Python versions. The .pyc
> files get placed in a separate tree which is, obviously, versioned.

Debian's been asking for this for a while now. The problem is that 
serving pyc/pyo files from a different location requires some ugly 
hacking on import.c

As far as I'm aware, no-one has done that work. Or if they have, they 
haven't fed the changes back into Python that I've seen. 

As Phillip points out, this is a recipe for all sorts of pain. This is 
one of the issues I hope will be made better in Python 3 - until 
then, I'm very doubtful that the necessary work to change import to 
handle this in a sane and backwards compatible way will be done.

Some small example - the __file__ attribute of a module might suddenly 
be different depending on whether you load from a pyc or a py file. 
Plenty of code uses this to load resources from the package directory 
where the code lives. There's also changes needed to make sure that 
any files that are compiled (or recompiled) to pyc get the pyc files 
written to the new, different, location.

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

From jjl at pobox.com  Thu Aug  3 01:34:39 2006
From: jjl at pobox.com (John J Lee)
Date: Wed, 2 Aug 2006 23:34:39 +0000 (UTC)
Subject: [Distutils] [setuptools] old project release bootstrap broken by
 removal of 0.6a11
Message-ID: <Pine.LNX.4.64.0608022318420.8393@localhost>

Somebody reported to me that one of my project releases [1] has suddenly 
stopped being installable for people who don't already have setuptools 
installed.

The breakage occurred because the recommended method for providing a 
bootstrap (bundling ez_setup.py -- or FWIW, ez_setup/__init__.py, in my 
case) at least as of setuptools-0.6a11, unconditionally fetches the 
version of setuptools whose version number is embedded in ez_setup.py. 
That now fails for 0.6a11, because that version has been removed from 
PyPI.

Obviously people trying to install this old release of mine can still 
install setuptools manually by downloading ez_setup.py themselves.  But it 
would be nice if in future, the bootstrap were clever enough to fetch a 
directory listing and then grab the latest setuptools release. 
Otherwise, project releases that were very easy to install in the past 
suddenly become more complicated to install just because the PyPI 
setuptools download area has been cleaned up.

[1] http://wwwsearch.sourceforge.net/ClientCookie/src/ClientCookie-1.3.0.tar.gz


John


From jjl at pobox.com  Thu Aug  3 22:32:29 2006
From: jjl at pobox.com (John J Lee)
Date: Thu, 3 Aug 2006 20:32:29 +0000 (UTC)
Subject: [Distutils] [setuptools] 0.6c1 package_index.py swallows
	KeyboardInterrupt
Message-ID: <Pine.LNX.4.64.0608032023190.8383@localhost>

If an error occurs on the first download attempt, the subsequent attempts 
by easy_install to download a file can't be properly interrupted with 
Control-C (instead of terminating the process, it just jumps to the next 
of ten or fifteen mirrors).  Here's the fix:

--- 
/usr/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg/setuptools/package_index.py~    2006-08-03 20:04:28.000000000 +0000
+++ 
/usr/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg/setuptools/package_index.py     2006-08-03 20:21:18.000000000 +0000
@@ -589,6 +589,8 @@
              url = urlparse.urlunparse((scheme, mirror, path, param, '', frag))
              try:
                  return self._download_to(url, filename)
+            except (KeyboardInterrupt,SystemExit):
+                raise
              except:
                  _sf_mirrors.remove(mirror)  # don't retry the same mirror
                  mirror = get_sf_ip()


John


From pje at telecommunity.com  Thu Aug  3 22:55:16 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 03 Aug 2006 16:55:16 -0400
Subject: [Distutils] [setuptools] 0.6c1 package_index.py swallows
 KeyboardInterrupt
In-Reply-To: <Pine.LNX.4.64.0608032023190.8383@localhost>
Message-ID: <5.1.1.6.0.20060803165506.025ff008@sparrow.telecommunity.com>

At 08:32 PM 8/3/2006 +0000, John J Lee wrote:
>If an error occurs on the first download attempt, the subsequent attempts
>by easy_install to download a file can't be properly interrupted with
>Control-C (instead of terminating the process, it just jumps to the next
>of ten or fifteen mirrors).  Here's the fix:
>
>---
>/usr/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg/setuptools/package_index.py~ 
>2006-08-03 20:04:28.000000000 +0000
>+++
>/usr/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg/setuptools/package_index.py 
>2006-08-03 20:21:18.000000000 +0000
>@@ -589,6 +589,8 @@
>               url = urlparse.urlunparse((scheme, mirror, path, param, '', 
> frag))
>               try:
>                   return self._download_to(url, filename)
>+            except (KeyboardInterrupt,SystemExit):
>+                raise
>               except:
>                   _sf_mirrors.remove(mirror)  # don't retry the same mirror
>                   mirror = get_sf_ip()
>
>
>John

Thanks, I'll get this in c2.


From faassen at infrae.com  Fri Aug  4 11:36:31 2006
From: faassen at infrae.com (Martijn Faassen)
Date: Fri, 04 Aug 2006 11:36:31 +0200
Subject: [Distutils] [setuptools] eggs and Python Unicode variants (UCS2, UCS4)
In-Reply-To: <44CE48DD.3020000@infrae.com>
References: <44CE48DD.3020000@infrae.com>
Message-ID: <44D3151F.9070109@infrae.com>

Hey,

Any feedback on this? Nobody cares that Python eggs compiled with a 
linux distribution version of Python don't run on hand-compiled versions 
of Python, and vice versa? I added [setuptools] to the topic in case 
that's the convention to get people concerned with those to pay 
attention. :)

Regards,

Martijn

From tseaver at palladion.com  Fri Aug  4 15:31:34 2006
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 04 Aug 2006 09:31:34 -0400
Subject: [Distutils] [setuptools] eggs and Python Unicode variants (UCS2,
	UCS4)
In-Reply-To: <44D3151F.9070109@infrae.com>
References: <44CE48DD.3020000@infrae.com> <44D3151F.9070109@infrae.com>
Message-ID: <44D34C36.8070308@palladion.com>

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

Martijn Faassen wrote:
> Hey,
> 
> Any feedback on this? Nobody cares that Python eggs compiled with a 
> linux distribution version of Python don't run on hand-compiled versions 
> of Python, and vice versa? I added [setuptools] to the topic in case 
> that's the convention to get people concerned with those to pay 
> attention. :)

I care. :)  The "Python ABI" of an egg *is* part of its "signature", I
think.  I don't know for what use cases the UCS4 stuff was designed, but
it is *never* what I want (doubling space requirements for all unicode
strings is a recipe for an unhappy long-running process).

I'd actually settle for having setuptools just refuse to install an
incompatible binary egg, so that I would realize I needed to build it
from source.


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

iD8DBQFE00w2+gerLs4ltQ4RAoVEAKDQSTIotRiilcH4DLOQn98Fhh4e5QCfewpo
8lBo1DM1TWU913BcZN4gX40=
=tAqK
-----END PGP SIGNATURE-----


From constant.beta at gmail.com  Fri Aug  4 20:18:27 2006
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Fri, 4 Aug 2006 20:18:27 +0200
Subject: [Distutils] [setuptools] Sophisticated package requirements
Message-ID: <5e8b0f6b0608041118uba85765r4f8da44629501910@mail.gmail.com>

Hi,

I'm using setuptools interface to fetch packages from PyPI. Version
requirements work fine, but more sophisticated conditions are needed.
In particular, I would like to hint setuptools to prefer source
distributions (tar/subversion/..) over eggs and prefer fetching
distributions from PyPI over relying on locally installed releases
(even if version numbers match). Currently my code looks something
like that:

from setuptools.package_index import PackageIndex
from pkg_resources import Requirement

pkgindex = PackageIndex()
path = pkgindex.fetch(Requirement.parse(REQUIREMENTS),
    TMP_DIR, force_scan=True)

According to documentation, setting force_scan to False would inhibit
checking local filesystem, but it's not working that way. Can you
suggest anything that would help me in achieving what I described?

Cheers,
mk
-- 
 . o .       >>  http://joker.linuxstuff.pl  <<
 . . o   It's easier to get forgiveness for being wrong
 o o o   than forgiveness for being right.

From ronaldoussoren at mac.com  Fri Aug  4 21:05:23 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 4 Aug 2006 21:05:23 +0200
Subject: [Distutils] [setuptools] eggs and Python Unicode variants (UCS2,
	UCS4)
In-Reply-To: <44D3151F.9070109@infrae.com>
References: <44CE48DD.3020000@infrae.com> <44D3151F.9070109@infrae.com>
Message-ID: <D6AD543D-AA7C-44BD-8AE3-B98138FBC79E@mac.com>


On Aug 4, 2006, at 11:36 AM, Martijn Faassen wrote:

> Hey,
>
> Any feedback on this? Nobody cares that Python eggs compiled with a
> linux distribution version of Python don't run on hand-compiled  
> versions
> of Python, and vice versa? I added [setuptools] to the topic in case
> that's the convention to get people concerned with those to pay
> attention. :)

My guess is that nobody cares enough to provide a patch ;-)

The size of unicode characters is IMO part of the ABI "description",  
just like the python version and should therefore be part of the egg  
name. We should end up with something like 'lxml-1.0.1-py2.4-ucs2- 
macosx-10.4-fat.egg'.

A minor problem is that the right place to fix this is in distutils,  
not setuptools. That way other bdist_* targets would also pick up the  
right ABI description.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20060804/3f7c6438/attachment.bin 

From leif at geodynamics.org  Fri Aug  4 22:37:46 2006
From: leif at geodynamics.org (Leif Strand)
Date: Fri, 04 Aug 2006 13:37:46 -0700
Subject: [Distutils] [setuptools] "setup.py develop" should bootstrap
Message-ID: <44D3B01A.9040208@geodynamics.org>

Hi,

I think the 'develop' command should bootstrap 'setuptools' itself -- 
like 'install' does.

I was Googling around for a possible work-around, but instead I only 
found others who ran into the same problem:

    http://www.djangoproject.com/documentation/install/

(See the comments at the bottom of the page.) They try to use 'develop' 
to install Django, but get "ImportError: No module named pkg_resources" 
when they try to run it. (Come to think of it, I may have used 'develop' 
to install Django the first time, but it only worked because I had used 
'setuptools' before.)

The users of my 'setup.py' script will likely encounter the exact same 
scenario: their first encounter with 'setuptools' will be checking-out a 
project from Subversion, and then running "setup.py develop".

Anyway, I developed a crude work-around -- just force the setuptools egg 
to be installed, before calling setup() for real:

    import setuptools

    if setuptools.bootstrap_install_from:
        egg = setuptools.bootstrap_install_from
        setuptools.bootstrap_install_from = None
        setuptools.setup(script_args=['easy_install', egg])

    setuptools.setup(...)

(The above snippet has no warranty of any kind.)

--Leif Strand


From bob at redivi.com  Fri Aug  4 23:35:48 2006
From: bob at redivi.com (Bob Ippolito)
Date: Fri, 4 Aug 2006 14:35:48 -0700
Subject: [Distutils] [setuptools] "setup.py develop" should bootstrap
In-Reply-To: <44D3B01A.9040208@geodynamics.org>
References: <44D3B01A.9040208@geodynamics.org>
Message-ID: <AE36C31B-DE0F-44D8-8052-A6F5C64B0E04@redivi.com>


On Aug 4, 2006, at 1:37 PM, Leif Strand wrote:

> Hi,
>
> I think the 'develop' command should bootstrap 'setuptools' itself --
> like 'install' does.
>
> I was Googling around for a possible work-around, but instead I only
> found others who ran into the same problem:
>
>     http://www.djangoproject.com/documentation/install/
>
> (See the comments at the bottom of the page.) They try to use  
> 'develop'
> to install Django, but get "ImportError: No module named  
> pkg_resources"
> when they try to run it. (Come to think of it, I may have used  
> 'develop'
> to install Django the first time, but it only worked because I had  
> used
> 'setuptools' before.)
>
> The users of my 'setup.py' script will likely encounter the exact same
> scenario: their first encounter with 'setuptools' will be checking- 
> out a
> project from Subversion, and then running "setup.py develop".
>
> Anyway, I developed a crude work-around -- just force the  
> setuptools egg
> to be installed, before calling setup() for real:
>
>     import setuptools
>
>     if setuptools.bootstrap_install_from:
>         egg = setuptools.bootstrap_install_from
>         setuptools.bootstrap_install_from = None
>         setuptools.setup(script_args=['easy_install', egg])
>
>     setuptools.setup(...)

Adding setuptools to the install_requires=[] list of the package's  
setup.py should work. I guess that could be implicit all the time,  
because most setuptools-using packages want that (and anything with  
entry points is going to need it).

-bob


From pje at telecommunity.com  Mon Aug  7 00:10:40 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 06 Aug 2006 18:10:40 -0400
Subject: [Distutils] [setuptools] Sophisticated package requirements
In-Reply-To: <5e8b0f6b0608041118uba85765r4f8da44629501910@mail.gmail.com
 >
Message-ID: <5.1.1.6.0.20060806180638.02604e40@sparrow.telecommunity.com>

At 08:18 PM 8/4/2006 +0200, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>I'm using setuptools interface to fetch packages from PyPI. Version
>requirements work fine, but more sophisticated conditions are needed.
>In particular, I would like to hint setuptools to prefer source
>distributions (tar/subversion/..) over eggs and prefer fetching
>distributions from PyPI over relying on locally installed releases
>(even if version numbers match). Currently my code looks something
>like that:
>
>from setuptools.package_index import PackageIndex
>from pkg_resources import Requirement
>
>pkgindex = PackageIndex()

Pass an empty search path, e.g. PackageIndex(search_path=[])

This will create an index that doesn't include any installed eggs.


>path = pkgindex.fetch(Requirement.parse(REQUIREMENTS),
>     TMP_DIR, force_scan=True)
>
>According to documentation, setting force_scan to False would inhibit
>checking local filesystem,

I don't know where you're getting that from.  The docstring says:

"""If necessary, or if the `force_scan` flag is set, the requirement is
searched for in the (online) package index as well as the locally
installed packages."""

Note the "as well as".  Anyway, creating the PackageIndex with search_path 
set to an empty list should do what you want, except you also want to pass 
'source=True' to 'fetch()' if you want it to find only source packages.


From ronaldoussoren at mac.com  Mon Aug  7 01:23:27 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 6 Aug 2006 16:23:27 -0700
Subject: [Distutils] [setuptools] include files and eggs
Message-ID: <E3195E97-5B1B-4EB7-B682-422C9C1396CC@mac.com>

Hi,

Several python packages, such as Numeric, will install header files  
during installation. It seems to me that the best way to support this  
in a world of eggs is to add those include files to eggs and teach  
setuptools to use those includefiles in build_ext.

The attached patch does just that. It adds an egg_info.writer that  
writes all distribution.headers to the egg-info directory and patches  
build_ext to add header files from all active distributions to the  
include path.

I'm not entirely sure that this patch is correct, although it seems  
to work just fine. The egg_info.writer for include files adds a  
directory with files to the meta-data, the documentation and API seem  
to assume that writers will write a single file. The patch to  
build_ext feels hackish and I'm not sure if adding all active  
distributions is the right thing to do, maybe only header files from  
distributions that are mentioned as setup_requires should be added.  
That would avoid possible problems during upgrades of packages.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: setuptools-includes.patch
Type: application/octet-stream
Size: 5479 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20060806/98a3895d/attachment.obj 
-------------- next part --------------


From pje at telecommunity.com  Mon Aug  7 02:54:37 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 06 Aug 2006 20:54:37 -0400
Subject: [Distutils] [setuptools] "setup.py develop" should  bootstrap
In-Reply-To: <44D3B01A.9040208@geodynamics.org>
Message-ID: <5.1.1.6.0.20060806205215.0286bb28@sparrow.telecommunity.com>

At 01:37 PM 8/4/2006 -0700, Leif Strand wrote:
>Hi,
>
>I think the 'develop' command should bootstrap 'setuptools' itself --
>like 'install' does.

I agree, and this should be considered a bug, so it will be fixed in 
setuptools 0.6c2.


From constant.beta at gmail.com  Mon Aug  7 02:55:31 2006
From: constant.beta at gmail.com (=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?=)
Date: Mon, 7 Aug 2006 02:55:31 +0200
Subject: [Distutils] [setuptools] Sophisticated package requirements
In-Reply-To: <5.1.1.6.0.20060806180638.02604e40@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060806180638.02604e40@sparrow.telecommunity.com>
Message-ID: <5e8b0f6b0608061755y44650ab5o4432f45e190448e6@mail.gmail.com>

On 8/7/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 08:18 PM 8/4/2006 +0200, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> >I'm using setuptools interface to fetch packages from PyPI. Version
> >requirements work fine, but more sophisticated conditions are needed.
> >In particular, I would like to hint setuptools to prefer source
> >distributions (tar/subversion/..) over eggs and prefer fetching
> >distributions from PyPI over relying on locally installed releases
> >(even if version numbers match). Currently my code looks something
> >like that:
> >
> >from setuptools.package_index import PackageIndex
> >from pkg_resources import Requirement
> >
> >pkgindex = PackageIndex()
>
> Pass an empty search path, e.g. PackageIndex(search_path=[])
>
> This will create an index that doesn't include any installed eggs.
>
>
> >path = pkgindex.fetch(Requirement.parse(REQUIREMENTS),
> >     TMP_DIR, force_scan=True)
> >
> >According to documentation, setting force_scan to False would inhibit
> >checking local filesystem,
>
> I don't know where you're getting that from.  The docstring says:
>
> """If necessary, or if the `force_scan` flag is set, the requirement is
> searched for in the (online) package index as well as the locally
> installed packages."""
>
> Note the "as well as".  Anyway, creating the PackageIndex with search_path
> set to an empty list should do what you want, except you also want to pass
> 'source=True' to 'fetch()' if you want it to find only source packages.

Works well. Thanks!

Cheers,
mk
-- 
 . o .       >>  http://joker.linuxstuff.pl  <<
 . . o   It's easier to get forgiveness for being wrong
 o o o   than forgiveness for being right.

From pje at telecommunity.com  Mon Aug  7 03:00:22 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 06 Aug 2006 21:00:22 -0400
Subject: [Distutils] [setuptools] eggs and Python Unicode variants (UCS2, UCS4)
In-Reply-To: <D6AD543D-AA7C-44BD-8AE3-B98138FBC79E@mac.com>
References: <44D3151F.9070109@infrae.com> <44CE48DD.3020000@infrae.com>
	<44D3151F.9070109@infrae.com>
Message-ID: <5.1.1.6.0.20060806205504.02aa7008@sparrow.telecommunity.com>

At 09:05 PM 8/4/2006 +0200, Ronald Oussoren wrote:

>On Aug 4, 2006, at 11:36 AM, Martijn Faassen wrote:
>
>>Hey,
>>
>>Any feedback on this? Nobody cares that Python eggs compiled with a
>>linux distribution version of Python don't run on hand-compiled
>>versions
>>of Python, and vice versa? I added [setuptools] to the topic in case
>>that's the convention to get people concerned with those to pay
>>attention. :)
>
>My guess is that nobody cares enough to provide a patch ;-)
>
>The size of unicode characters is IMO part of the ABI "description",
>just like the python version and should therefore be part of the egg
>name. We should end up with something like 'lxml-1.0.1-py2.4-ucs2- 
>macosx-10.4-fat.egg'.
>
>A minor problem is that the right place to fix this is in distutils,
>not setuptools. That way other bdist_* targets would also pick up the
>right ABI description.

Yes, it should be fixed in the distutils.  Of course, for Python versions 
<2.6, it will actually have to be fixed by setuptools.  It would be nice if 
someone could provide patches for both distutils and setuptools.

To implement the setuptools patch, you will need to modify the various 
"platform utilities" in pkg_resources:

     http://peak.telecommunity.com/DevCenter/PkgResources#platform-utilities

bdist_egg and all of the pkg_resources internals rely on these functions.

Note that for this patch to be backward-compatible, it *must* change 
compatible_platforms to only compare unicode widths if they are present in 
*both* the 'required' and the 'provided' strings.  If either one is missing 
a unicode width indicator, the unicode width must be ignored.

This is a non-negotiable requirement, since otherwise it will be impossible 
for someone to use packages they've already built locally once they upgrade.

The patch will also have to go into the new 0.7 alpha line (rather than the 
0.6c line), since it's a new feature.


From pje at telecommunity.com  Mon Aug  7 04:49:12 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 06 Aug 2006 22:49:12 -0400
Subject: [Distutils] [setuptools] include files and eggs
In-Reply-To: <E3195E97-5B1B-4EB7-B682-422C9C1396CC@mac.com>
Message-ID: <5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>

At 04:23 PM 8/6/2006 -0700, Ronald Oussoren wrote:
>Hi,
>
>Several python packages, such as Numeric, will install header files
>during installation. It seems to me that the best way to support this
>in a world of eggs is to add those include files to eggs and teach
>setuptools to use those includefiles in build_ext.
>
>The attached patch does just that.

Thank you for taking the time to do this; even if I don't use the patch, 
your analysis of the problem and proof of concept is very helpful.  I wish 
more people would do this when they propose expansive additions to 
setuptools.  :)


>  It adds an egg_info.writer that
>writes all distribution.headers to the egg-info directory and patches
>build_ext to add header files from all active distributions to the
>include path.
>
>I'm not entirely sure that this patch is correct, although it seems
>to work just fine.

One thing that might be a problem is that you're always effectively writing 
the headers in Unix file format, so they will appear that way regardless of 
origin and destination platform.  I don't know if that's the right thing to 
do.  Perhaps somebody with some experience could speak to this, as far as 
whether any Windows or Mac tools might have a problem with this?


>  The egg_info.writer for include files adds a
>directory with files to the meta-data, the documentation and API seem
>to assume that writers will write a single file.

I don't really see it as a problem, I'll take a look at the docs.


>  The patch to
>build_ext feels hackish

I presume you mean due to the temporary directory.  Probably the right 
solution is to allow access to metadata filenames in 0.7, so that the 
temporary directory can be managed by the usual extraction techniques for 
zipped eggs.  I have seen other places where file access for metadata would 
be useful, so the addition wouldn't just be for this.


>and I'm not sure if adding all active
>distributions is the right thing to do, maybe only header files from
>distributions that are mentioned as setup_requires should be added.
>
>That would avoid possible problems during upgrades of packages.

Using the setup_requires requirements is probably the right thing to do.

I won't be able to include this new feature in 0.6, so it'll be part of 0.7 
instead.  But it seems like a terrific idea, and fits well with setuptools' 
design principles.  It provides backward compatibility for plain distutils 
packages that provide headers, and it lets setuptools users depend on those 
headers.  Thank you very much!

Of course, since it is such a useful and sensible idea, it will of course 
be incompatible with Debian Python policy.

Sadly, that isn't a joke, as I'm sure there will be screams of bloody 
murder regarding the idea of putting headers inside directories inside 
Python version-specific library directories, not the least since they will 
want to split such packages into a plain and "devel" version.

There will then be much wailing and gnashing of teeth by people trying to 
develop SVN-based packages atop Debian, since setuptools will notice the 
presence of the Debian-installed packages and try to use their (missing) 
header files when the user attempts to build something.

The Debian team will see nothing wrong with this because obviously the user 
should've known by osmosis that a -devel package was needed, and...  [sigh]

Okay, no point in continuing that rant.  Instead, a counter-meme is 
required, to permit easy education of developers.  Maybe something like, 
"Debian thinks that users aren't developers, so they strip out everything 
that might be used to develop software.  Make sure you have a '-devel' 
package for *everything* on your system, because otherwise it's impossible 
to tell what things will be broken when you try to develop software."  That 
has at least some chance of allowing things to work, at the cost of having 
to be repeated to every single developer that encounters the problem, and 
for every Python package that might be their point of entry to discovering 
the problem.

Unfortunately, this is a religious issue, which means it is not solvable by 
merely technical means.  If it were possible to have a mapping from PyPI 
projects to Debian packages, it would at least be possible in theory for 
setuptools to notify the user of the missing Debian package.  However, 
Debian policy conflates various meanings of "package" in a way that is 
utterly incompatible with such a mapping, only manual mapping is 
possible.  Essentially, there would have to be some kind of *manually 
maintained* global mapping of PyPI project names to Debian package 
names.  If somebody in the Debian community wants to create and maintain 
the thing, then in theory at least, setuptools could use it to tell the 
user to install the Debian packages, or invoke the corresponding package 
installation tools.

Maybe in setuptools 0.7, I should provide some way of providing alternative 
installation hooks, and then encourage people who complain about 
Debian-related problems to write a plugin that wraps the Debian 
tools.  Perhaps there might even be some way to use existing Debian package 
metadata directories to find out what Debian package(s) need to be 
installed in order to mimic a direct installation of a particular PyPI project.


From ronaldoussoren at mac.com  Mon Aug  7 07:14:06 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 6 Aug 2006 22:14:06 -0700
Subject: [Distutils] [setuptools] include files and eggs
In-Reply-To: <5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>
Message-ID: <85629C7F-094E-4FD0-B90D-B1BD8DD47CCD@mac.com>


On 6-aug-2006, at 19:49, Phillip J. Eby wrote:

> At 04:23 PM 8/6/2006 -0700, Ronald Oussoren wrote:
>> Hi,
>>
>> Several python packages, such as Numeric, will install header files
>> during installation. It seems to me that the best way to support this
>> in a world of eggs is to add those include files to eggs and teach
>> setuptools to use those includefiles in build_ext.
>>
>> The attached patch does just that.
>
> Thank you for taking the time to do this; even if I don't use the  
> patch, your analysis of the problem and proof of concept is very  
> helpful.  I wish more people would do this when they propose  
> expansive additions to setuptools.  :)

I had to do something on the plane ;-).
>
>
>>  It adds an egg_info.writer that
>> writes all distribution.headers to the egg-info directory and patches
>> build_ext to add header files from all active distributions to the
>> include path.
>>
>> I'm not entirely sure that this patch is correct, although it seems
>> to work just fine.
>
> One thing that might be a problem is that you're always effectively  
> writing the headers in Unix file format, so they will appear that  
> way regardless of origin and destination platform.  I don't know if  
> that's the right thing to do.  Perhaps somebody with some  
> experience could speak to this, as far as whether any Windows or  
> Mac tools might have a problem with this?

Mac tools shouldn't be a problem here, current versions of MacOS are  
unix and use unix EOL conventions. I don't know how windows compilers  
deal with unix-style files.

BTW. I don't understand why you think the headers are written in Unix  
format as my patch opens files in text mode. Meta data is read as  
binary data and then writting out in text mode. That could cause  
problems: if the egg contains a header in windows format the  
resulting file will be mangled because the data returned by  
metadata_read contains '\r\n' which write will then happily change  
into '\r\r\n'. This could change the meaning of header file.
>
>>  The patch to
>> build_ext feels hackish
>
> I presume you mean due to the temporary directory.  Probably the  
> right solution is to allow access to metadata filenames in 0.7, so  
> that the temporary directory can be managed by the usual extraction  
> techniques for zipped eggs.  I have seen other places where file  
> access for metadata would be useful, so the addition wouldn't just  
> be for this.

I did mean the temporary directory. On the other hand I don't really  
like extraction stuff for zipped eggs, so I shouldn't complain  
here ;-). I'll write another message on that subject, but basically I  
don't like an ever-growing .python-eggs directory in my home directory.

>
>
>> and I'm not sure if adding all active
>> distributions is the right thing to do, maybe only header files from
>> distributions that are mentioned as setup_requires should be added.
>>
>> That would avoid possible problems during upgrades of packages.
>
> Using the setup_requires requirements is probably the right thing  
> to do.
>
> I won't be able to include this new feature in 0.6, so it'll be  
> part of 0.7 instead.  But it seems like a terrific idea, and fits  
> well with setuptools' design principles.  It provides backward  
> compatibility for plain distutils packages that provide headers,  
> and it lets setuptools users depend on those headers.  Thank you  
> very much!

Adding it to 0.7 is fine. I'm slowly moving my stuff to python 2.5  
and am therefore using the setuptools trunk anyway :-)

>
> Of course, since it is such a useful and sensible idea, it will of  
> course be incompatible with Debian Python policy.

This one is worse, it is incompatible with the packaging policy of  
every Linux distribution, header files must be in -devel packages  
obviously :-(. Maybe --single-version-externally-managed should just  
revert to the current "let's install the header in the python headers  
directory" behaviour, that way you won't get the wrath of the Debian  
packagers while "real" eggs behave as they should.

>
> Sadly, that isn't a joke, as I'm sure there will be screams of  
> bloody murder regarding the idea of putting headers inside  
> directories inside Python version-specific library directories, not  
> the least since they will want to split such packages into a plain  
> and "devel" version.

I know, this can be very annoying and seems to be one of the most  
asked questions on this list (or rather, "how do I install distutils  
manually?").

>
> There will then be much wailing and gnashing of teeth by people  
> trying to develop SVN-based packages atop Debian, since setuptools  
> will notice the presence of the Debian-installed packages and try  
> to use their (missing) header files when the user attempts to build  
> something.
>
> The Debian team will see nothing wrong with this because obviously  
> the user should've known by osmosis that a -devel package was  
> needed, and...  [sigh]

The end result of which may will be that a meme will spread that says  
you shouldn't use the distributors build of python because that is  
broken. I don't envy you here, at least some people that try to build  
their own eggs will see this failure and think it's a bug in setuptools.

>
> Okay, no point in continuing that rant.  Instead, a counter-meme is  
> required, to permit easy education of developers.  Maybe something  
> like, "Debian thinks that users aren't developers, so they strip  
> out everything that might be used to develop software.  Make sure  
> you have a '-devel' package for *everything* on your system,  
> because otherwise it's impossible to tell what things will be  
> broken when you try to develop software."  That has at least some  
> chance of allowing things to work, at the cost of having to be  
> repeated to every single developer that encounters the problem, and  
> for every Python package that might be their point of entry to  
> discovering the problem.
>
> Unfortunately, this is a religious issue, which means it is not  
> solvable by merely technical means.

I'm afraid you're right. What really annoyed me the last time debian  
vs. eggs was discussed here was that some Debian packagers honestly  
believe that they know better than the authors of packages what the  
dependencies of those packages are.

> If it were possible to have a mapping from PyPI projects to Debian  
> packages, it would at least be possible in theory for setuptools to  
> notify the user of the missing Debian package.  However, Debian  
> policy conflates various meanings of "package" in a way that is  
> utterly incompatible with such a mapping, only manual mapping is  
> possible.  Essentially, there would have to be some kind of  
> *manually maintained* global mapping of PyPI project names to  
> Debian package names.  If somebody in the Debian community wants to  
> create and maintain the thing, then in theory at least, setuptools  
> could use it to tell the user to install the Debian packages, or  
> invoke the corresponding package installation tools.

Does debian really split some projects into multiple debian packages  
(excluding -devel variants)? I know they do this for some non-python  
stuff, but haven't noticed this for python software yet. Not that I'm  
likely to notice, the only Debian machine I manage at the moment  
isn't running much python software.

Given that at least some Debian developers think setuptools is  
superfluous I wouldn't hold my breath waiting for a volunteer that  
maintains a mapping from PyPI to debian package names.

Ronald
>


From tseaver at palladion.com  Mon Aug  7 15:36:52 2006
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 07 Aug 2006 09:36:52 -0400
Subject: [Distutils] [setuptools] include files and eggs
In-Reply-To: <85629C7F-094E-4FD0-B90D-B1BD8DD47CCD@mac.com>
References: <5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>
	<85629C7F-094E-4FD0-B90D-B1BD8DD47CCD@mac.com>
Message-ID: <44D741F4.4090503@palladion.com>

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

Ronald Oussoren wrote:

> On 6-aug-2006, at 19:49, Phillip J. Eby wrote:

>> Of course, since it is such a useful and sensible idea, it will of  
>> course be incompatible with Debian Python policy.
> 
> This one is worse, it is incompatible with the packaging policy of  
> every Linux distribution, header files must be in -devel packages  
> obviously :-(. Maybe --single-version-externally-managed should just  
> revert to the current "let's install the header in the python headers  
> directory" behaviour, that way you won't get the wrath of the Debian  
> packagers while "real" eggs behave as they should.
> 
>> Sadly, that isn't a joke, as I'm sure there will be screams of  
>> bloody murder regarding the idea of putting headers inside  
>> directories inside Python version-specific library directories, not  
>> the least since they will want to split such packages into a plain  
>> and "devel" version.
> 
> I know, this can be very annoying and seems to be one of the most  
> asked questions on this list (or rather, "how do I install distutils  
> manually?").
> 
>> There will then be much wailing and gnashing of teeth by people  
>> trying to develop SVN-based packages atop Debian, since setuptools  
>> will notice the presence of the Debian-installed packages and try  
>> to use their (missing) header files when the user attempts to build  
>> something.
>>
>> The Debian team will see nothing wrong with this because obviously  
>> the user should've known by osmosis that a -devel package was  
>> needed, and...  [sigh]
> 
> The end result of which may will be that a meme will spread that says  
> you shouldn't use the distributors build of python because that is  
> broken.

That meme is already prevalent in the Zope world:  the tradeoffs the
distro authors make when packaging Python (e.g., using UCS4 because it
supposedly makes for a better GUI experience, or putting distutils et.
aliae into a separate, not-installed-by-default package) serve goals
which are not compatible with those of the long-running appserver.

> I don't envy you here, at least some people that try to build  
> their own eggs will see this failure and think it's a bug in setuptools.
> 
>> Okay, no point in continuing that rant.  Instead, a counter-meme is  
>> required, to permit easy education of developers.  Maybe something  
>> like, "Debian thinks that users aren't developers, so they strip  
>> out everything that might be used to develop software.  Make sure  
>> you have a '-devel' package for *everything* on your system,  
>> because otherwise it's impossible to tell what things will be  
>> broken when you try to develop software."  That has at least some  
>> chance of allowing things to work, at the cost of having to be  
>> repeated to every single developer that encounters the problem, and  
>> for every Python package that might be their point of entry to  
>> discovering the problem.
>>
>> Unfortunately, this is a religious issue, which means it is not  
>> solvable by merely technical means.
> 
> I'm afraid you're right. What really annoyed me the last time debian  
> vs. eggs was discussed here was that some Debian packagers honestly  
> believe that they know better than the authors of packages what the  
> dependencies of those packages are.

There is a not-quite-overt cultural issue here:  if we automate the
production of .deb files using the original authors' specifications,
then we remove the possibility of needing a Debian developer to be the
"maintainer" of said packages.

>> If it were possible to have a mapping from PyPI projects to Debian  
>> packages, it would at least be possible in theory for setuptools to  
>> notify the user of the missing Debian package.  However, Debian  
>> policy conflates various meanings of "package" in a way that is  
>> utterly incompatible with such a mapping, only manual mapping is  
>> possible.  Essentially, there would have to be some kind of  
>> *manually maintained* global mapping of PyPI project names to  
>> Debian package names.  If somebody in the Debian community wants to  
>> create and maintain the thing, then in theory at least, setuptools  
>> could use it to tell the user to install the Debian packages, or  
>> invoke the corresponding package installation tools.
> 
> Does debian really split some projects into multiple debian packages  
> (excluding -devel variants)? I know they do this for some non-python  
> stuff, but haven't noticed this for python software yet. Not that I'm  
> likely to notice, the only Debian machine I manage at the moment  
> isn't running much python software.

- From a packager's point of view, it might be sensisble, especially for
things like the conditional dependencies called out in setuptools'
"features":  GUI support might be optional, for instance.

> Given that at least some Debian developers think setuptools is  
> superfluous I wouldn't hold my breath waiting for a volunteer that  
> maintains a mapping from PyPI to debian package names.

Maybe the pool is not Debian-developers-who-use-PyPI, but
PyPI-developers-who-use-Debian.


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

iD8DBQFE10Hz+gerLs4ltQ4RAr0fAJ0fiMvkA2KXefoiJlOwHiI5ki9uQwCgzjsh
gDoKL8kxvJTd1hGJqHT09G4=
=Urpg
-----END PGP SIGNATURE-----


From strawman at astraw.com  Mon Aug  7 22:13:34 2006
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 07 Aug 2006 13:13:34 -0700
Subject: [Distutils] [setuptools] include files and eggs
In-Reply-To: <5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>
Message-ID: <44D79EEE.8050300@astraw.com>

Phillip J. Eby wrote:
> Of course, since it is such a useful and sensible idea, it will of course 
> be incompatible with Debian Python policy.
>
> Sadly, that isn't a joke, as I'm sure there will be screams of bloody 
> murder regarding the idea of putting headers inside directories inside 
> Python version-specific library directories, not the least since they will 
> want to split such packages into a plain and "devel" version.
>   
Hmm, AFAICT they haven't screamed bloody murder regarding numpy, which
has been including its header files in an egg-compatible way for a long
time (since its inception almost a year ago?). Now that it's in beta,
it's surely getting some widespread use, presumably even by Debian
Developers. (To be sure, some people have screamed bloody murder about
this, but they haven't been DDs, to my knowledge.)
> There will then be much wailing and gnashing of teeth by people trying to 
> develop SVN-based packages atop Debian, since setuptools will notice the 
> presence of the Debian-installed packages and try to use their (missing) 
> header files when the user attempts to build something.
>
> The Debian team will see nothing wrong with this because obviously the user 
> should've known by osmosis that a -devel package was needed, and...  [sigh]
>
> Okay, no point in continuing that rant.  Instead, a counter-meme is 
> required, to permit easy education of developers.  Maybe something like, 
> "Debian thinks that users aren't developers, so they strip out everything 
> that might be used to develop software.  Make sure you have a '-devel' 
> package for *everything* on your system, because otherwise it's impossible 
> to tell what things will be broken when you try to develop software."  That 
> has at least some chance of allowing things to work, at the cost of having 
> to be repeated to every single developer that encounters the problem, and 
> for every Python package that might be their point of entry to discovering 
> the problem.
>
>   
Well, I'm just glad that my Debian systems (presumably) aren't cluttered
up with the cruft for developing perl programs, just the bare minimum
necessary for them to run, thank you very much. :) Those perl developers
probably feel the same about Python.

Seriously, there are reasons for Debian's seeming madness. I certainly
don't understand them all, but they include: being able to install
working software with minimal footprint, modularly being able to add
documentation and development abilities, minimizing server space
required to house a Python package distribution that might have binary
extension modules that run on all the architectures that Debian
supports. In other words, Debian is a lot of things to a lot of people,
and some have resulted in decisions that are different from those that
would have been made if Debian was designed to prioritize Python
user/developer experiences over other considerations.

> Unfortunately, this is a religious issue, which means it is not solvable by 
> merely technical means.  If it were possible to have a mapping from PyPI 
> projects to Debian packages, it would at least be possible in theory for 
> setuptools to notify the user of the missing Debian package.  However, 
> Debian policy conflates various meanings of "package" in a way that is 
> utterly incompatible with such a mapping, only manual mapping is 
> possible.  Essentially, there would have to be some kind of *manually 
> maintained* global mapping of PyPI project names to Debian package 
> names.  If somebody in the Debian community wants to create and maintain 
> the thing, then in theory at least, setuptools could use it to tell the 
> user to install the Debian packages, or invoke the corresponding package 
> installation tools.
>   
I have the beginnings of a related, but not identical, mapping at
http://stdeb.python-hosting.com/wiki/stdeb_all.cfg This is not exactly
what you describe above, but it's a mapping for use by stdeb
(setuptools-to-debian-source-package converter) that goes from PyPI
names (well, the "name" field of calls to setuptools.setup() -- is that
the PyPI name?) to the names of packages created by stdeb and other
Debian packages required or conflicting.

I welcome discussions of how something like this could be expanded to be
used by easy_install so that it could query the debian dpkg system to
ask if a requirement could be installed based on the Debian repository.
It may not fit into the scope of stdeb very easily, but if it does
there'd be at least one user and maintainer -- me.

stdeb is currently completely non-Debian Python policy compliant. Among
other things, it bundles a Python package distribution in a single .deb,
which, as you indicate, is not the Debian Way. So, this means that my
mapping is basically one-to-one, whereas a one-to-many mapping is needed
to deal with Debian's official packages splitting a single Python
package distribution into multiple .debs. For use by setuptools to
automatically find and download packages, I can see we'd have to tackle
this issue, at least. Which might also move stdeb towards producing
Debian-policy compliant packages.
> Maybe in setuptools 0.7, I should provide some way of providing alternative 
> installation hooks, and then encourage people who complain about 
> Debian-related problems to write a plugin that wraps the Debian 
> tools.  Perhaps there might even be some way to use existing Debian package 
> metadata directories to find out what Debian package(s) need to be 
> installed in order to mimic a direct installation of a particular PyPI project.
>
>   
The closest thing I can think of is looking at the source package and
installing all the "binary" packages that it is capable of producing
that work on your architecture for the version of Python you're
concerned with.

Another issue is making pkg_resources.require() aware of Debian such
that it can query Debian-installed packages that happen not to be built
with setuptools. Hopefully these will be fewer over time, but currently
there are rather few built with setuptools. Or perhaps you see the
mapping as achieving this?

From pje at telecommunity.com  Tue Aug  8 03:21:16 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 07 Aug 2006 21:21:16 -0400
Subject: [Distutils] [setuptools] include files and eggs
In-Reply-To: <44D79EEE.8050300@astraw.com>
References: <5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>
	<5.1.1.6.0.20060806222151.02b7e758@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060807205255.02658880@sparrow.telecommunity.com>

At 01:13 PM 8/7/2006 -0700, Andrew Straw wrote:
>In other words, Debian is a lot of things to a lot of people,
>and some have resulted in decisions that are different from those that
>would have been made if Debian was designed to prioritize Python
>user/developer experiences over other considerations.

That's not a fair spin: the same issues apply to any circumstance where the 
developer of a piece of software has a particular intended configuration 
and provides documentation for that configuration, but Debian chooses to do 
something differently -- *without* providing effective notices of the 
modifications.

By which I mean, when they install part of Python and still call the 
package "Python", it's misleading.  Frankly, it is making me consider 
changing the licenses on my packages to a license that disallows using the 
original package name as part of a modified distribution, in order to 
prevent any possible confusion that users can expect some 
Debian-distributed thing to behave the same way as the original version.


>I have the beginnings of a related, but not identical, mapping at
>http://stdeb.python-hosting.com/wiki/stdeb_all.cfg This is not exactly
>what you describe above, but it's a mapping for use by stdeb
>(setuptools-to-debian-source-package converter) that goes from PyPI
>names (well, the "name" field of calls to setuptools.setup() -- is that
>the PyPI name?)

Yes.


>  to the names of packages created by stdeb and other
>Debian packages required or conflicting.

Right, but as you point out, this is entirely outside the scope of Debian 
proper; they may be .deb's but they're heretical ones.


>stdeb is currently completely non-Debian Python policy compliant. Among
>other things, it bundles a Python package distribution in a single .deb,
>which, as you indicate, is not the Debian Way.

Yep.  The Debian Way, if uniformly applied, would effectively preclude and 
forbid jars and gems as well as eggs.  I'm not sure whether it *actually* 
does, however.


>So, this means that my
>mapping is basically one-to-one, whereas a one-to-many mapping is needed
>to deal with Debian's official packages splitting a single Python
>package distribution into multiple .debs.

It's not even that simple, since Debian's Python policy effectively makes 
namespace packages like zope.*, peak.*, and ll.* impossible.  i.e., they 
want those to be many-to-one, despite it producing nonsensical results.


>  For use by setuptools to
>automatically find and download packages, I can see we'd have to tackle
>this issue, at least. Which might also move stdeb towards producing
>Debian-policy compliant packages.

There are only two ways to fix this:

1. Fix Debian Python policy (which is terribly broken)

2. Create a manual mapping for Debianized packages in order to maintain the 
fiction for as long as possible that the policy isn't actually broken.

People being people, you can probably guess which of these is more likely 
to happen.  :)


>Another issue is making pkg_resources.require() aware of Debian such
>that it can query Debian-installed packages that happen not to be built
>with setuptools.

That's taken care of in Python 2.5, barring any heroic measures (i.e. 
patching the distutils) by Debian developers to prevent it.  Packages built 
by the distutils with Python 2.5 produce an .egg-info file to contain the 
necessary metadata.

Of course, it's possible that Debian's song-and-dance to share source code 
across multiple Python versions will in some way break this support.  If 
that happens, I think the best thing to do would be for some people to 
develop an alternative Debian -platform Python that conforms to Python 
standards rather than Debian ones, and for the Python community at large to 
withdraw support for Debianized Python packages that don't map 1-to-1 with 
PyPI.

I'd call it a fork, except that in this case it's clearly Debian who has 
forked Python, so it would be more of an "unforking".  :)

Actually, it's not even anything as dramatic as all that.  The sanest thing 
to do is probably to work to set up infrastructure to package and 
distribute lots of PyPI projects in .deb form on an automated basis, and 
just ignore Debian Python policy altogether.  Let those who want cake eat 
cake, and spend as much time baking it as they want; meanwhile there will 
be pre-baked bread for the masses, as it were.  easy_deb and stdeb are 
clearly the right thing(s) to do; it's just that it will be a cold day in 
hell before they're considered to comply with Debian policy, so it's wasted 
effort to try.


From jim at zope.com  Tue Aug  8 16:43:28 2006
From: jim at zope.com (Jim Fulton)
Date: Tue, 8 Aug 2006 10:43:28 -0400
Subject: [Distutils] Passing build_ext arguments to easy_install?
Message-ID: <33F14758-8043-4D1A-AF21-F5A03071AD88@zope.com>


I need to install a package that depends on an external non-python  
library. I need to be able to specify the locations of the library's  
include and library files. Normally, when invoking setup.py myself,  
I'd pass these using the --include-dirs and --library-dirs options.   
Is there any way to pass this information to easy_install?

Note that the package in question doesn't use setuptools, but I want  
an egg as a result.  The only way I know how to do that is with  
easy_install.

One hack I can think of is to use --editible and --build-directory to  
download the package, write a setup.cfg into the resulting directory  
and then run easy_install on the result.  I would hope though that  
there is a better way. :)

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From pje at telecommunity.com  Tue Aug  8 17:58:19 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 08 Aug 2006 11:58:19 -0400
Subject: [Distutils] Passing build_ext arguments to easy_install?
In-Reply-To: <33F14758-8043-4D1A-AF21-F5A03071AD88@zope.com>
Message-ID: <5.1.1.6.0.20060808115421.0263bc90@sparrow.telecommunity.com>

At 10:43 AM 8/8/2006 -0400, Jim Fulton wrote:
>One hack I can think of is to use --editible and --build-directory to
>download the package, write a setup.cfg into the resulting directory
>and then run easy_install on the result.  I would hope though that
>there is a better way. :)

Not at the moment, no.  However, you could subclass easy_install and 
override the 'run_setup()' method to edit the setup.cfg first.  The 
setuptools.command.setopt module includes some nice routines for editing 
setup.cfg files, so that you won't even overwrite settings you don't care 
about.


From jim at zope.com  Tue Aug  8 18:02:55 2006
From: jim at zope.com (Jim Fulton)
Date: Tue, 8 Aug 2006 12:02:55 -0400
Subject: [Distutils] Passing build_ext arguments to easy_install?
In-Reply-To: <5.1.1.6.0.20060808115421.0263bc90@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060808115421.0263bc90@sparrow.telecommunity.com>
Message-ID: <9F518964-17A0-457A-B4AC-E7701FC71C35@zope.com>


On Aug 8, 2006, at 11:58 AM, Phillip J. Eby wrote:

> At 10:43 AM 8/8/2006 -0400, Jim Fulton wrote:
>> One hack I can think of is to use --editible and --build-directory to
>> download the package, write a setup.cfg into the resulting directory
>> and then run easy_install on the result.  I would hope though that
>> there is a better way. :)
>
> Not at the moment, no.  However, you could subclass easy_install  
> and override the 'run_setup()' method to edit the setup.cfg first.   
> The setuptools.command.setopt module includes some nice routines  
> for editing setup.cfg files, so that you won't even overwrite  
> settings you don't care about.


OK, I'll look at that when I get a chance.  Thanks. Would you be  
interested in some sort of patch for 0.7 to make it possible to pass  
this information to easy_install?

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From pje at telecommunity.com  Tue Aug  8 18:15:17 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 08 Aug 2006 12:15:17 -0400
Subject: [Distutils] Passing build_ext arguments to easy_install?
In-Reply-To: <9F518964-17A0-457A-B4AC-E7701FC71C35@zope.com>
References: <5.1.1.6.0.20060808115421.0263bc90@sparrow.telecommunity.com>
	<5.1.1.6.0.20060808115421.0263bc90@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060808121024.03b9e430@sparrow.telecommunity.com>

At 12:02 PM 8/8/2006 -0400, Jim Fulton wrote:

>On Aug 8, 2006, at 11:58 AM, Phillip J. Eby wrote:
>
>>At 10:43 AM 8/8/2006 -0400, Jim Fulton wrote:
>>>One hack I can think of is to use --editible and --build-directory to
>>>download the package, write a setup.cfg into the resulting directory
>>>and then run easy_install on the result.  I would hope though that
>>>there is a better way. :)
>>
>>Not at the moment, no.  However, you could subclass easy_install
>>and override the 'run_setup()' method to edit the setup.cfg first.
>>The setuptools.command.setopt module includes some nice routines
>>for editing setup.cfg files, so that you won't even overwrite
>>settings you don't care about.
>
>
>OK, I'll look at that when I get a chance.  Thanks. Would you be
>interested in some sort of patch for 0.7 to make it possible to pass
>this information to easy_install?

Do you mean via the command-line interface?

One thing I originally thought about doing was trying to have some way for 
the child setup to "inherit" settings from the easy_install command; that 
is, to copy default options from the parent process to the "subprocess" 
(not really a subprocess), perhaps by editing the target's setup.cfg.  But 
maybe for what you want, all you need is something like:

     easy_install --build-commands="build_ext --blah fah wah foo" whatever

The big question there of course is whether those commands should also be 
applied to dependencies.  For something like include and library dirs, it's 
probably not a problem, I'm just wondering about the general applicability.


From jim at zope.com  Tue Aug  8 20:23:15 2006
From: jim at zope.com (Jim Fulton)
Date: Tue, 8 Aug 2006 14:23:15 -0400
Subject: [Distutils] Passing build_ext arguments to easy_install?
In-Reply-To: <5.1.1.6.0.20060808121024.03b9e430@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060808115421.0263bc90@sparrow.telecommunity.com>
	<5.1.1.6.0.20060808115421.0263bc90@sparrow.telecommunity.com>
	<5.1.1.6.0.20060808121024.03b9e430@sparrow.telecommunity.com>
Message-ID: <680F25F0-A501-4113-839C-7E5D52A309A8@zope.com>


On Aug 8, 2006, at 12:15 PM, Phillip J. Eby wrote:

> At 12:02 PM 8/8/2006 -0400, Jim Fulton wrote:
>
>> On Aug 8, 2006, at 11:58 AM, Phillip J. Eby wrote:
>>
>>> At 10:43 AM 8/8/2006 -0400, Jim Fulton wrote:
>>>> One hack I can think of is to use --editible and --build- 
>>>> directory to
>>>> download the package, write a setup.cfg into the resulting  
>>>> directory
>>>> and then run easy_install on the result.  I would hope though that
>>>> there is a better way. :)
>>>
>>> Not at the moment, no.  However, you could subclass easy_install
>>> and override the 'run_setup()' method to edit the setup.cfg first.
>>> The setuptools.command.setopt module includes some nice routines
>>> for editing setup.cfg files, so that you won't even overwrite
>>> settings you don't care about.
>>
>>
>> OK, I'll look at that when I get a chance.  Thanks. Would you be
>> interested in some sort of patch for 0.7 to make it possible to pass
>> this information to easy_install?
>
> Do you mean via the command-line interface?

Yeah.  Although, ultimately, I want to escape the command-line  
interface. I'd still much rather use a Python API. I'll need to  
understand the internals a lot better.  I expect looking at the  
things you suggested will help me do that.  Generally, the farther I  
go and the more I learn of setuptools, the less I actually reply on  
easy-install.

> One thing I originally thought about doing was trying to have some  
> way for the child setup to "inherit" settings from the easy_install  
> command; that is, to copy default options from the parent process  
> to the "subprocess" (not really a subprocess), perhaps by editing  
> the target's setup.cfg.  But maybe for what you want, all you need  
> is something like:
>
>     easy_install --build-commands="build_ext --blah fah wah foo"  
> whatever
>
> The big question there of course is whether those commands should  
> also be applied to dependencies.

Probably not.

> For something like include and library dirs, it's probably not a  
> problem, I'm just wondering about the general applicability.

Yup.  All good points.  It's not obvious how to expose this.

I think what's needed is a way to say more about how a particular  
package should be
handled.  This kind of detail doesn't lend itself to command-line  
arguments, which is
why zc.buildout is command-line based. :)

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From me13013 at hotmail.com  Tue Aug  8 23:10:10 2006
From: me13013 at hotmail.com (Bob Harris)
Date: Tue, 08 Aug 2006 17:10:10 -0400
Subject: [Distutils] how to setup simple build for simple pyrex/c module
Message-ID: <BAY122-F15683D9E2AF88920641419F7540@phx.gbl>

Howdy,

I am trying to provide myself an interface to a C module from python, using 
pyrex as the glue.  I think I have all the C and pyrex correct, but am 
trying to figure out how to build it (on Mac OSX with Python 2.4 and gcc 
3.3).  My web search suggests that disutils is the proper way to build such 
a thing, even though I don't intend to distribute it to anyone but myself.  
But I am having a hard time sorting through all the documentation on 
distutils, attempting to separate the irrelevent from relevent.

I have a directory containing my myfunc.c, myfunc.h and c_myfunc.pyx.  What 
else do I need to do so that I can use distutils to build this and then 
access the functions in this module from another python program?

Thanks for any help.
Bob H

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


From pje at telecommunity.com  Wed Aug  9 00:43:22 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 08 Aug 2006 18:43:22 -0400
Subject: [Distutils] how to setup simple build for simple pyrex/c module
In-Reply-To: <BAY122-F15683D9E2AF88920641419F7540@phx.gbl>
Message-ID: <5.1.1.6.0.20060808184115.03b62060@sparrow.telecommunity.com>

At 05:10 PM 8/8/2006 -0400, Bob Harris wrote:
>I have a directory containing my myfunc.c, myfunc.h and 
>c_myfunc.pyx.  What else do I need to do so that I can use distutils to 
>build this and then access the functions in this module from another 
>python program?

This might be a good place to start:

http://ldots.org/pyrex-guide/2-compiling.html#distutils



From jim at zope.com  Fri Aug 11 15:04:35 2006
From: jim at zope.com (Jim Fulton)
Date: Fri, 11 Aug 2006 09:04:35 -0400
Subject: [Distutils] Want to use PackageIndex (and other APIs)
Message-ID: <1D822B27-FB26-48FA-AAED-3FA543FB151B@zope.com>


I'd like to start using the PackageIndex class.  For now, I want to use:

- The constructor (of course)

- prescan and

-  __getitem__.

I imagine I'll use other methods in the long term.  I'd be happy to  
document these as I go.
Is there any problem with considering these public?

As I mentioned the other day, my plan to to make more use of  
setuptools and less use of easy_install in zc.buildout, until I  
eventually don't use easy_install at all.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From jim at zope.com  Fri Aug 11 20:07:02 2006
From: jim at zope.com (Jim Fulton)
Date: Fri, 11 Aug 2006 14:07:02 -0400
Subject: [Distutils] pkg_resources.declare_namespace vs pkgutil.extend_path
Message-ID: <C1AE27A3-C4EE-4A59-B0DF-28805D0A9081@zope.com>


We currently have two ways of implementing namespace packages,

   pkg_resources.declare_namespace vs pkgutil.extend_path

Do we need 2?

What does pkg_resources.declare_namespace do that pkgutil.extend_path  
does, other than provide zip file support?  Can we consolidate them  
somehow?

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From pje at telecommunity.com  Fri Aug 11 21:38:31 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 11 Aug 2006 15:38:31 -0400
Subject: [Distutils] pkg_resources.declare_namespace vs
 pkgutil.extend_path
In-Reply-To: <C1AE27A3-C4EE-4A59-B0DF-28805D0A9081@zope.com>
Message-ID: <5.1.1.6.0.20060811153445.03c9e368@sparrow.telecommunity.com>

At 02:07 PM 8/11/2006 -0400, Jim Fulton wrote:

>We currently have two ways of implementing namespace packages,
>
>    pkg_resources.declare_namespace vs pkgutil.extend_path
>
>Do we need 2?

Um, maybe?  :)


>What does pkg_resources.declare_namespace do that pkgutil.extend_path
>does, other than provide zip file support?

It provides open-ended extensible support for arbitrary importers, not just 
zip files.  It also tracks which packages are namespace packages so that 
when new items are added to sys.path, the existing packages can be "fixed 
up" to include the appropriate variant of the new path.


>   Can we consolidate them
>somehow?

Not in any way that I know of.  You should use declare_namespace() unless 
you need .pkg files, because declare_namespace() supports PEP 302, while 
extend_path() assumes all sys.path entries are directories.  I don't really 
understand what .pkg files are for, so declare_namespace() doesn't support 
them at this time.


From jim at zope.com  Wed Aug 16 23:22:05 2006
From: jim at zope.com (Jim Fulton)
Date: Wed, 16 Aug 2006 17:22:05 -0400
Subject: [Distutils] "zip_safe flag not set;
	analyzing archive contents..." should be info, not a warning
Message-ID: <85FCE342-B26F-432F-B3CD-F5ADE314AA0F@zope.com>


IMO, the message "zip_safe flag not set; analyzing archive  
contents..." should be an info message, not a warning message, at  
lease when processing non-setuptools-based source distribution.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From jim at zope.com  Mon Aug 21 22:32:36 2006
From: jim at zope.com (Jim Fulton)
Date: Mon, 21 Aug 2006 16:32:36 -0400
Subject: [Distutils] Problems with cli.exe
Message-ID: <C5CA406B-9CF2-4DAF-AA04-F3CBEFC11F69@zope.com>


I've found a bug with cli.exe and a missing feature.

The bug is that arguments containing embedded spaces aren't handled  
correctly.
For example, suppose you have foo-script.py and a copy of cli.exe  
named foo.exe.
If you call foo.exe with a single argument, like this:

   foo "a b"

then foo-script.py will be called with 2 arguments, "a", and "b",  
rather than a single argument, "a b".

The missing feature is that options on the #! line aren't honored. It  
would be nice if, for example, a script beginning like:

   #!\Python24\python.exe -O

would run Python in optimized mode.

I'd be happy to take a crack at fixing the bug and adding the  
feature.  Where is the source?

I assume that this also applies to gui.exe.

BTW, Shouldn't the setuptools project be moved out of sandbox and be  
made a proper svn project with it's own trunk, branches, and tags?

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From pje at telecommunity.com  Mon Aug 21 22:41:46 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 21 Aug 2006 16:41:46 -0400
Subject: [Distutils] Problems with cli.exe
In-Reply-To: <C5CA406B-9CF2-4DAF-AA04-F3CBEFC11F69@zope.com>
Message-ID: <5.1.1.6.0.20060821163924.02521aa8@sparrow.telecommunity.com>

At 04:32 PM 8/21/2006 -0400, Jim Fulton wrote:

>I've found a bug with cli.exe and a missing feature.
>
>The bug is that arguments containing embedded spaces aren't handled
>correctly.
>For example, suppose you have foo-script.py and a copy of cli.exe
>named foo.exe.
>If you call foo.exe with a single argument, like this:
>
>    foo "a b"
>
>then foo-script.py will be called with 2 arguments, "a", and "b",
>rather than a single argument, "a b".
>
>The missing feature is that options on the #! line aren't honored. It
>would be nice if, for example, a script beginning like:
>
>    #!\Python24\python.exe -O
>
>would run Python in optimized mode.
>
>I'd be happy to take a crack at fixing the bug and adding the
>feature.

Thanks!  Please watch out for making sure that the following are still 
supported after your changes:

* Non-ASCII paths to python.exe
* Embedded spaces in the path to python.exe


>Where is the source?

launcher.c in the root of the setuptools checkout.


>I assume that this also applies to gui.exe.

Yes; both are compiled from the same source.


>BTW, Shouldn't the setuptools project be moved out of sandbox and be
>made a proper svn project with it's own trunk, branches, and tags?

Dunno; setuptools' presence in the sandbox predates the use of SVN for 
Python.  In any case, I'm more than happy with the status quo.  Note that 
there is also a branch for 0.6 maintenance in sandbox/branches.


From casbon at gmail.com  Tue Aug 22 09:57:40 2006
From: casbon at gmail.com (James Casbon)
Date: Tue, 22 Aug 2006 08:57:40 +0100
Subject: [Distutils] pkgfile entry points
Message-ID: <15d850bd0608220057m73bbc3dbw3ecc625ca913a5c4@mail.gmail.com>

Hi,

I have an app which makes heavy use of rich ini style configuration files. I
would like to add the ability to extend it using pkg_resources entry
points.  It seems quite natural here to use the entry point to refer to the
plugin configuration data like so:

[myapp.extension]
something = pkgfile:extension/config.ini

This single point would allow me to get the config data for the plugin.
Now, at the moment this style of entry point is not supported.  I could
potentially get round this by asking all plugins to define an entry point
method that returns the location of the configuration file, but that just
creates another piece of tedious boilerplate to write.

So, I'm wondering whether the inability to supply pkgfiles as entry points
is a deliberate design decision or just something that hadn't been
anticipated?  You might suggest that the configuration should be done as
entry points.  However, the ini file structure used is more rich than
supported by entry points and to use them would require moving lots of
configuration data into python code.  I do therefore think that this is a
legitimate use.

thanks,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20060822/b1618f69/attachment.htm 

From jim at zope.com  Tue Aug 22 20:56:36 2006
From: jim at zope.com (Jim Fulton)
Date: Tue, 22 Aug 2006 14:56:36 -0400
Subject: [Distutils] Problems with cli.exe
In-Reply-To: <5.1.1.6.0.20060821163924.02521aa8@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060821163924.02521aa8@sparrow.telecommunity.com>
Message-ID: <903A0DAC-5201-4E77-9089-EFFAE4801DA9@zope.com>

Phillip,

I'v updated launcher.c, cli.exe, and gui.exe on the jim-fix- 
setuptools-cli branch.
I've also added a doctest for cli.exe.

The update:

- Causes script arguments to be quoted with correct handling of embedded
   double quotes.   This allows passing arguments with embedded spaces
   and double quotes to scripts.

- Added support for passing a single argument (possibly specifying  
multiple
   options) to the Python executable on the #! line.

- Fixed a bug in handling trailing spaces on the #! line.

Let me know if you'd like me to merge this to the 0.6 branch and trunk.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From pje at telecommunity.com  Tue Aug 22 21:21:58 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 22 Aug 2006 15:21:58 -0400
Subject: [Distutils] Problems with cli.exe
In-Reply-To: <903A0DAC-5201-4E77-9089-EFFAE4801DA9@zope.com>
References: <5.1.1.6.0.20060821163924.02521aa8@sparrow.telecommunity.com>
	<5.1.1.6.0.20060821163924.02521aa8@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060822151837.022bb8b8@sparrow.telecommunity.com>

At 02:56 PM 8/22/2006 -0400, Jim Fulton wrote:
>Phillip,
>
>I'v updated launcher.c, cli.exe, and gui.exe on the jim-fix- 
>setuptools-cli branch.
>I've also added a doctest for cli.exe.
>
>The update:
>
>- Causes script arguments to be quoted with correct handling of embedded
>   double quotes.   This allows passing arguments with embedded spaces
>   and double quotes to scripts.
>
>- Added support for passing a single argument (possibly specifying
>multiple
>   options) to the Python executable on the #! line.
>
>- Fixed a bug in handling trailing spaces on the #! line.

Fantastic, thank you very much!


>Let me know if you'd like me to merge this to the 0.6 branch and trunk.

Yes, please.  I'll take care of updating the release notes for 0.6c2.

By the way, just for future reference, you don't need to branch the entire 
sandbox to work on a setuptools branch.  Notice, for example, that the 
setuptools-0.6 branch is just a copy of the sandbox/setuptools 
directory.  This is in fact the standard way to do branches and tags in the 
Python sandbox (i.e., just branch or tag the individual project, not the 
entire sandbox).


From pje at telecommunity.com  Tue Aug 22 21:30:48 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 22 Aug 2006 15:30:48 -0400
Subject: [Distutils] pkgfile entry points
In-Reply-To: <15d850bd0608220057m73bbc3dbw3ecc625ca913a5c4@mail.gmail.co
 m>
Message-ID: <5.1.1.6.0.20060822152203.0297f8a8@sparrow.telecommunity.com>

At 08:57 AM 8/22/2006 +0100, James Casbon wrote:
>Hi,
>
>I have an app which makes heavy use of rich ini style configuration files. 
>I would like to add the ability to extend it using pkg_resources entry 
>points.  It seems quite natural here to use the entry point to refer to 
>the plugin configuration data like so:
>
>[myapp.extension]
>something = pkgfile:extension/config.ini
>
>This single point would allow me to get the config data for the 
>plugin.  Now, at the moment this style of entry point is not supported.  I 
>could potentially get round this by asking all plugins to define an entry 
>point method that returns the location of the configuration file, but that 
>just creates another piece of tedious boilerplate to write.
>
>So, I'm wondering whether the inability to supply pkgfiles as entry points 
>is a deliberate design decision or just something that hadn't been anticipated?

It wasn't anticipated, and yes, there have been other things that have come 
up since where it would've been useful (e.g. i18n).

I considered making some changes to the format to allow some extensibility, 
but there isn't an easy way to maintain compatibility across setuptools 
versions with such changes.

So, instead my thought is this: setuptools already allows any characters 
you want on the left side of the '=' sign, except for '='.  So, you already 
have the ability to add arbitrary metadata to an entry point's name, e.g.:

    something (file:config.ini) = packagename

As long as you do the parsing in your own code, this will work with any 
setuptools version.  The string can be arbitrarily long, too, so you could 
define any number of 'prefix:value' variables.

In general, I'm thinking that setuptools 0.7 will offer some kind of 
built-in (but optional) support for this kind of parsing and metadata, so 
that you can both specify it more easily in setup.py and handle it more 
easily in code.


From jim at zope.com  Tue Aug 22 22:01:07 2006
From: jim at zope.com (Jim Fulton)
Date: Tue, 22 Aug 2006 16:01:07 -0400
Subject: [Distutils] Problems with cli.exe
In-Reply-To: <5.1.1.6.0.20060822151837.022bb8b8@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060821163924.02521aa8@sparrow.telecommunity.com>
	<5.1.1.6.0.20060821163924.02521aa8@sparrow.telecommunity.com>
	<5.1.1.6.0.20060822151837.022bb8b8@sparrow.telecommunity.com>
Message-ID: <65AA9AF6-3798-41B7-85C4-2AC4DD456916@zope.com>


On Aug 22, 2006, at 3:21 PM, Phillip J. Eby wrote:

>> Let me know if you'd like me to merge this to the 0.6 branch and  
>> trunk.
>
> Yes, please.  I'll take care of updating the release notes for 0.6c2.

Done.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org




From scott.finnie at virgin.net  Tue Aug 22 21:52:54 2006
From: scott.finnie at virgin.net (Scott Finnie)
Date: Tue, 22 Aug 2006 20:52:54 +0100
Subject: [Distutils] dumb newbie...?
Message-ID: <44EB6096.6030105@virgin.net>

Please be gentle...

Newbie to distutils, trying to install django 0.95 egg 
(www.djangoproject.com) from behind a corporate windows firewall. 
django in turn tries to download and install setuptools - which fails 
due to firewall.  As per ez_setup.py error message, I downloaded the 
setuptools egg, put it in the same dir and re-ran: but got same message.

Took a look at the code and found out why (expects the egg to be in the 
temp dir, not same dir).

Strikes me it's most likely I was doing something wrong / missed an 
option / some other rudimentary mistake.  Assuming that's the case, 
could someone set me straight?

In the unlikely event I've found a bug I've attached a patched version 
below.  Note the patch is anything but elegant, driven by minimal change 
rather than elegant solution.  Very un-pythonic I know.

Like I said, please be gentle...

  - Scoot.
--
def download_setuptools(
     version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir,
     delay = 15
):
     """Download setuptools from a specified location and return its 
filename

     `version` should be a valid setuptools version number that is available
     as an egg for download under the `download_base` URL (which should end
     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
     egg_name = "setuptools-%s-py%s.egg" % (version,sys.version[:3])
     saveto = os.path.join(to_dir, egg_name)
     #------------------------------------------------
     #Change begins
     #Don't download if the egg is in the current dir.
     #This is a horrible hack; should check for existence
     #in calling routine and possibly skip temp dir creation
     #altogether - depends on whether it's used subsequently by
     #setuptools.
     try:
         os.stat(egg_name)
         shutil.copyfile(egg_name, saveto)
     except:
     # change ends (remainder indented though)
     #------------------------------------------------
         url = download_base + egg_name
         src = dst = None
         if not os.path.exists(saveto):  # Avoid repeated downloads
             try:
                 from distutils import log
                 if delay:
                     log.warn("""
 
---------------------------------------------------------------------------
     This script requires setuptools version %s to run (even to display
     help).  I will attempt to download it for you (from
     %s), but
     you may need to enable firewall access for this script first.
     I will start the download in %d seconds.

     (Note: if this machine does not have network access, please obtain 
the file

        %s

     and place it in this directory before rerunning this script.)
 
---------------------------------------------------------------------------""",
                         version, download_base, delay, url
                     ); from time import sleep; sleep(delay)
                 log.warn("Downloading %s", url)
                 src = urllib2.urlopen(url)
                 # Read/write all in one block, so we don't create a 
corrupt file
                 # if the download is interrupted.
                 data = _validate_md5(egg_name, src.read())
                 dst = open(saveto,"wb"); dst.write(data)
             finally:
                 if src: src.close()
                 if dst: dst.close()
     return os.path.realpath(saveto)

From pje at telecommunity.com  Tue Aug 22 23:08:34 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 22 Aug 2006 17:08:34 -0400
Subject: [Distutils] dumb newbie...?
In-Reply-To: <44EB6096.6030105@virgin.net>
Message-ID: <5.1.1.6.0.20060822170637.025ce328@sparrow.telecommunity.com>

At 08:52 PM 8/22/2006 +0100, Scott Finnie wrote:
>Please be gentle...
>
>Newbie to distutils, trying to install django 0.95 egg
>(www.djangoproject.com) from behind a corporate windows firewall.
>django in turn tries to download and install setuptools - which fails
>due to firewall.  As per ez_setup.py error message, I downloaded the
>setuptools egg, put it in the same dir and re-ran: but got same message.

Were you running setup.py or ez_setup.py?

Running ez_setup.py downloads to a temporary directory; running setup.py 
should've looked in the current directory and worked correctly.


From scott.finnie at virgin.net  Wed Aug 23 01:34:44 2006
From: scott.finnie at virgin.net (Scott Finnie)
Date: Wed, 23 Aug 2006 00:34:44 +0100
Subject: [Distutils] dumb newbie...?
In-Reply-To: <5.1.1.6.0.20060822170637.025ce328@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060822170637.025ce328@sparrow.telecommunity.com>
Message-ID: <44EB9494.8070009@virgin.net>

Phillip,

Thanks for reply.

I used ez_setup.py per instructions here: 
http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions

Looks like I should've used setup.py instead. That being the case, 
perhaps the text should be reworded - it currently says:

"Place the egg in the same directory as ez_setup.py on the target 
computer before running it."

Cheers,
Scoot.


Phillip J. Eby wrote:
> At 08:52 PM 8/22/2006 +0100, Scott Finnie wrote:
>> Please be gentle...
>>
>> Newbie to distutils, trying to install django 0.95 egg
>> (www.djangoproject.com) from behind a corporate windows firewall.
>> django in turn tries to download and install setuptools - which fails
>> due to firewall.  As per ez_setup.py error message, I downloaded the
>> setuptools egg, put it in the same dir and re-ran: but got same message.
> 
> Were you running setup.py or ez_setup.py?
> 
> Running ez_setup.py downloads to a temporary directory; running setup.py 
> should've looked in the current directory and worked correctly.
> 
> 

From pje at telecommunity.com  Wed Aug 23 02:12:55 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 22 Aug 2006 20:12:55 -0400
Subject: [Distutils] dumb newbie...?
In-Reply-To: <44EB9494.8070009@virgin.net>
References: <5.1.1.6.0.20060822170637.025ce328@sparrow.telecommunity.com>
	<5.1.1.6.0.20060822170637.025ce328@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060822200840.02a0a898@sparrow.telecommunity.com>

At 12:34 AM 8/23/2006 +0100, Scott Finnie wrote:
>Phillip,
>
>Thanks for reply.
>
>I used ez_setup.py per instructions here: 
>http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions
>
>Looks like I should've used setup.py instead. That being the case, perhaps 
>the text should be reworded - it currently says:
>
>"Place the egg in the same directory as ez_setup.py on the target computer 
>before running it."

Those are the instructions for installing setuptools, not Django.

The error message that would've shown when you tried to install Django 
(following its instructions) would have said (with the appropriate blanks 
filled in):

---------------------------------------------------------------------------
This script requires setuptools version %s to run (even to display
help).  I will attempt to download it for you (from
%s), but
you may need to enable firewall access for this script first.
I will start the download in %d seconds.

(Note: if this machine does not have network access, please obtain the file

    %s

and place it in this directory before rerunning this script.)
---------------------------------------------------------------------------

i.e., rerunning setup.py, which would've triggered the message in the first 
place.

In other words, all of the documentation is correct, but the implementation 
is wrong.  :)

More specifically, everything in your case would've worked fine from 
following the Django instructions + error message, but a standalone 
setuptools installation doesn't necessarily work as advertised, so I'll 
look into doing something similar to your patch.

Thanks for the problem report.


From krokodylek at tenbit.pl  Thu Aug 24 16:46:09 2006
From: krokodylek at tenbit.pl (krokodylek at tenbit.pl)
Date: Thu, 24 Aug 2006 16:46:09 CEST
Subject: [Distutils] setuptools and python-2.3.4
Message-ID: <E1GGGTB-0006fc-00@ap-04>


Hi :-)

I want to use some plugins for Trac, which come in source code and require setuptools for install. The server with Trac is running on Fedora Core 3 and has python 2.3.4 (tha latest packaged version for the system)

I've visited setuptools' website (http://peak.telecommunity.com/DevCenter/setuptools) and it says in couple of places that the minimal requirement is python 2.3.5... I want to ask if any of you know it is safe to use setuptools with python-2.3.4? As far as I know 2.3.5 is "only" a bugfix release...

I can't test it myself because the machine is a production server ;-)

I will be very grateful for any help.

Best regards,
Maciej Zieba





From pje at telecommunity.com  Thu Aug 24 18:16:14 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 24 Aug 2006 12:16:14 -0400
Subject: [Distutils] setuptools and python-2.3.4
In-Reply-To: <E1GGGTB-0006fc-00@ap-04>
Message-ID: <5.1.1.6.0.20060824121455.022a7ca0@sparrow.telecommunity.com>

At 04:46 PM 8/24/2006 +0000, krokodylek at tenbit.pl wrote:

>Hi :-)
>
>I want to use some plugins for Trac, which come in source code and require 
>setuptools for install. The server with Trac is running on Fedora Core 3 
>and has python 2.3.4 (tha latest packaged version for the system)
>
>I've visited setuptools' website 
>(http://peak.telecommunity.com/DevCenter/setuptools) and it says in couple 
>of places that the minimal requirement is python 2.3.5... I want to ask if 
>any of you know it is safe to use setuptools with python-2.3.4? As far as 
>I know 2.3.5 is "only" a bugfix release...

2.3.5 has a bug fix for the use of reload() with modules contained in zip 
files, so it's recommended.  However, if you never use reload() with a 
module that might be in a zip file, you can probably get away with 2.3.4.


From Jonathan.Peirce at nottingham.ac.uk  Thu Aug 24 19:44:09 2006
From: Jonathan.Peirce at nottingham.ac.uk (Jon Peirce)
Date: Thu, 24 Aug 2006 18:44:09 +0100
Subject: [Distutils] [setuptools] running a post_install script
Message-ID: <44EDE569.5060301@psychology.nottingham.ac.uk>

I've just been discovering the beauties of setuptools - for someone like 
me, developing a package with many dependencies, it could be just the 
tonic! And very easy to get going too - thnks!

One question though - my package carries a post-install script to create 
a few shortcuts on windows systems. Creating an egg and then 
easy_installing it copies a setuptools version of the script to the 
scripts folder but it doesn't run at the end of install (or maybe it 
tries to and fails in some hidden way). The script does use the special 
functions from distutils [like get_special_folder_path(csidl_string)] 
and maybe these aren't available to setuptools?

Am I missing something? Should it run? Or is it a simple limitation of 
eggs that they can't do this?

The post-install script is attached below.

thanks
Jon

http://www.psychopy.org/


#--------------------------------------
##-----------------------------
##Windows post install (shortcuts etc...)
##-----------------------------
import sys, os

def install():
    print "Adding shortcuts to >>Start>Programs>PsychoPy"
    progsFolder= get_special_folder_path("CSIDL_COMMON_PROGRAMS")
    sitePackages = os.path.join(sys.prefix , 'lib','site-packages')
   
    #Psychopy Programs folder
    psychopyShortcuts = os.path.join(progsFolder, 'PsychoPy')
    if not os.path.isdir(psychopyShortcuts):
        os.mkdir(psychopyShortcuts)
        directory_created(psychopyShortcuts)
       
    #monitor center
    monitorCenterLink=os.path.join(psychopyShortcuts, "MonitorCenter.lnk")
    if os.path.isfile(monitorCenterLink):   
        os.remove(monitorCenterLink)#we want to make a new one
    
create_shortcut(os.path.join(sitePackages,'monitors','MonitorCenter.py'),
                        'PsychoPy Monitor Center', monitorCenterLink)
    file_created(monitorCenterLink)
   
    #homepage
    homePageLink = os.path.join(psychopyShortcuts, "PsychoPyHome.lnk")
    if os.path.isfile(homePageLink):   
        os.remove(homePageLink)#we want to make a new one
    create_shortcut(r"http://www.psychopy.org",
                        'PsychoPy HomePage', homePageLink)
    file_created(homePageLink)
       
    print "All done. Enjoy!"

if len(sys.argv) > 1:
    if sys.argv[1] == '-install':
        install()
    else:
        print "Script was called with option %s" % sys.argv[1]


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.


From pje at telecommunity.com  Thu Aug 24 22:44:27 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 24 Aug 2006 16:44:27 -0400
Subject: [Distutils] [setuptools] running a post_install script
In-Reply-To: <44EDE569.5060301@psychology.nottingham.ac.uk>
Message-ID: <5.1.1.6.0.20060824163935.0422c798@sparrow.telecommunity.com>

At 06:44 PM 8/24/2006 +0100, Jon Peirce wrote:
>I've just been discovering the beauties of setuptools - for someone like
>me, developing a package with many dependencies, it could be just the
>tonic! And very easy to get going too - thnks!
>
>One question though - my package carries a post-install script to create
>a few shortcuts on windows systems. Creating an egg and then
>easy_installing it copies a setuptools version of the script to the
>scripts folder but it doesn't run at the end of install (or maybe it
>tries to and fails in some hidden way).

easy_install doesn't support post-install scripts, currently, as it's 
designed for installation of libraries rather than applications.

It's possible that some future version of easy_install could support a 
mechanism for various kinds of post-install hooks, in order to allow e.g. 
shortcut registration, registry entries, and the like.  The idea would be 
that a package would include metadata that describes the registration info 
needed, rather than including code to actually do the registration.  (The 
idea here being that we're not opening up for arbitrary code to run during 
installation.)

But at this point, such a feature is a rather long way off.  So for now, 
it's best to just instruct users how to run your postinstall script (which 
ideally should be given a name that's unique to your package, e.g. 
'foo-postinstall' if your package is named foo).


From pje at telecommunity.com  Thu Aug 24 22:58:26 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 24 Aug 2006 16:58:26 -0400
Subject: [Distutils] setuptools and python-2.3.4
In-Reply-To: <44EE0E66.9090503@tenbit.pl>
References: <5.1.1.6.0.20060824121455.022a7ca0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060824121455.022a7ca0@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060824165730.0278b008@sparrow.telecommunity.com>

At 10:39 PM 8/24/2006 +0200, =?windows-1252?Q?Maciej_Zie=3Bba?= wrote:
>Hi :-)
>
>Thank you for your response :-)
>
>Are python eggs "modules in a zip file"?

Yes.


>  I'm asking because trac plugins build such eggs...

Well, if they're going to be reloaded using reload(), they may not work 
correctly with Python 2.3.4.  But if reload() isn't used, you shouldn't 
have any problems.


From krokodylek at tenbit.pl  Thu Aug 24 22:39:02 2006
From: krokodylek at tenbit.pl (=?windows-1252?Q?Maciej_Zie=3Bba?=)
Date: Thu, 24 Aug 2006 22:39:02 +0200
Subject: [Distutils] setuptools and python-2.3.4
In-Reply-To: <5.1.1.6.0.20060824121455.022a7ca0@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060824121455.022a7ca0@sparrow.telecommunity.com>
Message-ID: <44EE0E66.9090503@tenbit.pl>

Hi :-)

Thank you for your response :-)

Are python eggs "modules in a zip file"? I'm asking because trac plugins 
build such eggs...

Best regards,
Maciek

Phillip J. Eby napisa?(a):
> At 04:46 PM 8/24/2006 +0000, krokodylek at tenbit.pl wrote:
> 
>> Hi :-)
>>
>> I want to use some plugins for Trac, which come in source code and 
>> require setuptools for install. The server with Trac is running on 
>> Fedora Core 3 and has python 2.3.4 (tha latest packaged version for 
>> the system)
>>
>> I've visited setuptools' website 
>> (http://peak.telecommunity.com/DevCenter/setuptools) and it says in 
>> couple of places that the minimal requirement is python 2.3.5... I 
>> want to ask if any of you know it is safe to use setuptools with 
>> python-2.3.4? As far as I know 2.3.5 is "only" a bugfix release...
> 
> 2.3.5 has a bug fix for the use of reload() with modules contained in 
> zip files, so it's recommended.  However, if you never use reload() with 
> a module that might be in a zip file, you can probably get away with 2.3.4.


From rlratzel at enthought.com  Fri Aug 25 00:01:33 2006
From: rlratzel at enthought.com (Rick Ratzel)
Date: Thu, 24 Aug 2006 17:01:33 -0500 (CDT)
Subject: [Distutils] [setuptools] running a post_install script
Message-ID: <20060824220133.99D60B3C@mail.enthought.com>


>   >I've just been discovering the beauties of setuptools - for someone like
>   >me, developing a package with many dependencies, it could be just the
>   >tonic! And very easy to get going too - thnks!
>   >
>   >One question though - my package carries a post-install script to create
>   >a few shortcuts on windows systems. Creating an egg and then
>   >easy_installing it copies a setuptools version of the script to the
>   >scripts folder but it doesn't run at the end of install (or maybe it
>   >tries to and fails in some hidden way).
>
>   easy_install doesn't support post-install scripts, currently, as it's 
>   designed for installation of libraries rather than applications.
>
>   It's possible that some future version of easy_install could support a 
>   mechanism for various kinds of post-install hooks, in order to allow e.g. 
>   shortcut registration, registry entries, and the like.  The idea would be 
>   that a package would include metadata that describes the registration info 
>   needed, rather than including code to actually do the registration.  (The 
>   idea here being that we're not opening up for arbitrary code to run during 
>   installation.)
>
>   But at this point, such a feature is a rather long way off.  So for now, 
>   it's best to just instruct users how to run your postinstall script (which 
>   ideally should be given a name that's unique to your package, e.g. 
>   'foo-postinstall' if your package is named foo).

   Here at Enthought, we're developing an application which provides a graphical
user interface to easy_install which also adds additional features that we need
in order to deploy some of the libraries we use in egg form.  One of the
additional features we need is the ability to run post-install scripts.

   The application is named "Enstaller" and is currently available only as an
alpha right now, and only for Windows.  Enstaller will eventually be used as the
means for distributing "Python Enthought Edition".  At the moment, the stable
versions of Python Enthought Edition are distributed as a massive Wise .exe
installer...Enstaller allows users to pick and choose the individual packages
provided by Enthought rather than downloading several which they don't need.  It
also allows a user to browse and install from the Python Cheeseshop.

   In order to distribute the complete Python Enthought Edition in egg-form, we
had to make eggs for two applications which are bundled in the big .exe file:
Swig and MinGW.  The post-install scripts bundled with those eggs add their dirs
to the search PATH.  Another egg we have is for VTK, and it's post-install
script adds one of the dirs to the search PATH so it's .dlls are found.  Also,
our pywin32 egg has a post-install script which runs to do the various registry
mods that the pywin32 .exe installer does.

   Currently, only Enstaller knows how to run these post-install scripts.  If
the egg it just installed has a "post_install.py" script in EGG-INFO, it runs
it.  The post_install.py script calls, in an order defined at egg-build time,
the scripts in EGG-INFO/post_install.

   At the moment, this does allow for arbitrary code to run during install,
which has the potential to be bad.  We needed something to allow this given the
many diverse packages we offer in Python Enthought Edition though, but I imagine
future versions won't allow this and will instead be more like what Phillip
suggested by only allowing specific registration operations.

   If you'd like to check it out, the link to the Python 2.4.3 Enthought Edition
1.1.0 download page (has a link to a Python-2.4 .exe installer which runs
Enstaller at the end to add the Enthought Edition packages, as well a link to
the Enstaller bootstrap script if you wish to use an existing Python 2.4 Windows
install) is here:

 http://code.enthought.com/enthon/enstaller.shtml

   ...and the Enstaller wiki is here:

 http://enthought.com/enthought/wiki/Enstaller

   Remember that a.) it's still alpha and undergoing frequent changes, and b.)
while it can run on other platforms, the packages it requires to get it properly
bootstrapped are only available for Windows and Python 2.4...that will change
soon though.

   Hope this helps!

-- 
Rick Ratzel - Enthought, Inc.
515 Congress Avenue, Suite 2100 - Austin, Texas 78701
512-536-1057 x229 - Fax: 512-536-1059
http://www.enthought.com


From hbl at st-andrews.ac.uk  Wed Aug 30 20:01:59 2006
From: hbl at st-andrews.ac.uk (Hamish Lawson)
Date: Wed, 30 Aug 2006 19:01:59 +0100
Subject: [Distutils] Spurious "required version not available" error for
	setuptools?
Message-ID: <9acacaa50608301101q230a6653re680da82fc469e8f@mail.gmail.com>

I have version 0.6c1 of setuptools installed, but when I try to
easy_install Kid from subversion:

    easy_install svn://kid-templating.org/trunk

I get this error message:

    The required version of setuptools (>=0.6a11) is not available

Any pointers to why?

Thanks,
Hamish Lawson

From pje at telecommunity.com  Wed Aug 30 20:59:55 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 30 Aug 2006 14:59:55 -0400
Subject: [Distutils] Spurious "required version not available" error for
 setuptools?
In-Reply-To: <9acacaa50608301101q230a6653re680da82fc469e8f@mail.gmail.co
 m>
Message-ID: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>

At 07:01 PM 8/30/2006 +0100, Hamish Lawson wrote:
>I have version 0.6c1 of setuptools installed, but when I try to
>easy_install Kid from subversion:
>
>     easy_install svn://kid-templating.org/trunk
>
>I get this error message:
>
>     The required version of setuptools (>=0.6a11) is not available
>
>Any pointers to why?

No idea; it works fine for me.  Does "easy_install --help" work?


From hbl at st-andrews.ac.uk  Wed Aug 30 21:05:55 2006
From: hbl at st-andrews.ac.uk (Hamish Lawson)
Date: Wed, 30 Aug 2006 20:05:55 +0100
Subject: [Distutils] Spurious "required version not available" error for
	setuptools?
In-Reply-To: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
Message-ID: <9acacaa50608301205k2b1037a2w8c763eb3e87fe56a@mail.gmail.com>

Phillip J. Eby wrote:

> No idea; it works fine for me.  Does "easy_install --help" work?

Yes.

From pje at telecommunity.com  Wed Aug 30 21:09:40 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 30 Aug 2006 15:09:40 -0400
Subject: [Distutils] Spurious "required version not available" error for
 setuptools?
In-Reply-To: <9acacaa50608301205k2b1037a2w8c763eb3e87fe56a@mail.gmail.co
 m>
References: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>

At 08:05 PM 8/30/2006 +0100, Hamish Lawson wrote:
>Phillip J. Eby wrote:
>
>>No idea; it works fine for me.  Does "easy_install --help" work?
>
>Yes.

Well, try "easy_install -U setuptools"; it's possible your current 
installation isn't actually 0.6c1.  (If you're on Windows, use "ez_setup.py 
-U setuptools" instead).


From hbl at st-andrews.ac.uk  Wed Aug 30 21:14:07 2006
From: hbl at st-andrews.ac.uk (Hamish Lawson)
Date: Wed, 30 Aug 2006 20:14:07 +0100
Subject: [Distutils] Spurious "required version not available" error for
	setuptools?
In-Reply-To: <5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
Message-ID: <9acacaa50608301214t56e9359v5c15749c241bf712@mail.gmail.com>

Phillip J. Eby wrote:

> Well, try "easy_install -U setuptools"; it's possible your current
> installation isn't actually 0.6c1.

Output:

"""
Searching for setuptools
Reading http://www.python.org/pypi/setuptools/
Reading http://peak.telecommunity.com/DevCenter/setuptools
Reading http://www.python.org/pypi/setuptools/UNKNOWN
Best match: setuptools 0.6c1
Processing setuptools-0.6c1-py2.4.egg
setuptools 0.6c1 is already the active version in easy-install.pth
Installing easy_install script to /usr/local/python/bin
Installing easy_install-2.4 script to /usr/local/python/bin

Using /usr/local/python/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg
Processing dependencies for setuptools
"""

But stil the same error after.

From pje at telecommunity.com  Wed Aug 30 21:50:46 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 30 Aug 2006 15:50:46 -0400
Subject: [Distutils] Spurious "required version not available" error for
 setuptools?
In-Reply-To: <9acacaa50608301214t56e9359v5c15749c241bf712@mail.gmail.com
 >
References: <5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>

At 08:14 PM 8/30/2006 +0100, Hamish Lawson wrote:
>Phillip J. Eby wrote:
>
>>Well, try "easy_install -U setuptools"; it's possible your current
>>installation isn't actually 0.6c1.
>
>Output:
>
>"""
>Searching for setuptools
>Reading http://www.python.org/pypi/setuptools/
>Reading http://peak.telecommunity.com/DevCenter/setuptools
>Reading http://www.python.org/pypi/setuptools/UNKNOWN
>Best match: setuptools 0.6c1
>Processing setuptools-0.6c1-py2.4.egg
>setuptools 0.6c1 is already the active version in easy-install.pth
>Installing easy_install script to /usr/local/python/bin
>Installing easy_install-2.4 script to /usr/local/python/bin
>
>Using /usr/local/python/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg
>Processing dependencies for setuptools
>"""
>
>But stil the same error after.

Would you mind including the entire log of the error, too?  Thanks.


From hbl at st-andrews.ac.uk  Thu Aug 31 09:56:01 2006
From: hbl at st-andrews.ac.uk (Hamish Lawson)
Date: Thu, 31 Aug 2006 08:56:01 +0100
Subject: [Distutils] Spurious "required version not available" error for
	setuptools?
In-Reply-To: <5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>
Message-ID: <9acacaa50608310056o5c05ec4dn37ea54a64893e8e2@mail.gmail.com>

Phillip J. Eby wrote:

> Would you mind including the entire log of the error, too?  Thanks.

----
robin-hbl% easy_install svn://kid-templating.org/trunk
Doing subversion checkout from svn://kid-templating.org/trunk to
/tmp/easy_install-OW_QLh/trunk
Processing trunk
Running setup.py -q bdist_egg --dist-dir
/tmp/easy_install-OW_QLh/trunk/egg-dist-tmp-UO9-nX
The required version of setuptools (>=0.6a11) is not available, and
can't be installed while this script is running. Please install
 a more recent version first.
error: Setup script exited with 2
----

Thanks for looking at this,

Hamish

From hbl at st-andrews.ac.uk  Thu Aug 31 11:46:40 2006
From: hbl at st-andrews.ac.uk (Hamish Lawson)
Date: Thu, 31 Aug 2006 10:46:40 +0100
Subject: [Distutils] Spurious "required version not available" error for
	setuptools?
In-Reply-To: <9acacaa50608310245k65ee5de7j3fd419551beefbc@mail.gmail.com>
References: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>
	<9acacaa50608310056o5c05ec4dn37ea54a64893e8e2@mail.gmail.com>
	<9acacaa50608310245k65ee5de7j3fd419551beefbc@mail.gmail.com>
Message-ID: <9acacaa50608310246n6ed56d8brb5e0aa0400f6af33@mail.gmail.com>

Others on the Kid mailing list seem to be having setuptools problems:

<http://sourceforge.net/mailarchive/forum.php?thread_id=30391159&forum_id=43670>

Is it Kid's installation setup that's awry?

Hamish

From pje at telecommunity.com  Thu Aug 31 17:37:51 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 31 Aug 2006 11:37:51 -0400
Subject: [Distutils] Spurious "required version not available" error for
 setuptools?
In-Reply-To: <9acacaa50608310056o5c05ec4dn37ea54a64893e8e2@mail.gmail.co
 m>
References: <5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20060831113032.0231be28@sparrow.telecommunity.com>

At 08:56 AM 8/31/2006 +0100, Hamish Lawson wrote:
>Phillip J. Eby wrote:
>
>>Would you mind including the entire log of the error, too?  Thanks.
>
>----
>robin-hbl% easy_install svn://kid-templating.org/trunk
>Doing subversion checkout from svn://kid-templating.org/trunk to
>/tmp/easy_install-OW_QLh/trunk
>Processing trunk
>Running setup.py -q bdist_egg --dist-dir
>/tmp/easy_install-OW_QLh/trunk/egg-dist-tmp-UO9-nX
>The required version of setuptools (>=0.6a11) is not available, and
>can't be installed while this script is running. Please install
>a more recent version first.

Ah, the plot thickens.  This error message only occurs if there is a 
version *conflict* error - that is, you have an installed version of 
setuptools on your sys.path that is a lower version than 0.6a11.  This 
could happen if your default installation location is later on sys.path 
than the installation location for an older version of setuptools.

Try this:

% python2.4
 >>> import pkg_resources
 >>> print list(pkg_resources.working_set)

And send me the output.  I'm guessing it will show a version of setuptools 
that's less than 0.6a11, and the path shown with it will be different than 
the one you've been installing later versions of setuptools to.

(Oh, and also check which Python version is being run by your easy_install 
script, to make sure you run the same version to do the above.)


From pje at telecommunity.com  Thu Aug 31 17:46:17 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 31 Aug 2006 11:46:17 -0400
Subject: [Distutils] Spurious "required version not available" error for
 setuptools?
In-Reply-To: <9acacaa50608310246n6ed56d8brb5e0aa0400f6af33@mail.gmail.co
 m>
References: <9acacaa50608310245k65ee5de7j3fd419551beefbc@mail.gmail.com>
	<5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>
	<9acacaa50608310056o5c05ec4dn37ea54a64893e8e2@mail.gmail.com>
	<9acacaa50608310245k65ee5de7j3fd419551beefbc@mail.gmail.com>
Message-ID: <5.1.1.6.0.20060831113756.022e2d88@sparrow.telecommunity.com>

At 10:46 AM 8/31/2006 +0100, Hamish Lawson wrote:
>Others on the Kid mailing list seem to be having setuptools problems:
>
><http://sourceforge.net/mailarchive/forum.php?thread_id=30391159&forum_id=43670>
>
>Is it Kid's installation setup that's awry?

That problem is due to them using a11 after I killed off all the alpha 
releases from the Cheeseshop to keep people from installing versions that 
had some rather serious bugs that were fixed by the beta versions.  This 
doesn't affect your problem; even though they've changed the ez_setup 
you're still going to get an installation conflict error in your 
installation.  The problem you're having is specific to your installation, 
in other words.

On the whole, I think ez_setup is going to have to grow a way to bootstrap 
to the "latest non-alpha version" if there's one out there.  I should 
probably also have it output information about the conflicting setuptools 
installation if there's a conflict, as that would have made your problem 
easier for you to spot up front.



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


From hbl at st-andrews.ac.uk  Thu Aug 31 18:00:17 2006
From: hbl at st-andrews.ac.uk (Hamish Lawson)
Date: Thu, 31 Aug 2006 17:00:17 +0100
Subject: [Distutils] Spurious "required version not available" error for
	setuptools?
In-Reply-To: <5.1.1.6.0.20060831113032.0231be28@sparrow.telecommunity.com>
References: <5.1.1.6.0.20060830145710.022eb870@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830150806.0230e3f0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060830154913.0295fce0@sparrow.telecommunity.com>
	<5.1.1.6.0.20060831113032.0231be28@sparrow.telecommunity.com>
Message-ID: <9acacaa50608310900s16df7954l71a42635549f9c1b@mail.gmail.com>

Phillip J. Eby wrote:

>  >>> print list(pkg_resources.working_set)

[setuptools 0.6c1
(/usr/local/python/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg),
CherryPy 2.1.1 (/usr/local/python/lib/python2.4/site-packages/CherryPy-2.1.1-py2.4.egg),
FormEncode 0.5.1
(/usr/local/python/lib/python2.4/site-packages/FormEncode-0.5.1-py2.4.egg),
Markup 0.2.0 (/usr/local/python/lib/python2.4/site-packages/Markup-0.2.0-py2.4.egg),
PyDO 2.0p1 (/usr/local/python/lib/python2.4/site-packages/PyDO-2.0p1-py2.4.egg),
SQLAlchemy 0.91alpha
(/usr/local/python/lib/python2.4/site-packages/SQLAlchemy-0.91alpha-py2.4.egg),
SQLObject 0.7.1dev-r1457
(/usr/local/python/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg),
TurboGears 0.8.8
(/usr/local/python/lib/python2.4/site-packages/TurboGears-0.8.8-py2.4.egg),
TestGears 0.2 (/usr/local/python/lib/python2.4/site-packages/TestGears-0.2-py2.4.egg),
cElementTree 1.0.2-20050302
(/usr/local/python/lib/python2.4/site-packages/cElementTree-1.0.2_20050302-py2.4-solaris-2.10-sun4u.egg),
elementtree 1.2.6
(/usr/local/python/lib/python2.4/site-packages/elementtree-1.2.6-py2.4.egg),
kid 0.9.3 (/usr/local/python/lib/python2.4/site-packages/kid-0.9.3-py2.4.egg),
simplejson 1.3 (/usr/local/python/lib/python2.4/site-packages/simplejson-1.3-py2.4.egg)]

> (Oh, and also check which Python version is being run by your easy_install
> script, to make sure you run the same version to do the above.)

Ah, I think the problem night be solved. The easy_install being picked
up is in /usr/local/bin:

----
#!/usr/local/bin/python
# EASY-INSTALL-ENTRY-SCRIPT:
'setuptools==0.6a9','console_scripts','easy_install'
__requires__ = 'setuptools==0.6a9'
import sys
from pkg_resources import load_entry_point

sys.exit(
   load_entry_point('setuptools==0.6a9', 'console_scripts', 'easy_install')()
)
----

There's also an easy_install in my Python installation
(/usr/local/python/bin); this one refers to 0.6c1. When I invoke this
absolutely then the installtaion of Kid from Subversion works.

Hamish