Jeff Edwards <j...@edwardsj.com> added the comment: Interesting, I hadn’t realized that it would embed the FQ Executable path, but that does make sense overall. I guess I had always planned on fixing the ‘bin’ directory anyway afterwards, it’s just that the lack of relative home made it significantly harder to encapsulate multiple environments running with the same interpreter without having to do a complete reinstall, and venv did seem like the best and most-pythonic way to do it.
I’ll think about it a bit more On Tue, Jan 28, 2020 at 2:33 PM Eryk Sun <rep...@bugs.python.org> wrote: > > Eryk Sun <eryk...@gmail.com> added the comment: > > > Suffice to say, is there a significant reason to not allow it? > > It's poorly supported by packaging. In particular, relocating an > environment isn't supported with entry-point scripts, which pip installs > with a fully-qualified shebang. Moreover, entry-point scripts in Windows > are created as exe files (e.g. "pip.exe") that embed the fully-qualified > path of python[w].exe in the environment, plus a zipped __main__.py. For > example, given an environment at "C:\Temp\env", running > "C:\Temp\env\Scripts\pip.exe" in turn spawns a child process with the > command line: "C:\Temp\env\Scripts\python.exe" > "C:\Temp\env\Scripts\pip.exe". This breaks if the environment is renamed or > relocated. > > ---------- > nosy: +eryksun > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue39469> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39469> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
