Fred Drake wrote:
On Fri, Mar 18, 2011 at 9:50 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
We don't have to make it look so Windows-like, though. We could
use something more cheerful such as 'python.nothisisnotthedirectory'.
Yes, but... the sad part is that a turd has to be
Is .cfg generally preferred to .conf for some good reason?
FTR, it’s the form used by modules in the standard library: distutils,
idle, unittest in a near future. (One exception is .pypirc.) I find
“.conf” ugly :)
de-gustibus-non-disputandum-ly yours
On Mar 18, 2011, at 10:37 AM, Carl Meyer wrote:
Hmm, really? What extension does the executable typically have on OS X
that ought to be stripped?
As others have pointed out, the OS X build leaves a python.exe in the
development tree, but installs without the .exe. I think it's useful to be
able
On 17 Mar, 2011, at 21:33, Barry Warsaw wrote:
Sounds good to me.
On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:
* executable-name has the extension stripped on Windows, but not
otherwise.
It should probably also have the extension stripped on OS X too.
There is no extension on OSX.
On 03/17/2011 09:33 PM, Barry Warsaw wrote:
On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:
* executable-name has the extension stripped on Windows, but not
otherwise.
It should probably also have the extension stripped on OS X too.
Hmm, really? What extension does the executable typically
On 03/17/2011 08:35 PM, P.J. Eby wrote:
* I eliminated any form of generically-named config file, as I think the
extra possible names (and thus possible sources of confusion) is not
really worth the benefit. The only use case I can think of is if you
have multiple python binaries or symlinks
On Thu, Mar 17, 2011 at 5:33 PM, Carl Meyer c...@oddbird.net wrote:
On 03/17/2011 05:13 PM, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for
./bin/clean.pythonv and
On Thu, Mar 17, 2011 at 6:08 PM, P.J. Eby p...@telecommunity.com wrote:
At 05:13 PM 3/17/2011 -0400, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for
./bin/clean.pythonv
On Fri, Mar 18, 2011 at 10:37 AM, Carl Meyer c...@oddbird.net wrote:
On 03/17/2011 09:33 PM, Barry Warsaw wrote:
On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:
* executable-name has the extension stripped on Windows, but not
otherwise.
It should probably also have the extension stripped on
On Fri, Mar 18, 2011 at 11:09 AM, Jim Fulton j...@zope.com wrote:
None. Barry's been using Ubuntu too long and has forgotten that Mac OS
X is Unix. :)
There's also the fact that Python on Mac OS X builds with a .exe
extension; I don't recall it getting installed that way, though. On a
On Fri, Mar 18, 2011 at 11:18 AM, Fred Drake fdr...@acm.org wrote:
On Fri, Mar 18, 2011 at 11:09 AM, Jim Fulton j...@zope.com wrote:
None. Barry's been using Ubuntu too long and has forgotten that Mac OS
X is Unix. :)
There's also the fact that Python on Mac OS X builds with a .exe
Jim Fulton wrote:
None. Barry's been using Ubuntu too long and has forgotten that Mac OS
X is Unix. :)
Or possibly he's thinking of the .app extension that application
bundles have on MacOSX. But that's *not* the executable that
gets run -- the actual executable is buried inside the
Jim Fulton wrote:
On Fri, Mar 18, 2011 at 11:18 AM, Fred Drake fdr...@acm.org wrote:
On a
case-senseless filesystem, distinguishing the python executable from
the Python directory in the sources requires that unfortunate
extension.
So sad.
We don't have to make it look so Windows-like,
Whatever mechanism we end up with, I suggest that a standard python
install include an isolated configuration. This is a common use case
and should be available without having to create a virtualenv (or
whatever) for each project or working directory.
I'm very happy to see this work taking place.
On Mar 17, 2011, at 08:07 AM, Jim Fulton wrote:
Whatever mechanism we end up with, I suggest that a standard python
install include an isolated configuration. This is a common use case
and should be available without having to create a virtualenv (or
whatever) for each project or working
On 03/17/2011 10:59 AM, Barry Warsaw wrote:
On Mar 17, 2011, at 08:07 AM, Jim Fulton wrote:
Whatever mechanism we end up with, I suggest that a standard python
install include an isolated configuration. This is a common use case
and should be available without having to create a virtualenv
On Thu, Mar 17, 2011 at 12:44 PM, Carl Meyer c...@oddbird.net wrote:
On 03/17/2011 10:59 AM, Barry Warsaw wrote:
On Mar 17, 2011, at 08:07 AM, Jim Fulton wrote:
Whatever mechanism we end up with, I suggest that a standard python
install include an isolated configuration. This is a common use
On 03/17/2011 01:23 PM, Jim Fulton wrote:
My understanding of how this will work was that I could created this
myself by creating some sort of configuration file, say clean.cfg and
then link a Python executable to the name clean. Reading pythonv,
take two more carefully, I see that it is a
On Thu, Mar 17, 2011 at 1:41 PM, Carl Meyer c...@oddbird.net wrote:
Actually, now that I come to think of it, pythonv (take two) does
already cover your requirement. If you have a symlinked or copied python
binary, and an empty pythonv.conf one directory up, and you simply
_don't_ create any
At 01:41 PM 3/17/2011 -0400, Carl Meyer wrote:
Actually, now that I come to think of it, pythonv (take two) does
already cover your requirement. If you have a symlinked or copied python
binary, and an empty pythonv.conf one directory up,
Is there any reason why the configuration file has to be
On 03/17/2011 03:00 PM, P.J. Eby wrote:
At 01:41 PM 3/17/2011 -0400, Carl Meyer wrote:
Actually, now that I come to think of it, pythonv (take two) does
already cover your requirement. If you have a symlinked or copied python
binary, and an empty pythonv.conf one directory up,
Is there any
On 03/17/2011 01:53 PM, Jim Fulton wrote:
It occurs to me that it would be nice if site.py could grow knowledge
of whether -S was used and not automatically mutate the path if -S was
used. That would allow -S to work robustly without having to link
anything or create a config file.
This
On Thu, Mar 17, 2011 at 3:46 PM, Carl Meyer c...@oddbird.net wrote:
On 03/17/2011 01:53 PM, Jim Fulton wrote:
It occurs to me that it would be nice if site.py could grow knowledge
of whether -S was used and not automatically mutate the path if -S was
used. That would allow -S to work robustly
On Thu, Mar 17, 2011 at 3:04 PM, Carl Meyer c...@oddbird.net wrote:
On 03/17/2011 03:00 PM, P.J. Eby wrote:
At 01:41 PM 3/17/2011 -0400, Carl Meyer wrote:
Actually, now that I come to think of it, pythonv (take two) does
already cover your requirement. If you have a symlinked or copied python
On 03/17/2011 05:13 PM, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for
./bin/clean.pythonv and ./pythonv.cfg.
Nice - I like the ability to have multiple interpreters
On Thu, Mar 17, 2011 at 5:33 PM, Carl Meyer c...@oddbird.net wrote:
On 03/17/2011 05:13 PM, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for
./bin/clean.pythonv and
On Thu, Mar 17, 2011 at 5:33 PM, Carl Meyer c...@oddbird.net wrote:
Is .cfg generally preferred to .conf for some good reason? I don't
personally care too much; the former is shorter but the latter looks
less ugly to me ;-)
That all depends on who you ask; I tend to prefer .conf myself (but
At 05:13 PM 3/17/2011 -0400, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for
./bin/clean.pythonv and ./pythonv.cfg.
And on Windows, presumably remove the .exe part? or are
On Mar 17, 2011, at 12:44 PM, Carl Meyer wrote:
Any opinions on the commandline UI for this? I was thinking of just
adding a pythonv.py to the stdlib that you could execute with python
-m pythonv path/to/new/env (and would also export appropriate API to
create environments programmatically).
On 03/17/2011 04:39 PM, Barry Warsaw wrote:
Bikeshedding time: how about something a little more descriptive?
$ python -m virtualize path/to/new/env
Ok, that color will do nicely.
Carl
___
Distutils-SIG maillist - Distutils-SIG@python.org
On Mar 17, 2011, at 05:33 PM, Carl Meyer wrote:
On 03/17/2011 05:13 PM, Jim Fulton wrote:
I suggest the following:
Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
So if I've linked the Python executable to ./bin/clean, look for
./bin/clean.pythonv and ./pythonv.cfg.
Nice - I
FWIW, I've pushed a reworking of the config-file-finding, with the
following shed-paint color choices:
* File is named executable-name.virtual.conf (I kept the .virtual,
despite it being longer and not strictly necessary, because I think it
more clearly expresses the function of the file. The
At 07:53 PM 3/17/2011 -0400, Carl Meyer wrote:
FWIW, I've pushed a reworking of the config-file-finding, with the
following shed-paint color choices:
* File is named executable-name.virtual.conf (I kept the .virtual,
despite it being longer and not strictly necessary, because I think it
more
Sounds good to me.
On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:
* executable-name has the extension stripped on Windows, but not
otherwise.
It should probably also have the extension stripped on OS X too.
-Barry
signature.asc
Description: PGP signature
34 matches
Mail list logo
