On 03/16/2011 11:47 PM, P.J. Eby wrote:
At 11:28 AM 3/16/2011 +0100, Adam GROSZER wrote:
On 03/14/2011 07:50 PM, P.J. Eby wrote:
Run python -c 'import pkg_resources;print
pkg_resources.get_build_platform()' (with the Python interpreter you're
using.
D:\installc:\Python26_64\python.exe
Python
Carl Meyer carl at oddbird.net writes:
work well. Please try it and tell me what I missed!
To try it out, create a directory somewhere with a bin/ subdirectory,
symlink or copy (it works either way) the python3 binary from an install
of the pythonv2 branch into bin/, and create
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 Wed, Mar 16, 2011 at 10:39 PM, Barry Warsaw ba...@python.org wrote:
I vaguely recall that while this *should* work, it actually doesn't
because once the executable has started, $LD_LIBRARY_PATH isn't consulted
again.
I recall less vaguely, since we've had to deal with this problem more
On Mar 17, 2011, at 08:36 AM, Fred Drake wrote:
On Wed, Mar 16, 2011 at 10:39 PM, Barry Warsaw ba...@python.org wrote:
I vaguely recall that while this *should* work, it actually doesn't
because once the executable has started, $LD_LIBRARY_PATH isn't consulted
again.
I recall less vaguely,
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
Hi all,
This is my first post specifically to distutils-sig, though I've had
an interest in packaging for a while (having come up with some fairly
arcane schemes in the past, where no better alternatives were
apparent).
At any rate: I'm currently working on a plan to overhaul how a number
of my
Hi,
two weeks ago I asked about your opinions on a buildout option
that enforces specifying (MD5) checksums for all files downloaded
through buildout's download utility API. I've been discussing the
subject with Christian Theune in the meantime and would like to
describe a more concrete proposal
Hi Erik,
On Thu, Mar 17, 2011 at 8:42 AM, Erik Bray erik.m.b...@gmail.com wrote:
Hi all,
This is my first post specifically to distutils-sig, though I've had
an interest in packaging for a while (having come up with some fairly
arcane schemes in the past, where no better alternatives were
Hi Vinay,
On 03/17/2011 06:25 AM, Vinay Sajip wrote:
It seems to work with a symlink but not with a copy. With an empty
pythonv.conf
file in ~/projects/vptest:
vinay@eta-natty:~/projects/vptest/bin$ ln -s ~/tools/cpythonv/python
vinay@eta-natty:~/projects/vptest/bin$ ./python
Python
On 03/17/2011 10:56 AM, Barry Warsaw wrote:
Thanks for helping bolster my memory! I still think setting $LD_LIBRARY_PATH
won't be necessary in the majority of cases, so generally no re-exec should
happen. I can imagine that if it *were* necessary, an appropriate section in
the pythonv.conf
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 Mar 17, 2011, at 12:32 PM, Carl Meyer wrote:
I also realized last night that if the need for LD_LIBRARY_PATH is as
rare as it seems to be, people could just as well set it themselves
before running stuff in their virtualenv. We could even have our shell
activate script set it, so you'd only
Hi Thomas,
I like your idea in general. I'd like to point to the following
suggestion with patch+test (though it might need some cleanup) that is
not exactly related to what you're proposing, but has to do with the
same thing (relationship between files and checksums):
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
On 03/16/2011 11:04 PM, Barry Warsaw wrote:
+1. Time for a PEP?
Working on a draft PEP. I'll push it to bitbucket to make collaboration
easier - then the next step would be to present the draft on
python-ideas, if I'm reading PEP 2 correctly?
Carl
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/17/2011 02:50 PM, Carl Meyer wrote:
On 03/16/2011 11:04 PM, Barry Warsaw wrote:
+1. Time for a PEP?
Working on a draft PEP. I'll push it to bitbucket to make collaboration
easier - then the next step would be to present the draft on
On Mar 17, 2011, at 02:50 PM, Carl Meyer wrote:
On 03/16/2011 11:04 PM, Barry Warsaw wrote:
+1. Time for a PEP?
Working on a draft PEP. I'll push it to bitbucket to make collaboration
easier - then the next step would be to present the draft on
python-ideas, if I'm reading PEP 2 correctly?
I
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
Carl Meyer carl at oddbird.net writes:
This is odd, as the same setup works fine for me with a copied binary
(I'm on Ubuntu 10.10). If you're willing to do any more debugging on
this, here's what would be helpful:
I think I know what the problem is: the python executable checks to see where
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
On this system I have a local build of Python made from the official default
branch, which is installed to /usr/local/lib since the system Python is 3.2
(Ubuntu 11.04 - Natty).
Sorry, I meant to say that the system Python is 2.7 (in /usr). I also
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
37 matches
Mail list logo
