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 solution to me. PEP 405 specifies that bin/python3 >> exists, but not that it is the actual Python interpreter binary that is >> normally used. For each target system, a solution should be defined that >> allows in-place updates of Python that also update all venvs >> automatically. > > I propose that for Windows, that solution is to have a new enough > version of Windows and the necessary privileges, and use the --symlink > option to the pyvenv script, or else to manually update venvs using > pyvenv --upgrade. Sounds fine to me as well. >> For example, for Windows, it would be sufficient to just have the >> executable in bin/, as the update will only affect pythonXY.dll. >> That executable may be different from the regular python.exe, and >> it might be necessary that it locates its Python installation first. > > 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 Python end users, for whom creation of a venv under a privileged account is a significant hassle. This being free software, anybody needs to scratch her own itches, of course. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4