Carl Meyer carl at oddbird.net writes:
The version key could in theory be useful to know whether a particular
venv created by that Python has or has not yet been upgraded to match,
but since the upgrade is trivial and idempotent I don't think that is
important.
Agreed it's not essential,
Hi Paul,
On 05/07/2012 04:16 PM, Paul Moore wrote:
On 7 May 2012 21:55, Martin v. Löwismar...@v.loewis.de wrote:
This sounds to me like a level of complexity unwarranted by the severity
of the problem, especially when considering the additional burden it
imposes on alternative Python
On 8 May 2012 17:14, Carl Meyer c...@oddbird.net wrote:
I don't think anyone has proposed making symlinks the default on Windows. At
this point the two options on Windows would be to use the --symlink option
explicitly, or else to need to run pyvenv --upgrade on your envs if you
upgrade the
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right solution to me. PEP 405 specifies that bin/python3
exists, but not that it is the actual
On 7 May, 2012, at 11:52, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right solution to me. PEP 405 specifies
On 05/07/2012 04:26 AM, Ronald Oussoren wrote:
On 7 May, 2012, at 11:52, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this
here for the sake of completeness, but it's already been rejected
due to significant problems on older Windows' and OS X.
That sounds
On 05/07/2012 03:52 AM, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right solution to me. PEP 405 specifies that
The bin/python3 executable in a framework is a small stub that
execv's the real interpreter that is stuffed in a Python.app bundle
inside the Python framework. That's done to ensure that GUI code can
work from the command-line, Apple's GUI framework refuse to work when
the executable is not in an
On 07.05.2012 18:35, Carl Meyer wrote:
On 05/07/2012 03:52 AM, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right
Ronald Oussoren ronaldoussoren at mac.com writes:
Because of this trick pyvenv won't know which executable the user actually
called and hence cannot find the pyvenv configuration file (which is next to
the stub executable).
Ah, but the stub has been changed to set an environment variable,
On 7 May 2012 21:55, Martin v. Löwis mar...@v.loewis.de wrote:
This sounds to me like a level of complexity unwarranted by the severity
of the problem, especially when considering the additional burden it
imposes on alternative Python implementations.
OTOH, it *significantly* reduces the
On 05/05/2012 02:38 AM, Vinay Sajip wrote:
Nick Coghlanncoghlanat gmail.com writes:
Personally, I expect that always update your virtual environment
binaries after updating the system Python to a new point release will
itself become a recommended practice when using virtual environments.
On 05/05/2012 04:40 AM, Antoine Pitrou wrote:
On Fri, 04 May 2012 14:49:03 -0600
Carl Meyerc...@oddbird.net wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and
On 05/05/2012 12:41 AM, Nick Coghlan wrote:
On Sat, May 5, 2012 at 6:49 AM, Carl Meyerc...@oddbird.net wrote:
1) Document it and provide a tool for easily upgrading a venv in this
situation. This may be adequate. In practice the situation is quite rare:
2.6.8/2.7.3 is the only actual example
Carl Meyer carl at oddbird.net writes:
them in sync). IOW, if you want real full isolation from a system
Python, you build your own Python, you don't use pyvenv.
For the interpreter you can use your own Python, but you would still use pyvenv,
as the venv is still useful for you to have an
On 5/4/2012 9:39 PM, Terry Reedy wrote:
The gist of my response is that the venv 'tail' should way the python
'dog' as little as possbile.
Yes, that was exactly my thought too. But I'm not sure the technology
permits, with Windows not having exec. On the other hand, one might
speculate
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer c...@oddbird.net wrote:
1) Document it and provide a tool for easily upgrading a venv in this
situation. This may be adequate. In practice the situation is quite rare:
2.6.8/2.7.3 is the only actual example in the history of virtualenv that I'm
aware
Nick Coghlan ncoghlan at gmail.com writes:
Personally, I expect that always update your virtual environment
binaries after updating the system Python to a new point release will
itself become a recommended practice when using virtual environments.
Of course, the venv update tool will need to
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer c...@oddbird.net wrote:
2) In addition to the above, introduce a versioning marker in the standard
library (is there one already?) and have some code somewhere (insert
hand-waving here) check sys.version_info against the stdlib version, and
fail fast
Hi,
On Fri, 04 May 2012 14:49:03 -0600
Carl Meyer c...@oddbird.net wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
Perhaps symlinking could be
Hi all,
The recent virtualenv breakage in Python 2.6.8 and 2.7.3 reveals an
issue that deserves to be explicitly addressed in PEP 405: what happens
when the system Python underlying a venv gets an in-place bugfix
upgrade. If the bugfix includes a simultaneous change to the interpreter
and
On 5/4/2012 4:49 PM, Carl Meyer wrote:
Hi all,
The recent virtualenv breakage in Python 2.6.8 and 2.7.3 reveals an
issue that deserves to be explicitly addressed in PEP 405: what happens
when the system Python underlying a venv gets an in-place bugfix
upgrade. If the bugfix includes a
On 5/4/2012 8:48 PM, Terry Reedy wrote:
CPython is developed, tested, packaged, distributed, and installed as
one unit. It is intended to be run as one package. If something caches
a copy of python.exe, it seems to me that it should check and update
as needed. Could venv check the file date of
On 5/4/2012 11:58 PM, Glenn Linderman wrote:
On 5/4/2012 8:48 PM, Terry Reedy wrote:
CPython is developed, tested, packaged, distributed, and installed as
one unit. It is intended to be run as one package. If something caches
a copy of python.exe, it seems to me that it should check and update
24 matches
Mail list logo
