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 <report@bugs.python.org> wrote:

>
> Eryk Sun <eryksun@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 <report@bugs.python.org>
> <https://bugs.python.org/issue39469>
> _______________________________________
>