On 8 May 2012 17:14, Carl Meyer 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 underlying Py
Hi Paul,
On 05/07/2012 04:16 PM, Paul Moore wrote:
On 7 May 2012 21:55, "Martin v. Löwis" 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,
Carl Meyer 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, b
On 7 May 2012 21:55, "Martin v. Löwis" 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 burden on P
Ronald Oussoren 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,
__PYTHONV_LAUNCHE
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
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 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
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 t
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 spe
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
Carl Meyer 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 isolated
On 05/05/2012 12:41 AM, Nick Coghlan wrote:
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer 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
On 05/05/2012 04:40 AM, Antoine Pitrou wrote:
On Fri, 04 May 2012 14:49:03 -0600
Carl Meyer 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 s
On 05/05/2012 02:38 AM, Vinay Sajip wrote:
Nick Coghlan 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
Hi,
On Fri, 04 May 2012 14:49:03 -0600
Carl Meyer 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 used at least
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer 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 with an unamb
Nick Coghlan 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 only u
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer 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 of. The disad
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 abo
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
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 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 simultaneo
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 sta
24 matches
Mail list logo
