On Tue, 2008-04-22 at 12:19 -0400, Phillip J. Eby wrote:
> At 11:49 AM 4/22/2008 -0400, Pete wrote:
> >On Apr 21, 2008, at 6:01 PM, Phillip J. Eby wrote:
> >
> >>At 04:23 PM 4/21/2008 -0400, Pete wrote:
> >>>I'm not looking for explicit testing support from setuptools for
> >>>testing here - I'm j
On Tue, 2008-04-15 at 13:01 +1200, Greg Ewing wrote:
> David Cournapeau wrote:
> > what is needed is a stable API for the used packages.
>
> That's a nice ideal to aim for, but it's only achievable
> for old and mature packages.
I don't think so. It requires vigil on the part of the maintainer,
Sorry for breaking up the thread. I wasn't subscribed to the list (now
I am) and apparently I stopped being CC'd at some point, so I'll have to
sum up several things and address them here.
1) I agree that "system" scripts should use the "system" python
(whatever that is defined to mean - for now
On Sat, 2008-04-12 at 19:54 -0400, Phillip J. Eby wrote:
> (That's also, by the way, why easy_install also always installs a
> versioned executable name for itself.)
So if setuptools can rely on this name, why doesn't it use it in the
shebang line?
Regards,
Cliff
_
On Sat, 2008-04-12 at 19:54 -0400, Phillip J. Eby wrote:
> At 03:26 PM 4/12/2008 -0700, Cliff Wells wrote:
>
> >On Sat, 2008-04-12 at 17:53 -0400, Phillip J. Eby wrote:
> > > At 12:30 PM 4/12/2008 -0700, Cliff Wells wrote:
> > > >PATH is *supposed* to affect app
On Sat, 2008-04-12 at 17:53 -0400, Phillip J. Eby wrote:
> At 12:30 PM 4/12/2008 -0700, Cliff Wells wrote:
> >PATH is *supposed* to affect applications.
>
> It affects which application you should run, not which interpreter
> you run the application with.
I think that
On Sat, 2008-04-12 at 13:49 -0400, Phillip J. Eby wrote:
> At 09:58 AM 4/12/2008 -0700, Cliff Wells wrote:
> >Unless I'm missing something, I can't see the advantage your way has
> >over the traditional way.
>
> Well for one, it isn't affected by change
On Sat, 2008-04-12 at 12:19 -0400, Phillip J. Eby wrote:
> At 09:07 PM 4/11/2008 -0700, Cliff Wells wrote:
> >It seems the correct solution to this is to use "#!/usr/bin/env
> >python" (or rather, evaluate `which env` to account for some systems
> >which have /b
