From jjl at pobox.com  Tue May  2 12:19:06 2006
From: jjl at pobox.com (John J Lee)
Date: Tue, 2 May 2006 11:19:06 +0100 (GMT Standard Time)
Subject: [Distutils] easy_install -f "<SF URL>"
Message-ID: <Pine.WNT.4.64.0605021114520.3468@shaolin>

Attempting to install pyExcelerator, whose PyPI entry is out of date, I 
tried pointing easy_install at this SF page:

http://sourceforge.net/project/showfiles.php?group_id=134081&package_id=148078


That times out (maybe due to the SF advertising pause?).  Maybe it can be 
worked around?

It worked with this URL:

http://prdownloads.sourceforge.net/pyexcelerator/pyexcelerator-0.6.3a.zip?download


John

From jjl at pobox.com  Tue May  2 12:26:27 2006
From: jjl at pobox.com (John J Lee)
Date: Tue, 2 May 2006 11:26:27 +0100 (GMT Standard Time)
Subject: [Distutils] NameError from setuptools 0.6a11
Message-ID: <Pine.WNT.4.64.0605021121510.3468@shaolin>

The fix to this is obvious: s/url/fn/

...
"c:\python24\lib\site-packages\setuptools-0.6a11-py2.4.egg\setuptools\package_index.py", line 182, in process_filename
     self.warn("Not found: %s", url)
NameError: global name 'url' is not defined


John

From jjl at pobox.com  Tue May  2 12:33:13 2006
From: jjl at pobox.com (John J Lee)
Date: Tue, 2 May 2006 11:33:13 +0100 (GMT Standard Time)
Subject: [Distutils] -U --always-unzip won't replace zipped install
Message-ID: <Pine.WNT.4.64.0605021128340.3468@shaolin>

Subject line nearly sums it up, I guess:  if I easy_install something and 
get a zipped egg installed, then decide I wanted in unzipped:

easy_install -U -f --always-unzip "http://prdownloads.sourceforge.net/pyexcelerator/pyexcelerator-0.6.3a.zip?download" pyExcelerator
...
Best match: pyexcelerator 0.6.3a
Processing pyexcelerator-0.6.3a-py2.4.egg
pyexcelerator 0.6.3a is already the active version in easy-install.pth

Using c:\python24\lib\site-packages\pyexcelerator-0.6.3a-py2.4.egg
Processing dependencies for pyExcelerator


...I end up the zip still there, and no unzipped install.  Would be nice 
if it were to replace it with an unzipped install.

Or is there some other way to ask for that?


John

From ianb at colorstudy.com  Tue May  2 17:23:56 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 02 May 2006 10:23:56 -0500
Subject: [Distutils] [Edu-sig] HTConsole
In-Reply-To: <44571D91.8070706@luc.edu>
References: <44501D3C.50307@colorstudy.com>		<7528bcdd0604261909x7451053ex1e10f7513861a12a@mail.gmail.com>		<44502AF8.2070807@colorstudy.com>	<7528bcdd0604261936w4a6c7ab0m7e929dac4ce04608@mail.gmail.com>
	<445038F9.5080303@colorstudy.com> <44571D91.8070706@luc.edu>
Message-ID: <4457798C.4010809@colorstudy.com>

Andrew Harrington wrote:
> Dear Ian,
> I installed easy_install successfully and then I have this session, 
> ending in an error:
> 
> C:\Python24>easy_install htconsole
> Searching for htconsole
> Best match: htconsole 0.2
> Processing htconsole-0.2-py2.4.egg
> htconsole 0.2 is already the active version in easy-install.pth
> Installing htconsole-script.py script to C:\Python24\Scripts
> Installing htconsole.exe script to C:\Python24\Scripts
> 
> Using c:\python24\lib\site-packages\htconsole-0.2-py2.4.egg
> Processing dependencies for htconsole
> Searching for Cheetah>=2a
> Best match: Cheetah 2.0rc6
> Downloading 
> http://69.9.164.2/sourceforge/cheetahtemplate/Cheetah-2.0rc6.tar.gz
> error: Download error: (10061, 'Connection refused')

I've gotten this from time to time as well.  Something with how 
easy_install downloads from SF -- I think it retries when it gets some 
kinds of failures, but not all, and SF mirrors fail a lot.

If you try it once or twice more it'll probably work, or you can download
http://sourceforge.net/project/showfiles.php?group_id=28961&package_id=20864&release_id=391008

And then run "easy_install FileYouJustDownloaded.tar.gz"

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

From pje at telecommunity.com  Tue May  2 17:35:45 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 02 May 2006 11:35:45 -0400
Subject: [Distutils] easy_install -f "<SF URL>"
In-Reply-To: <Pine.WNT.4.64.0605021114520.3468@shaolin>
Message-ID: <5.1.1.6.0.20060502113450.01e79b20@mail.telecommunity.com>

At 11:19 AM 5/2/2006 +0100, John J Lee wrote:
>Attempting to install pyExcelerator, whose PyPI entry is out of date, I
>tried pointing easy_install at this SF page:
>
>http://sourceforge.net/project/showfiles.php?group_id=134081&package_id=148078

It worked fine for me.


>That times out (maybe due to the SF advertising pause?).  Maybe it can be
>worked around?

Not really; the SVN versions of easy_install do automatically retry failed 
downloads, however.  As Ian says, SF mirrors fail a *lot*.


From pje at telecommunity.com  Tue May  2 17:36:37 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 02 May 2006 11:36:37 -0400
Subject: [Distutils] NameError from setuptools 0.6a11
In-Reply-To: <Pine.WNT.4.64.0605021121510.3468@shaolin>
Message-ID: <5.1.1.6.0.20060502113625.038fb878@mail.telecommunity.com>

At 11:26 AM 5/2/2006 +0100, John J Lee wrote:
>The fix to this is obvious: s/url/fn/
>
>...
>"c:\python24\lib\site-packages\setuptools-0.6a11-py2.4.egg\setuptools\package_index.py", 
>line 182, in process_filename
>      self.warn("Not found: %s", url)
>NameError: global name 'url' is not defined

Already fixed in SVN, but thanks for the report.


From pje at telecommunity.com  Tue May  2 17:39:51 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 02 May 2006 11:39:51 -0400
Subject: [Distutils] -U --always-unzip won't replace zipped install
In-Reply-To: <Pine.WNT.4.64.0605021128340.3468@shaolin>
Message-ID: <5.1.1.6.0.20060502113643.01e8a940@mail.telecommunity.com>

At 11:33 AM 5/2/2006 +0100, John J Lee wrote:
>Subject line nearly sums it up, I guess:  if I easy_install something and
>get a zipped egg installed, then decide I wanted in unzipped:
>
>easy_install -U -f --always-unzip 
>"http://prdownloads.sourceforge.net/pyexcelerator/pyexcelerator-0.6.3a.zip?download" 
>pyExcelerator
>...
>Best match: pyexcelerator 0.6.3a
>Processing pyexcelerator-0.6.3a-py2.4.egg
>pyexcelerator 0.6.3a is already the active version in easy-install.pth
>
>Using c:\python24\lib\site-packages\pyexcelerator-0.6.3a-py2.4.egg
>Processing dependencies for pyExcelerator
>
>
>...I end up the zip still there, and no unzipped install.  Would be nice
>if it were to replace it with an unzipped install.
>
>Or is there some other way to ask for that?

At the moment, there is no well-defined rule for which package easy_install 
will choose to use when you already have the "latest" version installed.  I 
do intend to remedy this soon, but in the meantime, removing the existing 
egg or specifying a precise URL or filename to install ("easy_install -U 
/path/or/url/to/some.egg") will do the trick.  (i.e., the ambiguity only 
occurs when you're asking for it to figure out what version to install.)


From john.pye at student.unsw.edu.au  Wed May  3 04:16:11 2006
From: john.pye at student.unsw.edu.au (John Pye)
Date: Wed, 03 May 2006 12:16:11 +1000
Subject: [Distutils] bundling a pre-built DLL/SO
Message-ID: <4458126B.8010209@student.unsw.edu.au>

Hi all,

Is there a way I can use distutils to package up a binary distribution
of a SWIG module that has already been created with another build tool?

In particular, I have a .dll/.so file and a .py file, and they just need
to be dropped in the right place, and I want to use the distutils
'bdist_rpm' / exe builder to then create a distributable.

Cheers
JP

-- 
John Pye
School of Mechanical and Manufacturing Engineering
The University of New South Wales
Sydney  NSW 2052  Australia
t +61 2 9385 5127
f +61 2 9663 1222
mailto:john.pye_AT_student_DOT_unsw.edu.au
http://pye.dyndns.org/


From pje at telecommunity.com  Wed May  3 17:05:38 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 03 May 2006 11:05:38 -0400
Subject: [Distutils] bundling a pre-built DLL/SO
In-Reply-To: <4458126B.8010209@student.unsw.edu.au>
Message-ID: <5.1.1.6.0.20060503110332.0377fd18@mail.telecommunity.com>

At 12:16 PM 5/3/2006 +1000, John Pye wrote:
>Hi all,
>
>Is there a way I can use distutils to package up a binary distribution
>of a SWIG module that has already been created with another build tool?
>
>In particular, I have a .dll/.so file and a .py file, and they just need
>to be dropped in the right place, and I want to use the distutils
>'bdist_rpm' / exe builder to then create a distributable.

If the binary module is inside a package, you can treat it as package data.

Alternately, you could try subclassing 
distutils.command.build_ext.build_ext so that it runs your other build 
tool, and adding that to your custom commands dictionary in setup().


From john.pye at student.unsw.edu.au  Wed May  3 18:58:11 2006
From: john.pye at student.unsw.edu.au (John Pye)
Date: Thu, 04 May 2006 02:58:11 +1000
Subject: [Distutils] bundling a pre-built DLL/SO
In-Reply-To: <5.1.1.6.0.20060503110332.0377fd18@mail.telecommunity.com>
References: <5.1.1.6.0.20060503110332.0377fd18@mail.telecommunity.com>
Message-ID: <4458E123.9010500@student.unsw.edu.au>

Hi Philip,

Phillip J. Eby wrote:

> At 12:16 PM 5/3/2006 +1000, John Pye wrote:
>
>> Is there a way I can use distutils to package up a binary distribution
>> of a SWIG module that has already been created with another build tool?
>>
>> In particular, I have a .dll/.so file and a .py file, and they just need
>> to be dropped in the right place, and I want to use the distutils
>> 'bdist_rpm' / exe builder to then create a distributable.
>
>
> If the binary module is inside a package, you can treat it as package
> data.

I'm concerned that if I treat it as package data, it won't get put in
the right place in all cases.

>
> Alternately, you could try subclassing
> distutils.command.build_ext.build_ext so that it runs your other build
> tool, and adding that to your custom commands dictionary in setup().

That's an interesting idea -- have you heard of anyone doing this with
SCons?

Cheers
JP

From pje at telecommunity.com  Wed May  3 19:15:17 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 03 May 2006 13:15:17 -0400
Subject: [Distutils] bundling a pre-built DLL/SO
In-Reply-To: <4458E123.9010500@student.unsw.edu.au>
References: <5.1.1.6.0.20060503110332.0377fd18@mail.telecommunity.com>
	<5.1.1.6.0.20060503110332.0377fd18@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060503131331.01e3cae8@mail.telecommunity.com>

At 02:58 AM 5/4/2006 +1000, John Pye wrote:
>Hi Philip,
>
>Phillip J. Eby wrote:
>
> > At 12:16 PM 5/3/2006 +1000, John Pye wrote:
> >
> >> Is there a way I can use distutils to package up a binary distribution
> >> of a SWIG module that has already been created with another build tool?
> >>
> >> In particular, I have a .dll/.so file and a .py file, and they just need
> >> to be dropped in the right place, and I want to use the distutils
> >> 'bdist_rpm' / exe builder to then create a distributable.
> >
> >
> > If the binary module is inside a package, you can treat it as package
> > data.
>
>I'm concerned that if I treat it as package data, it won't get put in
>the right place in all cases.

If you treat it as *package* data, it will be in the right place.  See:

http://python.org/doc/2.4.1/dist/node11.html


> > Alternately, you could try subclassing
> > distutils.command.build_ext.build_ext so that it runs your other build
> > tool, and adding that to your custom commands dictionary in setup().
>
>That's an interesting idea -- have you heard of anyone doing this with
>SCons?

No.  See:

http://python.org/doc/2.4.1/dist/node29.html

for instructions on how to integrate your custom commands.


From eugeneoden at gmail.com  Thu May  4 04:41:49 2006
From: eugeneoden at gmail.com (Eugene Oden)
Date: Wed, 3 May 2006 21:41:49 -0500
Subject: [Distutils] patch for building binary eggs on hp-ux 11.00
Message-ID: <200605032141.49959.eugeneoden@gmail.com>

i have a patch to submit to fix two issues i encountered when building binary 
eggs for hp-ux 11.00.  the model number of the hardware, as reported by 
uname -m, is '9000/800' which causes problems when this is part of a 
filename.  the two other changes i have are to add the shared library 
extension of '.sl' and to add executable permissions for shared libraries 
when eggs are unpacked, a requirement of hp-ux.

where should i send this patch for consideration?

thanks,

gene oden

From FETCHMAIL-DAEMON at ns3565.ovh.net  Thu May  4 13:48:44 2006
From: FETCHMAIL-DAEMON at ns3565.ovh.net (FETCHMAIL-DAEMON at ns3565.ovh.net)
Date: Thu,  4 May 2006 13:48:44 +0200 (CEST)
Subject: [Distutils] (no subject)
Message-ID: <20060504114844.C88381E4007@bag.python.org>

This message was too large (SMTP error 552).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 487 bytes
Desc: not available
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20060504/d78857bc/attachment.bin 

From pje at telecommunity.com  Thu May  4 19:18:42 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 04 May 2006 13:18:42 -0400
Subject: [Distutils] patch for building binary eggs on hp-ux 11.00
In-Reply-To: <200605032141.49959.eugeneoden@gmail.com>
Message-ID: <5.1.1.6.0.20060504131753.03a95030@mail.telecommunity.com>

At 09:41 PM 5/3/2006 -0500, Eugene Oden wrote:
>i have a patch to submit to fix two issues i encountered when building binary
>eggs for hp-ux 11.00.  the model number of the hardware, as reported by
>uname -m, is '9000/800' which causes problems when this is part of a
>filename.  the two other changes i have are to add the shared library
>extension of '.sl' and to add executable permissions for shared libraries
>when eggs are unpacked, a requirement of hp-ux.
>
>where should i send this patch for consideration?

To me directly, or to the list here.


From pje at telecommunity.com  Mon May  8 06:02:28 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 08 May 2006 00:02:28 -0400
Subject: [Distutils] PythonEggs: What do you think about an
 is_required_by() method?
In-Reply-To: <200605050310.08021.jgodoy@gmail.com>
References: <200605050255.38677.jgodoy@gmail.com>
	<200605050255.38677.jgodoy@gmail.com>
Message-ID: <5.1.1.6.0.20060507232628.03807e30@home.unrestrained.com>

At 03:10 AM 5/5/2006 -0300, Jorge Godoy wrote:
>Em Sexta 05 Maio 2006 02:55, Jorge Godoy escreveu:
> > Hi Phillip,
> >
> >
> > I was talking to Kevin Dangoor a while ago about implementing some
> > extension to Turbogears' "tg-admin info" where it listed not only what
> > Turbogears required to work, but also what requires Turbogears.
> >
> > Currently pkg_resources provides a "require()" method --
> > http://peak.telecommunity.com/DevCenter/PythonEggs#automatic-discovery --
> > and I'd like to know what do you think about implementing a dual operation
> > for this and providing an is_required_by() method?
> >
> > The idea is to provide the package name and list all eggs that requires
> > this package.
>
>I believe I got the correct syntax for this.  What do you think?  (I'm not
>using the same abstraction as you do in your code, this is just a sample
>implementation)
>
>
> >>> def is_required_by(package):
>...     for item in pkg_resources.AvailableDistributions():
>...         for required in pkg_resources.require(item):
>...             if str(required).startswith(package): print item

A few pointers:

1. 'AvailableDistributions' is deprecated and will disappear in 0.7; please 
use 'Environment' instead.

2. You're going to get false positive hits if 'package' is something like 
'turbo' -- use 'if required.key==safe_name(package).lower()' instead.  (Or 
better yet, do 'package = safe_name(package).lower()' at the start of the 
routine, outside the loops.)

3. As written, your code may scan sys.path directories multiple times, and 
thus be slow.  Rather than using 'require()', I suggest using the 
'resolve()' method of a working set, and passing in the environment you 
started with.

4. As written, your routine is not at all specific about which packages are 
required by which versions of things, and in fact it will show only the 
dependencies for versions that are currently active on sys.path.  As a 
result, it's also subject to throwing version conflict errors.

I strongly suggest that you define which versions of which packages you 
mean for this to operate on.  As written, it displays dependencies for the 
version on sys.path, or the most recent version if none is defined.  And it 
has side effects, since it will add things to sys.path as it runs.  This 
isn't a good idea.

What you should do is get a collection of Distribution instances that 
reflect the set of eggs that you want to verify dependencies for.  You 
should then ask each instance for its requirements, e.g.:

     def depends_on(dist, req):
         if not isinstance(req, Requirement):
             req = Requirement.parse(req)
         for r in dist.requires():
             if r.key == req.key:
                 return True
         else:
             return False

You can now do something like '[dist for dist in eggs if 
depends_on(dist,"foo")]'.

No, it's not recursive, but its behavior is well-defined, it doesn't do 
repeated disk scans each time you make a pass over the set, and it doesn't 
alter the contents of sys.path in any way.  If you want it to be recursive, 
you would do something like:

     def find_dependers(req, distributions, memo=None):
         if memo is None:
             memo = {}
         for dist in distributions:
             if dist in memo:
                 continue
             memo[dist] = 1
             if depends_on(dist, req):
                 yield dist
                 for dist in find_dependers(dist.as_requirement(), 
distributions, memo):
                     yield dist

This should yield the distributions from the input list that require 'req'.

So your only remaining problem would be to specify what distributions 
should be given as the input list.  You may wish to simply flatten an 
Environment, which would list all the installed eggs that depend on another 
egg, whether they are active on sys.path at present or not.  e.g.:

    env = Environment()
    list(find_dependers('foo', [d for k in env for d in env[k]]))

You could also just use working_set as the list of 'distributions', in 
which case only the distributions active on sys.path would be tested for 
dependencies.

None of the above code is tested, but should put you on the right 
track.  Please also consult the API documentation at:

     http://peak.telecommunity.com/DevCenter/PkgResources

to find out more about using the APIs I used above.


From cwmoad at gmail.com  Tue May  9 00:46:43 2006
From: cwmoad at gmail.com (Charlie Moad)
Date: Mon, 8 May 2006 18:46:43 -0400
Subject: [Distutils] easy_install finding wrong platform
Message-ID: <6382066a0605081546yea05e6bse542b3c0c77f0247@mail.gmail.com>

For matplotlib I have pypi's download url set to
"http://sourceforge.net/project/showfiles.php?group_id=80706&amp;package_id=82474".
 All the files are over the 5MB limit in case anyone asks.  When I run
"easy_install -U matplotlib" on windows 2.4 it is downloading the
"matplotlib-0.87.2-py2.4-macosx10.4.mpkg.zip" file instead of
"matplotlib-0.87.2-py2.4-win32.egg".  Obviously wrong.

Thanks,
     Charlie

From pje at telecommunity.com  Tue May  9 01:01:55 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 08 May 2006 19:01:55 -0400
Subject: [Distutils] easy_install finding wrong platform
In-Reply-To: <6382066a0605081546yea05e6bse542b3c0c77f0247@mail.gmail.com
 >
Message-ID: <5.1.1.6.0.20060508185800.01e7ce30@mail.telecommunity.com>

At 06:46 PM 5/8/2006 -0400, Charlie Moad wrote:
>For matplotlib I have pypi's download url set to
>"http://sourceforge.net/project/showfiles.php?group_id=80706&amp;package_id=82474".
>  All the files are over the 5MB limit in case anyone asks.  When I run
>"easy_install -U matplotlib" on windows 2.4 it is downloading the
>"matplotlib-0.87.2-py2.4-macosx10.4.mpkg.zip" file instead of
>"matplotlib-0.87.2-py2.4-win32.egg".  Obviously wrong.

Hi Charlie; this is a known issue that is fixed in the SVN trunk and 0.6 
branch of setuptools; released versions of easy_install are confused by 
"bdist_dumb" distributions of this sort, as they think the .zip file is of 
a project called "matplotlib" with a version of 
"0.87.2-py2.4-macosx10.4.mpkg", and since this is a higher version than 
"0.87.2" easy_install considers it a better match.  I hope to release 0.6b1 
shortly, which will fix this problem in the released version.

In the meantime, you can "easy_install matplotlib==0.87.2" to work around 
the problem, or "easy_install setuptools==dev06" to upgrade to the SVN 
version of the 0.6 branch (soon to be released as 0.6b1).


From ianb at colorstudy.com  Tue May  9 20:56:30 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 09 May 2006 13:56:30 -0500
Subject: [Distutils] easy_install: #egg taking priority
Message-ID: <4460E5DE.9060102@colorstudy.com>

So, first the setup.  We wanted to require PIL for a package.  PIL goes 
by the name "PIL" and "Imaging".  Specifically, the file you download is 
named "Imaging", and the actual package installed is named "PIL".  You 
can install Imaging (as long as you use easy_install -f 
http://effbot.org/downloads/) , but it doesn't work as a requirement 
because Imaging itself does not fulfill an Imaging requirement.

So, I figured we'd put in a link like this in someplace listed in -f (we 
have a local set of links we maintain): 
http://effbot.org/downloads/Imaging-1.1.5.tar.gz#egg=PIL-1.1.5

But, this doesn't work.  easy_install pays attention to 
"Imaging-1.1.5.tar.gz" and ignores the "#egg=..." portion.  This seems 
wrong, since the only reason for #egg to be there is to help 
easy_install, so it should take priority (or both names could be read, 
as long as the #egg info isn't thrown away).

We worked around this by creating a shortened link with rubyurl.com 
(irony!  tinyurl.com apparently doesn't allow non-browser user agents, 
and rubyurl was the next thing I could think of), and adding the #egg to 
that.  A little silly and indirect, but a workaround for now.

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

From mike.bernson at gmail.com  Tue May  9 22:11:57 2006
From: mike.bernson at gmail.com (Mike Bernson)
Date: Tue, 9 May 2006 16:11:57 -0400
Subject: [Distutils] Getting eggs from with user, password
Message-ID: <d7b489ac0605091311n55d033b1x7caf3114477a8d34@mail.gmail.com>

I want to use eggs for a non-open source project.

What I would like to do is create a page that has all the eggs for the
project but
is password. I would then like easy_install to be able to access this page.
I see an
option for adding a url to look at for find eggs. What I am missing is a way
to
supply this user and password for download.

Am I missing something here or is not possible to have password to protect
the
page where some eggs exist ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20060509/eb42e9c5/attachment.html 

From ianb at colorstudy.com  Fri May 12 22:37:43 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 12 May 2006 15:37:43 -0500
Subject: [Distutils] setuptools: hardcoding the path in a script and site.py
Message-ID: <4464F217.7040904@colorstudy.com>

So, there's really two monkeypatches to setuptools that workenv does to 
setuptools, and I'd like to get rid of them; they cause a lot of 
trouble, in part because setuptools is making it difficult to 
monkeypatch with the recent change to easy-install.pth (at least, I 
think it's a recent change) -- but if I don't need to monkeypatch 
setuptools then this won't be a problem, and I don't really need to be 
compatible with old versions of setuptools because workingenv can (maybe 
always should) install its own version of setuptools.


The first is hardcoding paths in scripts.  This is the monkeypatch:

def get_script_header(script_text, executable=easy_install.sys_executable):
     from distutils.command.build_scripts import first_line_re
     first, rest = (script_text+'\\n').split('\\n',1)
     match = first_line_re.match(first)
     options = ''
     if match:
         script_text = rest
         options = match.group(1) or ''
         if options:
             options = ' '+options
     if options.find('-S') == -1:
         options += ' -S'
     shbang = \"#!%(executable)s%(options)s\\n\" % locals()
     shbang += ("import sys, os\\n"
                "join, dirname = os.path.join, os.path.dirname\\n"
                "lib_dir = join(dirname(dirname(__file__)), 'lib', 
'python%s.%s' % tuple(sys.version_info[:2]))\\n"
                "sys.path.insert(0, lib_dir)\\n"
                "import site\\n")
     return shbang

easy_install.get_script_header = get_script_header


Basically we're creating:

#!/usr/bin/python -S
import sys, os
join, dirname = os.p;ath.join, os.path.dirname
lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % 
tuple(sys.version_info[:2]))
sys.path.insert(0, lib_dir)
import site
# the rest...


I'm thinking this could be done with an installation option (that I can 
put in distutils.cfg), like:

   script_path_override = lib/python2.4

I'd prefer this path be interpreted relative to the location the script 
is installed (os.path.join(os.path.dirname(__file__), override)), but 
that doesn't fit with the typical way distutils interprets things.  Two 
options?  script_path_override, script_path_relative_override?

This is also a feature Jim has requested for Zope.


The other monkeypatch I'm doing is to keep setuptools from demanding to 
own site.py.  The monkeypatch is:

   def install_site_py(self):
       # to heck with this, we gots our own site.py and we'd like
       # to keep it, thank you
       pass
   easy_install.easy_install.install_site_py = install_site_py

But what would be better is if setuptools installed code somewhere 
besides site.py.  For instance, site-setuptools.py.  Then if site.py 
didn't exist, it would be created like:

   import os
   # add site-setuptools
   execfile(os.path.join(os.path.dirname(__file__), 'site-setuptools.py')

If the file did exist, setuptools would check for the text "add 
site-setuptools", and give a warning or error if it was not, or maybe 
would just prefix the site.py with this text, and leave the rest of it 
as is.  Then I'd include that code in workingenv's site.py.


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

From pje at telecommunity.com  Fri May 12 23:58:52 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 12 May 2006 17:58:52 -0400
Subject: [Distutils] Getting eggs from with user, password
In-Reply-To: <d7b489ac0605091311n55d033b1x7caf3114477a8d34@mail.gmail.co
 m>
Message-ID: <5.1.1.6.0.20060512175554.01ff7010@mail.telecommunity.com>

At 04:11 PM 5/9/2006 -0400, Mike Bernson wrote:
>I want to use eggs for a non-open source project.
>
>What I would like to do is create a page that has all the eggs for the 
>project but
>is password. I would then like easy_install to be able to access this 
>page. I see an
>option for adding a url to look at for find eggs. What I am missing is a 
>way to
>supply this user and password for download.
>
>Am I missing something here or is not possible to have password to protect the
>page where some eggs exist ?

If you want to implement this in an upgrade tool of your own, you can 
subclass PackageIndex (in setuptools.package_index) and then use that as 
the package index for an easy_install command instance.  You would need to 
have the download code check for a 401 and prompt the user to enter their 
ID and password.

If you send me working code, I'll see if I can incorporate a similar 
feature back into the standard easy_install release, but I'd like to do it 
in such a way that easy_install remains non-interactive by default.


From pje at telecommunity.com  Sat May 13 00:11:52 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 12 May 2006 18:11:52 -0400
Subject: [Distutils] easy_install: #egg taking priority
In-Reply-To: <4460E5DE.9060102@colorstudy.com>
Message-ID: <5.1.1.6.0.20060512180056.0332b008@mail.telecommunity.com>

At 01:56 PM 5/9/2006 -0500, Ian Bicking wrote:
>So, first the setup.  We wanted to require PIL for a package.  PIL goes
>by the name "PIL" and "Imaging".  Specifically, the file you download is
>named "Imaging", and the actual package installed is named "PIL".  You
>can install Imaging (as long as you use easy_install -f
>http://effbot.org/downloads/) , but it doesn't work as a requirement
>because Imaging itself does not fulfill an Imaging requirement.

Which means the source distribution isn't being produced by the distutils, 
or at any rate is being renamed for distribution.  My suggestion would be 
to redistribute a copy of the package with the correct filename, or ask the 
upstream author to do so.


>So, I figured we'd put in a link like this in someplace listed in -f (we
>have a local set of links we maintain):
>http://effbot.org/downloads/Imaging-1.1.5.tar.gz#egg=PIL-1.1.5
>
>But, this doesn't work.

That's because #egg was added to support SVN source checkouts and 
standalone .py files only.  It's not designed to work on distutils 
distributions.  In particular, using #egg lowers the link precedence so 
that the link is treated as least-preferable unless you're asking for a 
source distribution.  In other words, if there's a non #egg link that meets 
your criteria, easy_install will prefer it to an #egg link.

In short: don't use #egg for this; it's only for non-distutils formats, 
like Subversion checkouts and standalone .py files.


>   easy_install pays attention to
>"Imaging-1.1.5.tar.gz" and ignores the "#egg=..." portion.  This seems
>wrong, since the only reason for #egg to be there is to help
>easy_install, so it should take priority (or both names could be read,
>as long as the #egg info isn't thrown away).

I guess I could add this, but it doesn't make PIL's distribution name any 
less wrong.  Unless the filename is changed, *everybody* will have to use 
#egg links to work around it.  ISTM that this is a case where asking the 
author to distribute it under the matching package name (or to change its 
setup() name to "Imaging") would be the best solution.

But I'll go ahead and add this feature under the theory that it's better to 
always have the ability to tag something explicitly.


From pje at telecommunity.com  Sat May 13 00:54:25 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 12 May 2006 18:54:25 -0400
Subject: [Distutils] Setuptools 0.6b1 released
Message-ID: <5.1.1.6.0.20060512185227.031d5008@mail.telecommunity.com>

There are no new major features in this release, but many bug fixes and a 
few minor enhancements.  From here on out, the 0.6 line is for bug fixes 
only; any new features will have to go into the 0.7 alpha trunk.


From ianb at colorstudy.com  Sat May 13 04:55:40 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 12 May 2006 21:55:40 -0500
Subject: [Distutils] Getting eggs from with user, password
In-Reply-To: <d7b489ac0605091311n55d033b1x7caf3114477a8d34@mail.gmail.com>
References: <d7b489ac0605091311n55d033b1x7caf3114477a8d34@mail.gmail.com>
Message-ID: <44654AAC.6070306@colorstudy.com>

Mike Bernson wrote:
> I want to use eggs for a non-open source project.
> 
> What I would like to do is create a page that has all the eggs for the 
> project but
> is password. I would then like easy_install to be able to access this 
> page. I see an
> option for adding a url to look at for find eggs. What I am missing is a 
> way to
> supply this user and password for download.

Does http://user:password at host/path work?  If not, then perhaps it should.

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

From jjl at pobox.com  Sat May 13 14:19:12 2006
From: jjl at pobox.com (John J Lee)
Date: Sat, 13 May 2006 12:19:12 +0000 (UTC)
Subject: [Distutils] Getting eggs from with user, password
In-Reply-To: <44654AAC.6070306@colorstudy.com>
References: <d7b489ac0605091311n55d033b1x7caf3114477a8d34@mail.gmail.com>
	<44654AAC.6070306@colorstudy.com>
Message-ID: <Pine.LNX.4.64.0605131152090.8456@localhost>

On Fri, 12 May 2006, Ian Bicking wrote:

> Mike Bernson wrote:
>> I want to use eggs for a non-open source project.
>>
>> What I would like to do is create a page that has all the eggs for the
>> project but
>> is password. I would then like easy_install to be able to access this
>> page. I see an
>> option for adding a url to look at for find eggs. What I am missing is a
>> way to
>> supply this user and password for download.
>
> Does http://user:password at host/path work?  If not, then perhaps it should.

urllib2 (which easy_install uses, at least last time I looked) doesn't 
support this syntax ATM (except for proxy auth), and it seems a shame to 
do anything to prolong its existence.  Of course the reason for 
deprecating this (e.g. by RFC 3986) is that it has been used for spoofing. 
The RFCs never allowed it in http URLs, BTW.

Perhaps ask interactively only if a --prompt-for-passwords option is 
passed?  I suppose --user and --password options would be wrong, because 
easy_install wouldn't know which server to send the username and password 
to.


John


From hollisb at us.ibm.com  Tue May 16 00:02:46 2006
From: hollisb at us.ibm.com (Hollis Blanchard)
Date: Mon, 15 May 2006 17:02:46 -0500
Subject: [Distutils] cross-compiling with distutils?
Message-ID: <1147730566.1179.50.camel@basalt.austin.ibm.com>

Hi, I have a python module that uses distutils. I'm trying to build it
on an x86 system for a PPC host. Through much digging, I've found that I
can override CC to use my cross-compiler, but somehow it still wants to
use CFLAGS like -march=i386. Also, the output directory is still
"build/temp.linux-i686-2.4".

I have seen a fair amount of python cross-compiling pain on the net, but
few answers. Any help?

Thanks!

-- 
Hollis Blanchard
IBM Linux Technology Center


From jim at zope.com  Wed May 17 17:50:13 2006
From: jim at zope.com (Jim Fulton)
Date: Wed, 17 May 2006 11:50:13 -0400
Subject: [Distutils] Script-specific .pth files (or baking paths into
	scripts)
Message-ID: <446B4635.2030602@zope.com>


I seem to remember a threat from from Phillip to make a proposal
for installing script-specific ,pth files with scripts, but I don't
think I every saw anything.  Have I missed anything?  If so, what? :)
If not, I'll probably write something myself and share it.

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 ianb at colorstudy.com  Wed May 17 18:34:18 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 17 May 2006 11:34:18 -0500
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B4635.2030602@zope.com>
References: <446B4635.2030602@zope.com>
Message-ID: <446B508A.6090405@colorstudy.com>

Jim Fulton wrote:
> I seem to remember a threat from from Phillip to make a proposal
> for installing script-specific ,pth files with scripts, but I don't
> think I every saw anything.  Have I missed anything?  If so, what? :)
> If not, I'll probably write something myself and share it.

workingenv (http://svn.colorstudy.com/home/ianb/workingenv) doesn't use 
.pth files, but does put in script-specific paths.

As I note in my previous email ("setuptools: hardcoding the path in a 
script and site.py"), I think this would probably be cleanest to do 
through a new installation option, that could also be placed into 
distutils.cfg.  Right now what workingenv does is very specific to 
workingenv, and doesn't work off any public setuptools API.

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

From pje at telecommunity.com  Wed May 17 19:00:16 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 17 May 2006 13:00:16 -0400
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B4635.2030602@zope.com>
Message-ID: <5.1.1.6.0.20060517125616.0300e160@mail.telecommunity.com>

At 11:50 AM 5/17/2006 -0400, Jim Fulton wrote:

>I seem to remember a threat from from Phillip to make a proposal
>for installing script-specific ,pth files with scripts, but I don't
>think I every saw anything.

I haven't done it yet, mainly because I haven't decided how it should work, 
exactly.  Mostly I'm concerned that it seems to need a bunch of options in 
order to support all the use cases that have been requested.

For example, you've asked mainly that all the requirements be pre-baked, 
and Ian has asked also that nothing "leak into" the current environment 
that isn't  pre-baked.  (Which is also a reasonable requirement for 
high-security scripts.)

It also seems like some of these options should be controllable by the 
script author to some extent.  I just haven't come up with a good design 
for what the options should be.  Mostly the issue is that the 
script-writing code is already too complicated for my taste, and this is 
going to make it worse, and I haven't had any brilliant ideas yet on how to 
fix that.  :)


From jim at zope.com  Wed May 17 19:45:24 2006
From: jim at zope.com (Jim Fulton)
Date: Wed, 17 May 2006 13:45:24 -0400
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B508A.6090405@colorstudy.com>
References: <446B4635.2030602@zope.com> <446B508A.6090405@colorstudy.com>
Message-ID: <446B6134.7070203@zope.com>

Ian Bicking wrote:
> Jim Fulton wrote:
> 
>> I seem to remember a threat from from Phillip to make a proposal
>> for installing script-specific ,pth files with scripts, but I don't
>> think I every saw anything.  Have I missed anything?  If so, what? :)
>> If not, I'll probably write something myself and share it.
> 
> 
> workingenv (http://svn.colorstudy.com/home/ianb/workingenv) doesn't use 
> .pth files, but does put in script-specific paths.

As I understand it, it is really putting in environment-specific paths.
I think I want script-specific paths.

> As I note in my previous email ("setuptools: hardcoding the path in a 
> script and site.py"), I think this would probably be cleanest to do 
> through a new installation option, that could also be placed into 
> distutils.cfg.  Right now what workingenv does is very specific to 
> workingenv, and doesn't work off any public setuptools API.

I have an intuition that we're thinking about this incorrectly.
We seem to be going through a lot of effort to fake out something,
athough I'm not sure what.  I have a growing suspiction that
the traditional model of a large namespace of modules
that is used by many applications serves simple scripting very well
but doessn't work well for applications.

I think this is an area where more prototyping is warrented, at
least for my needs.  I'll let y'all know what, if anything I come up
with.

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 ianb at colorstudy.com  Wed May 17 19:55:22 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 17 May 2006 12:55:22 -0500
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <5.1.1.6.0.20060517125616.0300e160@mail.telecommunity.com>
References: <5.1.1.6.0.20060517125616.0300e160@mail.telecommunity.com>
Message-ID: <446B638A.4090205@colorstudy.com>

Phillip J. Eby wrote:
> At 11:50 AM 5/17/2006 -0400, Jim Fulton wrote:
>>I seem to remember a threat from from Phillip to make a proposal
>>for installing script-specific ,pth files with scripts, but I don't
>>think I every saw anything.
> 
> 
> I haven't done it yet, mainly because I haven't decided how it should work, 
> exactly.  Mostly I'm concerned that it seems to need a bunch of options in 
> order to support all the use cases that have been requested.
> 
> For example, you've asked mainly that all the requirements be pre-baked, 
> and Ian has asked also that nothing "leak into" the current environment 
> that isn't  pre-baked.  (Which is also a reasonable requirement for 
> high-security scripts.)

It's also a reasonable requirement for scripts you don't want breaking 
randomly.  These continue to be my bane.

What are the use cases?  My use cases can be done by inserting something 
into the beginning of the path before site is imported.  The "something" 
can be absolute or a script-relative path.  Except for the 
script-relative part, it's equivalent to setting PYTHONPATH.  If you 
don't have a custom site.py, then it's equivalent to just appending it 
to the path after site.py is imported.

If this is done through an installation option, then this covers me 
(where I have a distutils.cfg controlling this).  It can cover script 
customization (with setup.cfg), maybe that can be improved by doing some 
variable interpolation as well.  What variable interpolation I don't 
know, as I'm unsure what the actual use case is.  I can imagine a use 
case where a script represents a complete application, and wants 
specific control of all its libraries.  But I'm not sure how that fits 
in with eggs -- more the basket idea where you get a bundle of things, 
and you install the bundle and include it (and only it?) on the path.

I'm all for that too, but there's more to it than just the path issue. 
I see the working environment idea as complementary -- the working 
environment is what you develop in, and more attention is placed on 
making tools like easy_install work in that environment.  But if you 
want to package it up, you get something more like a basket.  So I can 
imagine implementing it the same way as the working environment -- you 
add a specific path before importing site.py, and the environment/basket 
gets to take over there.

So... I guess custom site.py's seem to give script authors a great deal 
of flexibility.  Except that isn't really a per-script kind of control, 
it's more per-basket.



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

From jim at zope.com  Wed May 17 20:23:25 2006
From: jim at zope.com (Jim Fulton)
Date: Wed, 17 May 2006 14:23:25 -0400
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B638A.4090205@colorstudy.com>
References: <5.1.1.6.0.20060517125616.0300e160@mail.telecommunity.com>
	<446B638A.4090205@colorstudy.com>
Message-ID: <446B6A1D.8020903@zope.com>

Ian Bicking wrote:
> Phillip J. Eby wrote:
> 
>> At 11:50 AM 5/17/2006 -0400, Jim Fulton wrote:
>>
>>> I seem to remember a threat from from Phillip to make a proposal
>>> for installing script-specific ,pth files with scripts, but I don't
>>> think I every saw anything.
>>
>>
>>
>> I haven't done it yet, mainly because I haven't decided how it should 
>> work, exactly.  Mostly I'm concerned that it seems to need a bunch of 
>> options in order to support all the use cases that have been requested.
>>
>> For example, you've asked mainly that all the requirements be 
>> pre-baked, and Ian has asked also that nothing "leak into" the current 
>> environment that isn't  pre-baked.  (Which is also a reasonable 
>> requirement for high-security scripts.)

I actually don't know what this means. :)

> 
> It's also a reasonable requirement for scripts you don't want breaking 
> randomly.  These continue to be my bane.
> 
> What are the use cases? 

I want to be able to install multiple programs ("scripts"), each with their
own dependencies.  Note that different programs might depend on
different versions of the same package.

I want to be able to update a package for one program without
implicitly affecting the others.  (This is a restatement of your
desire not to get implicit updates)

I want everything to be installed in a self-contained project,
ala your working environment.  I don't want to touch a Python install.

I to be able to use a simple install script, like easy_install.

I don't want to have to set environment variables or provide funny
options when I run programs.  I'd like to minimize this when installing things.

I want the system to be simple and understandable.  I'm willing to sacrifice
a lot of automation for this. "Explicit is better than implicit." :)

It should be possible to move or link scripts around.  It is not a requirement
for me to be able to move an environment without running some program to
adjust paths, as long as such a program exists.

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 ianb at colorstudy.com  Wed May 17 20:29:10 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 17 May 2006 13:29:10 -0500
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B6134.7070203@zope.com>
References: <446B4635.2030602@zope.com> <446B508A.6090405@colorstudy.com>
	<446B6134.7070203@zope.com>
Message-ID: <446B6B76.1020908@colorstudy.com>

Jim Fulton wrote:
> Ian Bicking wrote:
> 
>> Jim Fulton wrote:
>>
>>> I seem to remember a threat from from Phillip to make a proposal
>>> for installing script-specific ,pth files with scripts, but I don't
>>> think I every saw anything.  Have I missed anything?  If so, what? :)
>>> If not, I'll probably write something myself and share it.
>>
>>
>>
>> workingenv (http://svn.colorstudy.com/home/ianb/workingenv) doesn't 
>> use .pth files, but does put in script-specific paths.
> 
> 
> As I understand it, it is really putting in environment-specific paths.
> I think I want script-specific paths.

I don't think I understand the distinction?  Specifically, this is what 
gets put in:

#!/usr/bin/python2.4 -S
import sys, os
join, dirname = os.path.join, os.path.dirname
lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % 
tuple(sys.version_info[:2]))
sys.path.insert(0, lib_dir)
import site
# EASY-INSTALL-SCRIPT: 'Cheetah==1.0','cheetah'
__requires__ = 'Cheetah==1.0'
import pkg_resources
pkg_resources.run_script('Cheetah==1.0', 'cheetah')


I.e., it's hardcoding ../lib/python2.4 into the path.  The relative 
directory is right for workingenv (it makes it movable), but an absolute 
location might be what you want.  That's not very different, really.

The "environment" is really built off this path override, not the other 
way around.  The path override is in turn picked up from the environment 
during installation, but that's just a matter of self-consistency.

>> As I note in my previous email ("setuptools: hardcoding the path in a 
>> script and site.py"), I think this would probably be cleanest to do 
>> through a new installation option, that could also be placed into 
>> distutils.cfg.  Right now what workingenv does is very specific to 
>> workingenv, and doesn't work off any public setuptools API.
> 
> 
> I have an intuition that we're thinking about this incorrectly.
> We seem to be going through a lot of effort to fake out something,
> athough I'm not sure what. 

Primarily I'm trying to fake out site.py, which is the source of most of 
my problems.  It's a reasonable implementation of one packaging 
scenario, but it's hard to replace, and the standard implementation 
isn't what I want.

I also want to fake out distutils slightly, mostly to provide my own 
distutils.cfg, which is again a good idea that is far harder to use than 
it should be.

And then I fake out setuptools, which I'd really rather not do, in part 
because my faking out keeps breaking.

Oh, and faking out of #!, which if it wasn't so obnoxiously useless 
would be sufficient to handle the path stuff on its own.

> I have a growing suspiction that
> the traditional model of a large namespace of modules
> that is used by many applications serves simple scripting very well
> but doessn't work well for applications.

Absolutely, that's what I feel as well.  I want to opt-in to modules, 
not get some huge cloud.  At this point, setuptools/easy_install 
actually makes that cloud expand much more quickly with multi-version 
installations, and that's caused real problems for me.



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

From ianb at colorstudy.com  Wed May 17 20:53:34 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 17 May 2006 13:53:34 -0500
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B6A1D.8020903@zope.com>
References: <5.1.1.6.0.20060517125616.0300e160@mail.telecommunity.com>
	<446B638A.4090205@colorstudy.com> <446B6A1D.8020903@zope.com>
Message-ID: <446B712E.5060500@colorstudy.com>

Jim Fulton wrote:
>> It's also a reasonable requirement for scripts you don't want breaking 
>> randomly.  These continue to be my bane.
>>
>> What are the use cases? 
> 

Well, here's how workingenv deals with some of these right now...

> I want to be able to install multiple programs ("scripts"), each with their
> own dependencies.  Note that different programs might depend on
> different versions of the same package.

Inconsistent requirements in a single working environment rely on 
setuptool's multiversion install, which should work fine on its own when 
used in limited places.

> I want to be able to update a package for one program without
> implicitly affecting the others.  (This is a restatement of your
> desire not to get implicit updates)

This is fine.

> I want everything to be installed in a self-contained project,
> ala your working environment.  I don't want to touch a Python install.

Yup.

> I to be able to use a simple install script, like easy_install.

Except for frequent breakage, this works.  I hope that breakage is 
transitional.  Also, the python console works fine and represents the 
working environment, not the larger environment.

With workingenv, I also am playing around with --requirements, which is 
kind of a complete installation plan.  I think an external list of 
requirements is much easier to maintain than packages that carry their 
own requirements; at least for a certain set of problems, like 
co-developed packages, and building consistent development environments 
from code that is actively developed.  Or just building a development 
environment at all, as when you are building a web application.

> I don't want to have to set environment variables or provide funny
> options when I run programs.  I'd like to minimize this when installing 
> things.

When the setuptools monkeypatch works, this is fine.

> I want the system to be simple and understandable.  I'm willing to 
> sacrifice
> a lot of automation for this. "Explicit is better than implicit." :)

Except for some (IMHO necessary) faking out of bits and pieces, 
workingenv is really just a matter of setting the path and keeping the 
path from being implicitly extended.  So I think it's quite simple.  It 
would be nice if Python proper was so simple to work with, but I'm not 
100% sure what I really want yet, and I really don't feel like the grief 
of proposing anything on python-dev.  And anyway, I need this to work 
with old Python versions.

Perhaps one personal motivation is that I don't like to give lots of 
options to tools, I would rather they just work correctly, because any 
option I give is something I might give incorrectly.

That said, having to use /path/to/env/bin/easy_install doesn't bother 
me, even though easy_install --prefix=/path/to/env *does* bother me, so 
maybe workingenv can be a little simpler if I give up completely on 
integrating with any larger system of packages.

> It should be possible to move or link scripts around.  It is not a 
> requirement
> for me to be able to move an environment without running some program to
> adjust paths, as long as such a program exists.

Scripts can't be moved at this time.  The entire environ can be moved, 
though the activation scripts have to be adjusted, because I haven't 
figured out a way to do script-relative paths in a shell script that is 
sourced.  If you don't use the activation script, then that's fine.  And 
maybe the only thing that really needs the activation script is the 
python interactive interpreter.

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

From jim at zope.com  Wed May 17 21:00:32 2006
From: jim at zope.com (Jim Fulton)
Date: Wed, 17 May 2006 15:00:32 -0400
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B6B76.1020908@colorstudy.com>
References: <446B4635.2030602@zope.com> <446B508A.6090405@colorstudy.com>
	<446B6134.7070203@zope.com> <446B6B76.1020908@colorstudy.com>
Message-ID: <446B72D0.8060109@zope.com>

Ian Bicking wrote:
> Jim Fulton wrote:
> 
>> Ian Bicking wrote:
>>
>>> Jim Fulton wrote:
>>>
>>>> I seem to remember a threat from from Phillip to make a proposal
>>>> for installing script-specific ,pth files with scripts, but I don't
>>>> think I every saw anything.  Have I missed anything?  If so, what? :)
>>>> If not, I'll probably write something myself and share it.
>>>
>>>
>>>
>>>
>>> workingenv (http://svn.colorstudy.com/home/ianb/workingenv) doesn't 
>>> use .pth files, but does put in script-specific paths.
>>
>>
>>
>> As I understand it, it is really putting in environment-specific paths.
>> I think I want script-specific paths.
> 
> 
> I don't think I understand the distinction?  Specifically, this is what 
> gets put in:
> 
> #!/usr/bin/python2.4 -S
> import sys, os
> join, dirname = os.path.join, os.path.dirname
> lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % 
> tuple(sys.version_info[:2]))
> sys.path.insert(0, lib_dir)
> import site
> # EASY-INSTALL-SCRIPT: 'Cheetah==1.0','cheetah'
> __requires__ = 'Cheetah==1.0'
> import pkg_resources
> pkg_resources.run_script('Cheetah==1.0', 'cheetah')
> 
> I.e., it's hardcoding ../lib/python2.4 into the path.  The relative 
> directory is right for workingenv (it makes it movable), but an absolute 
> location might be what you want.  That's not very different, really.

Right. I understood this from the links you gave.  Every program (script) installed
into the environment has the same path.  If two programs use the same package,
then upgrading the package for one program updates them all.  I want to avoid
that.

...

>> I have an intuition that we're thinking about this incorrectly.
>> We seem to be going through a lot of effort to fake out something,
>> athough I'm not sure what. 
> 
> 
> Primarily I'm trying to fake out site.py,

That's one of the things we're trying to fake out. :)

...

> I also want to fake out distutils slightly, mostly to provide my own 
> distutils.cfg, which is again a good idea that is far harder to use than 
> it should be.

Yup, that's another example.

> And then I fake out setuptools, which I'd really rather not do, in part 
> because my faking out keeps breaking.

Faking isn't fun.

> Oh, and faking out of #!, which if it wasn't so obnoxiously useless 
> would be sufficient to handle the path stuff on its own.

:)

I suspect this is a case of too much automation in the wrong place.
We are tiptoeing around trying to trick setuptools/distutils/site
into doing the right thing automatically.

>> I have a growing suspiction that
>> the traditional model of a large namespace of modules
>> that is used by many applications serves simple scripting very well
>> but doessn't work well for applications.
> 
> 
> Absolutely, that's what I feel as well.  I want to opt-in to modules, 
> not get some huge cloud.  At this point, setuptools/easy_install 
> actually makes that cloud expand much more quickly with multi-version 
> installations, and that's caused real problems for me.

Yup.

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 ianb at colorstudy.com  Wed May 17 22:10:02 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 17 May 2006 15:10:02 -0500
Subject: [Distutils] Script-specific .pth files (or baking paths into
 scripts)
In-Reply-To: <446B72D0.8060109@zope.com>
References: <446B4635.2030602@zope.com> <446B508A.6090405@colorstudy.com>
	<446B6134.7070203@zope.com> <446B6B76.1020908@colorstudy.com>
	<446B72D0.8060109@zope.com>
Message-ID: <446B831A.1060500@colorstudy.com>

Jim Fulton wrote:
> Right. I understood this from the links you gave.  Every program 
> (script) installed
> into the environment has the same path.  If two programs use the same 
> package,
> then upgrading the package for one program updates them all.  I want to 
> avoid
> that.

Then you need more working environments...?  There's not an expectation 
that you'll just use one working environment.  Potentially each 
"application" will use its own working environment, for some definition 
of "application" (it seems like there's several).

> ...
> 
>>> I have an intuition that we're thinking about this incorrectly.
>>> We seem to be going through a lot of effort to fake out something,
>>> athough I'm not sure what. 
>>
>>
>>
>> Primarily I'm trying to fake out site.py,
> 
> 
> That's one of the things we're trying to fake out. :)
> 
> ...
> 
>> I also want to fake out distutils slightly, mostly to provide my own 
>> distutils.cfg, which is again a good idea that is far harder to use 
>> than it should be.
> 
> 
> Yup, that's another example.
> 
>> And then I fake out setuptools, which I'd really rather not do, in 
>> part because my faking out keeps breaking.
> 
> 
> Faking isn't fun.
> 
>> Oh, and faking out of #!, which if it wasn't so obnoxiously useless 
>> would be sufficient to handle the path stuff on its own.
> 
> 
> :)
> 
> I suspect this is a case of too much automation in the wrong place.
> We are tiptoeing around trying to trick setuptools/distutils/site
> into doing the right thing automatically.

Well, there's virtual-python if you really want total trickery.  That 
doesn't feel as scalable, though.

I guess I don't see a way around it.  It would be nice if Python had an 
option like --use-environment=path.  But even if did, because #! works 
in such a weird way, I don't think that wouldn't be enough.  And 
distutils should have a better option, but it doesn't, and that can't be 
changed now.  Ditto site.py.  So these are just the constraints we have, 
short of just replicating and replacing the Python standard library 
entirely.  Which seems rather heavy, since there's only two or three 
things that need adjustment.  Or wait for updates to Python itself, 
which is a particularly unfruitful way to get progress, since most 
people don't seem that concerned about this stuff.  I have no idea why. 
  Are our experience and use cases really so unusual?


But, thinking about it a bit, maybe /usr/bin/python is the wrong entry 
point.  If the interpreter (aka sys.executable) is something that 
"knows" about whatever this thing is -- be it environment or application 
-- then a lot of things might work better.

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

From pje at telecommunity.com  Thu May 18 02:58:34 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 17 May 2006 20:58:34 -0400
Subject: [Distutils] Script processing plugins?
Message-ID: <5.1.1.6.0.20060517204841.01e63b38@mail.telecommunity.com>

Okay, so after today's discussions I'm still not really clear on how path 
freezing (baking, whatever) should work for standalone setuptools.  Would 
it solve the problem for your use cases if I provided an option like 
"--script-wrappers=plugin1,plugin2,...", where the plugin names are entry 
points that would get a chance to modify the contents of generated 
scripts?  That way, you guys could experiment freely with your 
script-wrapping strategies without having to monkeypatch.  And any tools 
that you build which wrap easy_install can simply add the necessary 
setting(s) to an appropriate .cfg file.


From jim at zope.com  Thu May 18 03:31:30 2006
From: jim at zope.com (Jim Fulton)
Date: Wed, 17 May 2006 21:31:30 -0400
Subject: [Distutils] Script processing plugins?
In-Reply-To: <5.1.1.6.0.20060517204841.01e63b38@mail.telecommunity.com>
References: <5.1.1.6.0.20060517204841.01e63b38@mail.telecommunity.com>
Message-ID: <446BCE72.1070700@zope.com>

Phillip J. Eby wrote:
> Okay, so after today's discussions I'm still not really clear on how 
> path freezing (baking, whatever) should work for standalone setuptools.  
> Would it solve the problem for your use cases if I provided an option 
> like "--script-wrappers=plugin1,plugin2,...", where the plugin names are 
> entry points that would get a chance to modify the contents of generated 
> scripts?  That way, you guys could experiment freely with your 
> script-wrapping strategies without having to monkeypatch.  And any tools 
> that you build which wrap easy_install can simply add the necessary 
> setting(s) to an appropriate .cfg file.

That might be nice at some point.  For now, I think it best if I do
some prototyping sans monkeypatching.  Hopefully, I'll get back to you soon.
I started the discussion today mainly to get caught up, as I haven't had time
to work on this for a while.

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 ianb at colorstudy.com  Thu May 18 06:53:27 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 17 May 2006 23:53:27 -0500
Subject: [Distutils] Script processing plugins?
In-Reply-To: <5.1.1.6.0.20060517204841.01e63b38@mail.telecommunity.com>
References: <5.1.1.6.0.20060517204841.01e63b38@mail.telecommunity.com>
Message-ID: <446BFDC7.5020402@colorstudy.com>

Phillip J. Eby wrote:
> Okay, so after today's discussions I'm still not really clear on how 
> path freezing (baking, whatever) should work for standalone setuptools.  
> Would it solve the problem for your use cases if I provided an option 
> like "--script-wrappers=plugin1,plugin2,...", where the plugin names are 
> entry points that would get a chance to modify the contents of generated 
> scripts?  That way, you guys could experiment freely with your 
> script-wrapping strategies without having to monkeypatch.  And any tools 
> that you build which wrap easy_install can simply add the necessary 
> setting(s) to an appropriate .cfg file.

It seems weird to modify the contents of the scripts.  Can't they just 
get passed the name of the egg and entry point, and return the full 
script?  You couldn't have multiple wrappers, but compatible wrappers 
seem unlikely anyway.

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

From pje at telecommunity.com  Thu May 18 07:48:34 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 18 May 2006 01:48:34 -0400
Subject: [Distutils] Script processing plugins?
In-Reply-To: <446BFDC7.5020402@colorstudy.com>
References: <5.1.1.6.0.20060517204841.01e63b38@mail.telecommunity.com>
	<5.1.1.6.0.20060517204841.01e63b38@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060518014331.01e4bc80@mail.telecommunity.com>

At 11:53 PM 5/17/2006 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Okay, so after today's discussions I'm still not really clear on how path 
>>freezing (baking, whatever) should work for standalone setuptools.
>>Would it solve the problem for your use cases if I provided an option 
>>like "--script-wrappers=plugin1,plugin2,...", where the plugin names are 
>>entry points that would get a chance to modify the contents of generated 
>>scripts?  That way, you guys could experiment freely with your 
>>script-wrapping strategies without having to monkeypatch.  And any tools 
>>that you build which wrap easy_install can simply add the necessary 
>>setting(s) to an appropriate .cfg file.
>
>It seems weird to modify the contents of the scripts.  Can't they just get 
>passed the name of the egg and entry point, and return the full script?

No.  :)  The idea is to allow you to have *wrappers*, not to completely 
redo script generation.


>   You couldn't have multiple wrappers, but compatible wrappers seem 
> unlikely anyway.

I can envision uses for stacked wrappers rather easily, actually, since 
someone might want to write something that freezes other environment 
variables besides (effectively) PYTHONPATH, and they might want to use that 
along with one of your freezing plugins.  So, it seems wise to follow the 
"diversity rule" of Eclipse contributions, i.e. "extension points accept 
multiple extensions".


From jim at zope.com  Thu May 18 16:08:08 2006
From: jim at zope.com (Jim Fulton)
Date: Thu, 18 May 2006 10:08:08 -0400
Subject: [Distutils] What is the reason for requiring that an explicitly set
 egg-install installation is in the path?
Message-ID: <446C7FC8.6050000@zope.com>


If I explicitly specify an installation directory, for example, by
specifying:

   [install]
   install_lib = ~/py-lib
   install_scripts = ~/bin

in setup.cfg, setuptools gives me an error is the specified
lib dir isn't in the Python path.

Why is this?  Is this for my protection? If so, I don't need a path
nanny. :)  I can understand this, to some degree, if --prefix is used,
but if I specifically set an install location, setuptools should trust
that I know what the heck I'm doing.

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  Thu May 18 16:27:22 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 18 May 2006 10:27:22 -0400
Subject: [Distutils] What is the reason for requiring that an explicitly
 set egg-install installation is in the path?
In-Reply-To: <446C7FC8.6050000@zope.com>
Message-ID: <5.1.1.6.0.20060518102056.01e51748@mail.telecommunity.com>

At 10:08 AM 5/18/2006 -0400, Jim Fulton wrote:

>If I explicitly specify an installation directory, for example, by
>specifying:
>
>    [install]
>    install_lib = ~/py-lib
>    install_scripts = ~/bin
>
>in setup.cfg, setuptools gives me an error is the specified
>lib dir isn't in the Python path.
>
>Why is this?  Is this for my protection? If so, I don't need a path
>nanny. :)

Maybe not, but everybody else does.  ;)


>   I can understand this, to some degree, if --prefix is used,
>but if I specifically set an install location, setuptools should trust
>that I know what the heck I'm doing.

EasyInstall is telling you that as things stand, it can't accomplish what 
you asked it to -- specifically to install to that directory in such a way 
that the package is importable.  If you use -m (aka --multi-version), then 
it will not care because getting stuff on the runtime path is then *your* 
responsibility, not setuptools'.

The issue here is that when you install eggs without -m, the target 
directory must support .pth files.  To do that, it must be on PYTHONPATH 
(and use a site.py hack) or it must be a "site" directory.  You can assert 
that a directory is a "site" directory using --site-dirs, and EasyInstall 
will then believe you.

In short, use -m or --site-dirs, and in either case EasyInstall will permit 
you to be responsible for the results, without nannying.  But if you don't 
use either of those options, then it will want proof of your sanity (i.e. a 
correct PYTHONPATH) when installing to a non-site directory.  :)


From jim at zope.com  Thu May 18 17:27:38 2006
From: jim at zope.com (Jim Fulton)
Date: Thu, 18 May 2006 11:27:38 -0400
Subject: [Distutils] What is the reason for requiring that an explicitly
 set egg-install installation is in the path?
In-Reply-To: <5.1.1.6.0.20060518102056.01e51748@mail.telecommunity.com>
References: <5.1.1.6.0.20060518102056.01e51748@mail.telecommunity.com>
Message-ID: <446C926A.5080201@zope.com>

Phillip J. Eby wrote:
> At 10:08 AM 5/18/2006 -0400, Jim Fulton wrote:
> 
>> If I explicitly specify an installation directory, for example, by
>> specifying:
>>
>>    [install]
>>    install_lib = ~/py-lib
>>    install_scripts = ~/bin
>>
>> in setup.cfg, setuptools gives me an error is the specified
>> lib dir isn't in the Python path.
>>
>> Why is this?  Is this for my protection? If so, I don't need a path
>> nanny. :)
> 
> 
> Maybe not, but everybody else does.  ;)

Says you.

>>   I can understand this, to some degree, if --prefix is used,
>> but if I specifically set an install location, setuptools should trust
>> that I know what the heck I'm doing.
> 
> 
> EasyInstall is telling you that as things stand, it can't accomplish 
> what you asked it to -- specifically to install to that directory in 
> such a way that the package is importable.  If you use -m (aka 
> --multi-version), then it will not care because getting stuff on the 
> runtime path is then *your* responsibility, not setuptools'.
> 
> The issue here is that when you install eggs without -m, the target 
> directory must support .pth files.  To do that, it must be on PYTHONPATH 
> (and use a site.py hack) or it must be a "site" directory.  You can 
> assert that a directory is a "site" directory using --site-dirs, and 
> EasyInstall will then believe you.
> 
> In short, use -m or --site-dirs, and in either case EasyInstall will 
> permit you to be responsible for the results, without nannying.  But if 
> you don't use either of those options, then it will want proof of your 
> sanity (i.e. a correct PYTHONPATH) when installing to a non-site 
> directory.  :)

How about an i_do_not_need_a_path_nanny in the config file? ;)


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 ianb at colorstudy.com  Thu May 18 17:29:10 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 18 May 2006 10:29:10 -0500
Subject: [Distutils] What is the reason for requiring that an explicitly
 set egg-install installation is in the path?
In-Reply-To: <5.1.1.6.0.20060518102056.01e51748@mail.telecommunity.com>
References: <5.1.1.6.0.20060518102056.01e51748@mail.telecommunity.com>
Message-ID: <446C92C6.8090805@colorstudy.com>

Phillip J. Eby wrote:
> At 10:08 AM 5/18/2006 -0400, Jim Fulton wrote:
> 
> 
>>If I explicitly specify an installation directory, for example, by
>>specifying:
>>
>>   [install]
>>   install_lib = ~/py-lib
>>   install_scripts = ~/bin
>>
>>in setup.cfg, setuptools gives me an error is the specified
>>lib dir isn't in the Python path.
>>
>>Why is this?  Is this for my protection? If so, I don't need a path
>>nanny. :)
> 
> 
> Maybe not, but everybody else does.  ;)

My $0.02: personally it doesn't bother me, even though I know what I'm 
doing and also hit the error fairly often.  Usually it means something 
somewhere isn't like I thought it was.


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

From ianb at colorstudy.com  Thu May 18 22:34:07 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 18 May 2006 15:34:07 -0500
Subject: [Distutils] setuptools: hardcoding the path in a script and
	site.py
In-Reply-To: <4464F217.7040904@colorstudy.com>
References: <4464F217.7040904@colorstudy.com>
Message-ID: <446CDA3F.4050007@colorstudy.com>

Ian Bicking wrote:
> The other monkeypatch I'm doing is to keep setuptools from demanding to 
> own site.py.  The monkeypatch is:
> 
>    def install_site_py(self):
>        # to heck with this, we gots our own site.py and we'd like
>        # to keep it, thank you
>        pass
>    easy_install.easy_install.install_site_py = install_site_py
> 
> But what would be better is if setuptools installed code somewhere 
> besides site.py.  For instance, site-setuptools.py.  Then if site.py 
> didn't exist, it would be created like:
> 
>    import os
>    # add site-setuptools
>    execfile(os.path.join(os.path.dirname(__file__), 'site-setuptools.py')
> 
> If the file did exist, setuptools would check for the text "add 
> site-setuptools", and give a warning or error if it was not, or maybe 
> would just prefix the site.py with this text, and leave the rest of it 
> as is.  Then I'd include that code in workingenv's site.py.

I should note that even if the monkeypatch for path setting remains 
necessary a while longer, this monkeypatch actually causes me more 
grief.  So if setuptools fixed this, that would be even better.  And I 
think setuptools could actually add site-setuptools.py to existing 
site.py's even instead of the error or overwriting that it does now.  It 
can use the same technique it uses now to upgrade existing site.py's.


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

From pje at telecommunity.com  Thu May 18 23:07:50 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 18 May 2006 17:07:50 -0400
Subject: [Distutils] What is the reason for requiring that an explicitly
 set egg-install installation is in the path?
In-Reply-To: <446C926A.5080201@zope.com>
References: <5.1.1.6.0.20060518102056.01e51748@mail.telecommunity.com>
	<5.1.1.6.0.20060518102056.01e51748@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060518170217.039bdb90@mail.telecommunity.com>

At 11:27 AM 5/18/2006 -0400, Jim Fulton wrote:
>Phillip J. Eby wrote:
>>At 10:08 AM 5/18/2006 -0400, Jim Fulton wrote:
>>
>>>If I explicitly specify an installation directory, for example, by
>>>specifying:
>>>
>>>    [install]
>>>    install_lib = ~/py-lib
>>>    install_scripts = ~/bin
>>>
>>>in setup.cfg, setuptools gives me an error is the specified
>>>lib dir isn't in the Python path.
>>>
>>>Why is this?  Is this for my protection? If so, I don't need a path
>>>nanny. :)
>>
>>Maybe not, but everybody else does.  ;)
>
>Says you.

Yep.  Before I did that, too many people complained about things not 
working right because they thought they knew better, but didn't.  Have you 
verified that if you set PYTHONPATH to ~/py-lib during installation, but 
not at runtime, that things still work as you intend?  If you haven't 
verified this, you are still in the "think you know better" stage, rather 
than the "actually knows better" stage.  :)


>>>   I can understand this, to some degree, if --prefix is used,
>>>but if I specifically set an install location, setuptools should trust
>>>that I know what the heck I'm doing.
>>
>>EasyInstall is telling you that as things stand, it can't accomplish what 
>>you asked it to -- specifically to install to that directory in such a 
>>way that the package is importable.  If you use -m (aka --multi-version), 
>>then it will not care because getting stuff on the runtime path is then 
>>*your* responsibility, not setuptools'.
>>The issue here is that when you install eggs without -m, the target 
>>directory must support .pth files.  To do that, it must be on PYTHONPATH 
>>(and use a site.py hack) or it must be a "site" directory.  You can 
>>assert that a directory is a "site" directory using --site-dirs, and 
>>EasyInstall will then believe you.
>>In short, use -m or --site-dirs, and in either case EasyInstall will 
>>permit you to be responsible for the results, without nannying.  But if 
>>you don't use either of those options, then it will want proof of your 
>>sanity (i.e. a correct PYTHONPATH) when installing to a non-site directory.  :)
>
>How about an i_do_not_need_a_path_nanny in the config file? ;)

If the directory already allows .pth files to be processed (or you will 
take responsibility for ensuring this), then just list it in 
--site-dirs.  Otherwise, the correct way to show EasyInstall that you are 
able to set your PYTHONPATH is by setting your PYTHONPATH.  :)


From number5 at gmail.com  Sat May 20 17:06:11 2006
From: number5 at gmail.com (Bruce Wang)
Date: Sat, 20 May 2006 23:06:11 +0800
Subject: [Distutils] Fwd: [Remind-Fans] wxRemind - new release
In-Reply-To: <20060519183653.GA18889@bastiat.econ.duke.edu>
References: <20060518163214.GA14929@bastiat.econ.duke.edu>
	<8d581cfd0605182051l3ed9255el2457a5513e969c02@mail.gmail.com>
	<20060519183653.GA18889@bastiat.econ.duke.edu>
Message-ID: <8d581cfd0605200806l1cd0f79at395ef02f16cd264e@mail.gmail.com>

Here is some questions from Daniel Graham (the author of wxRemind),   maybe
someone on this list could answer :)


---------- Forwarded message ----------
From: Daniel Graham <daniel.graham at duke.edu>
Date: May 20, 2006 2:36 AM
Subject: Re: [Remind-Fans] wxRemind - new release
To: Users of the REMIND system <remind-fans at whatexit.org>

Bruce,

Thanks for the suggestions and the links.  I had fooled around with
distutils and nearly went crazy. My experience with setuptools and
easy_install was much more pleasant. I've thus added setup.py to the
package but left INSTALL so there are now three installation
alternatives: './INSTALL', 'python setup.py' and 'easy_install
wxRemind'. All are documented in the README and the home page at:

    http://www.duke.edu/~dgraham/wxRemind

I've also registered wxRemind at PyPI.

Still, the "egg" is not all that I wished:

    1) I could never get the dependencies to work right. Even though
    wxPython 2.6.3.2 is registered, easy_install would complain
    about not being able to satisfy wxPython>=2.6.1.  No problem
    satifying Python>=2.3, on the other hand, but easy_install would
    then identify 2.4 as 'better' and try to install that. I
    ended up dropping both requirements.

    2) It is still necessary to download FLOAT and WXREMINDRC since
    I couldn't figure out a way to make them accessable in the egg.

If you have suggestions about how to modify my setup.py to fix these
problems or other suggestions, I would be most grateful.

-Dan

On 2006-05-19 11:51 +0800, Bruce Wang wrote:
> wxRemind is great!
> Would you mind package it as python eggs [1] (and register it at PyPI [2]
of
> course)
> It will be much more easier for users to upgrade/install using python eggs
>
> [1] http://peak.telecommunity.com/DevCenter/PythonEggs
> [2] http://www.python.org/pypi
>
> --
> simple is good
> http://brucewang.net

_______________________________________________
Remind-fans mailing list
Remind-fans at lists.whatexit.org
http://lists.whatexit.org/mailman/listinfo/remind-fans


-- 
simple is good
http://brucewang.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20060520/5363db12/attachment.html 

From pje at telecommunity.com  Sat May 20 17:29:08 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 20 May 2006 11:29:08 -0400
Subject: [Distutils] Fwd: [Remind-Fans] wxRemind - new release
In-Reply-To: <8d581cfd0605200806l1cd0f79at395ef02f16cd264e@mail.gmail.co
 m>
References: <20060519183653.GA18889@bastiat.econ.duke.edu>
	<20060518163214.GA14929@bastiat.econ.duke.edu>
	<8d581cfd0605182051l3ed9255el2457a5513e969c02@mail.gmail.com>
	<20060519183653.GA18889@bastiat.econ.duke.edu>
Message-ID: <5.1.1.6.0.20060520112326.01f25c00@mail.telecommunity.com>

At 11:06 PM 5/20/2006 +0800, Bruce Wang wrote:
>Here is some questions from Daniel Graham (the author of 
>wxRemind),   maybe someone on this list could answer :)
>
>---------- Forwarded message ----------
>From: Daniel Graham <<mailto:daniel.graham at duke.edu>daniel.graham at duke.edu>
>Date: May 20, 2006 2:36 AM
>Subject: Re: [Remind-Fans] wxRemind - new release
>To: Users of the REMIND system <<mailto:remind-fans at whatexit.org> 
>remind-fans at whatexit.org>
>
>Bruce,
>
>Thanks for the suggestions and the links.  I had fooled around with
>distutils and nearly went crazy. My experience with setuptools and
>easy_install was much more pleasant. I've thus added setup.py to the
>package but left INSTALL so there are now three installation
>alternatives: './INSTALL', 'python setup.py' and 'easy_install
>wxRemind'. All are documented in the README and the home page at:
>
> 
><http://www.duke.edu/~dgraham/wxRemind>http://www.duke.edu/~dgraham/wxRemind
>
>I've also registered wxRemind at PyPI.
>
>Still, the "egg" is not all that I wished:
>
>     1) I could never get the dependencies to work right. Even though
>     wxPython <http://2.6.3.2>2.6.3.2 is registered, easy_install would 
> complain
>     about not being able to satisfy wxPython>=2.6.1.

That's because the wxPython distribution files are improperly named; the 
source file for wxPython 2.6.3.2 is named 'wxPython-src-2.6.3.2.tar.gz' 
(instead of the distutils-standard 'wxPython-2.6.3.2.tar.gz'), so 
easy_install thinks this is a project named 'wxPython' with version 
'src-2.6.3.2'.  You would need to make the dependency 'wxpython>=src-2.6.1' 
in order for it to work, or gripe at the wxPython folks to fix their 
filenames.  :)

Unfortunately, some popular packages that pre-date the distutils (or 
largely replace the distutils with custom machinery) do not distribute 
packages that follow distutils naming conventions, or else they register 
their packages under a different name than the package is actually produced 
with.


>   No problem
>     satifying Python>=2.3, on the other hand, but easy_install would
>     then identify 2.4 as 'better' and try to install that. I
>     ended up dropping both requirements.

Python isn't a distutils package, so don't try to depend on it.  In any 
case setuptools only works with Python 2.3 and above, so nobody with Python 
2.2 is going to be running easy_install.  :)


>     2) It is still necessary to download FLOAT and WXREMINDRC since
>     I couldn't figure out a way to make them accessable in the egg.

I don't know what this means, so I can't help without more details.


From nathan at yergler.net  Mon May 22 16:37:35 2006
From: nathan at yergler.net (Nathan R. Yergler)
Date: Mon, 22 May 2006 10:37:35 -0400
Subject: [Distutils] Installing via ez_setup.py reports error
Message-ID: <4471CCAF.90204@yergler.net>

I'm working on increasing my setuptools-foo-zen-karma-whatever, and have
a question.  According to the docs at
http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions,
you just need to download ez_setup.py and run it to install setuptools.
 I'm trying to install to a custom location.  When I run the following
command:

$ PYTHONPATH=lib/ python ez_setup.py --script-dir bin/ --install-dir
lib/ -a --site-dirs lib/

setuptools is installed as requested, but the following error is reported

Installed /home/nathan/Projects/zope.i18n/lib/setuptools-0.6b1-py2.4.egg
Processing dependencies for setuptools==0.6b1
error: No urls, filenames, or requirements specified (see --help)

On a separate topic, echoing Jim's comments regarding paths, it seems
silly that when I use the following command (omitting the explicit
PYTHONPATH):

$ python ez_setup.py --script-dir bin/ --install-dir lib/ -a --site-dirs
lib/

I'm told that ./lib is not on sys.path; isn't the point of site-dirs to
assert that a directory *will be* on the Python path?  I'll be the first
to acknowledge that I may be missing some fundamental point here.

Thanks,

Nathan

From pje at telecommunity.com  Mon May 22 17:29:26 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 22 May 2006 11:29:26 -0400
Subject: [Distutils] Installing via ez_setup.py reports error
In-Reply-To: <4471CCAF.90204@yergler.net>
Message-ID: <5.1.1.6.0.20060522112301.03b38008@mail.telecommunity.com>

At 10:37 AM 5/22/2006 -0400, Nathan R. Yergler wrote:
>I'm working on increasing my setuptools-foo-zen-karma-whatever, and have
>a question.  According to the docs at
>http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions,
>you just need to download ez_setup.py and run it to install setuptools.
>  I'm trying to install to a custom location.  When I run the following
>command:
>
>$ PYTHONPATH=lib/ python ez_setup.py --script-dir bin/ --install-dir
>lib/ -a --site-dirs lib/
>
>setuptools is installed as requested, but the following error is reported
>
>Installed /home/nathan/Projects/zope.i18n/lib/setuptools-0.6b1-py2.4.egg
>Processing dependencies for setuptools==0.6b1
>error: No urls, filenames, or requirements specified (see --help)

When ez_setup.py sees any command-line arguments, it runs easy_install with 
them once setuptools is bootstrapped.  EasyInstall then sees that there are 
only options and no arguments, so it complains.  I'm not sure if there's a 
reasonable fix for this, but I'll look into it.


>On a separate topic, echoing Jim's comments regarding paths, it seems
>silly that when I use the following command (omitting the explicit
>PYTHONPATH):
>
>$ python ez_setup.py --script-dir bin/ --install-dir lib/ -a --site-dirs
>lib/
>
>I'm told that ./lib is not on sys.path; isn't the point of site-dirs to
>assert that a directory *will be* on the Python path?

Actually, it's to assert that .pth files will be processed in that 
directory at Python startup.

I guess there is no escaping the Path Nanny, after all.  :)  Well, there's 
-m, actually.


From nathan at yergler.net  Mon May 22 17:55:01 2006
From: nathan at yergler.net (Nathan R. Yergler)
Date: Mon, 22 May 2006 11:55:01 -0400
Subject: [Distutils] Installing via ez_setup.py reports error
In-Reply-To: <5.1.1.6.0.20060522112301.03b38008@mail.telecommunity.com>
References: <5.1.1.6.0.20060522112301.03b38008@mail.telecommunity.com>
Message-ID: <4471DED5.9040707@yergler.net>

>> error: No urls, filenames, or requirements specified (see --help)
> 
> When ez_setup.py sees any command-line arguments, it runs easy_install
> with them once setuptools is bootstrapped.  EasyInstall then sees that
> there are only options and no arguments, so it complains.  I'm not sure
> if there's a reasonable fix for this, but I'll look into it.

Ah, so if I understand correctly setuptools sees the command line
options and assumes there will be an argument associated with them.  It
goes ahead and uses the options for bootstrapping, but then complains
when it doesn't find the argument.  Is this new-ish behavior?  I don't
seem to recall that happening when I was working with this initially
(PyCon-ish time frame).

>> On a separate topic, echoing Jim's comments regarding paths, it seems
>> silly that when I use the following command (omitting the explicit
>> PYTHONPATH):
>>
>> $ python ez_setup.py --script-dir bin/ --install-dir lib/ -a --site-dirs
>> lib/
>>
>> I'm told that ./lib is not on sys.path; isn't the point of site-dirs to
>> assert that a directory *will be* on the Python path?
> 
> Actually, it's to assert that .pth files will be processed in that
> directory at Python startup.
> 
> I guess there is no escaping the Path Nanny, after all.  :)  Well,
> there's -m, actually.

So it sounds like --site-dirs is more like --processes-pth-files :).


> 



From nathan at yergler.net  Mon May 22 17:59:29 2006
From: nathan at yergler.net (Nathan R. Yergler)
Date: Mon, 22 May 2006 11:59:29 -0400
Subject: [Distutils] error: None
Message-ID: <4471DFE1.6060602@yergler.net>

Thanks to Phillip for the insight into the interaction between
command-line arguments and options.  So another question regarding error
reporting.  When I so something like:

$ PYTHONPATH=lib/ python ez_setup.py --install-dir lib/ --script-dir
bin/ --site-dirs lib/ zope.testing

setuptools is bootstrapped correctly, and zope.testing and its
dependencies are downloaded and installed.  However, at the end of the
run you get a message like:

Installed /home/nathan/Projects/zope.i18n/lib/setuptools-0.6b1-py2.4.egg
Processing dependencies for setuptools==0.6b1
error: None

Does anyone have any insights into this?  From the output it looks like
it's processing the zope.testing and zope.testing dependencies first,
then setuptools.  Even with the error, everything seems to be installed
correctly; I can just see how the message would be disconcerting to some
users.

Thanks again,

Nathan


From ben at groovie.org  Mon May 22 19:34:25 2006
From: ben at groovie.org (Ben Bangert)
Date: Mon, 22 May 2006 10:34:25 -0700
Subject: [Distutils] setuptools auto-installing not working due to
	python.org proxy/redirect not working
Message-ID: <74007b23df616075d68cbc35f70bd403@groovie.org>

I noticed this morning that python.org is no longer either proxying or 
redirecting under python.org/pypi/XXXXXX/ which means that setuptools 
breaks for installation:
Searching for MyghtyUtils
Reading http://www.python.org/pypi/MyghtyUtils/
No local packages or download links found for MyghtyUtils

Of course, we know that
http://cheeseshop.python.org/pypi/MyghtyUtils

works just fine. Is it possible to have setuptools have a list of URL's 
to try and fail-over to the next one in the event it can't find it at 
the first one? Ideally, setuptools should also be able to pull a list 
of servers mirroring the data for fail-over as well sort of like CPAN 
so that there's some redundancy in the system.

Cheers,
Ben Bangert


From pje at telecommunity.com  Mon May 22 21:14:36 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 22 May 2006 15:14:36 -0400
Subject: [Distutils] setuptools auto-installing not working due to
 python.org proxy/redirect not working
In-Reply-To: <74007b23df616075d68cbc35f70bd403@groovie.org>
Message-ID: <5.1.1.6.0.20060522151142.021a6048@mail.telecommunity.com>

At 10:34 AM 5/22/2006 -0700, Ben Bangert wrote:
>I noticed this morning that python.org is no longer either proxying or
>redirecting under python.org/pypi/XXXXXX/ which means that setuptools
>breaks for installation:
>Searching for MyghtyUtils
>Reading http://www.python.org/pypi/MyghtyUtils/
>No local packages or download links found for MyghtyUtils

This should be reported to the Python webmaster, as it will also break the 
distutils  "setup.py register" and "setup.py upload" commands, independent 
of setuptools.


>Of course, we know that
>http://cheeseshop.python.org/pypi/MyghtyUtils
>
>works just fine. Is it possible to have setuptools have a list of URL's
>to try and fail-over to the next one in the event it can't find it at
>the first one? Ideally, setuptools should also be able to pull a list
>of servers mirroring the data for fail-over as well sort of like CPAN
>so that there's some redundancy in the system.

There's a command line option to set the index's base URL, but that 
shouldn't be necessary in this case.  The python.org is broken, as this 
redirection failure breaks the distutils for all currently distributed 
versions of Python and it should therefore be fixed at once.


From jim at zope.com  Wed May 24 21:41:47 2006
From: jim at zope.com (Jim Fulton)
Date: Wed, 24 May 2006 15:41:47 -0400
Subject: [Distutils] Why isn't a link given higher precedence than an egg
Message-ID: <4474B6FB.9080301@zope.com>


In an egg directory, I have:

   zc.buildout-0.1-py2.3.egg
   zc.buildout.egg-link

and the version the link is pointing to is 0.1.

If en environment is asked to pick the best match, it picks
zc.buildout-0.1-py2.3.egg.  Given that a link is the result of
"setup.py develop", I would expect it to get preference bacause it
reflects current developemnt.

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  Wed May 24 21:59:05 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 24 May 2006 15:59:05 -0400
Subject: [Distutils] Why isn't a link given higher precedence than an egg
In-Reply-To: <4474B6FB.9080301@zope.com>
Message-ID: <5.1.1.6.0.20060524155232.033b6290@mail.telecommunity.com>

At 03:41 PM 5/24/2006 -0400, Jim Fulton wrote:

>In an egg directory, I have:
>
>    zc.buildout-0.1-py2.3.egg
>    zc.buildout.egg-link
>
>and the version the link is pointing to is 0.1.
>
>If en environment is asked to pick the best match, it picks
>zc.buildout-0.1-py2.3.egg.  Given that a link is the result of
>"setup.py develop", I would expect it to get preference bacause it
>reflects current developemnt.

Source distributions actually have *lower* precedence than egg binaries, if 
they have the same version number.  This is mainly a heuristic so that 
easy_install will not build a package from source if there's a compatible 
binary version available.

In typical usage, easy-install.pth sets which egg is the current default, 
thus sidestepping this ambiguity.