Tzu-ping Chung <uranu...@gmail.com> added the comment: To provide concrete context, the problem I’m facing is with how Flit resolves `flit install --python`:
https://github.com/takluyver/flit/blob/7e65ffc7a540d76b96de0df473d3edff6f97c26c/flit/__init__.py#L18-L28 Generally the setup is to install Flit into a globally available location (let’s name it env A), so it’s usable for every project and environment. For a project foo you’d have a virtual environment (env X) that’s created from a base interpreter (env B, which may or may not be the same as env A). So the comment workflow would look like this: > pythonB -m venv project-env > project-env\Scripts\activate.bat (project-env) > pythonA -m flit install --python=pythonX This results in the following subprocess call: subprocess.check_output( ["pythonX", "-c", "import sys; print(sys.executable)"], universal_newlines=True, ).strip() And ideally (pre-3.7.2 Windows, or current POSIX behaviour) this would give you the absolute path to pythonX. But right now on Windows the result is pythonB. So if this is to be determined as acceptable behaviour, we’d need to come up with a suggestion how this code can be rewritten. `shutil.which` could be a direction, but still not enough since it’d break `flit install --python=py` because that’s give you the location of py.exe, not the actual interperter. What else? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38905> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
