This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author uranusjr
Recipients eric.smith, eryksun, paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
Date 2019-11-25.19:20:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
To provide concrete context, the problem I’m facing is with how Flit resolves `flit install --python`:

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:

    ["pythonX", "-c", "import sys; print(sys.executable)"],

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?
Date User Action Args
2019-11-25 19:20:31uranusjrsetrecipients: + uranusjr, paul.moore, eric.smith, tim.golden, zach.ware, eryksun, steve.dower
2019-11-25 19:20:31uranusjrsetmessageid: <>
2019-11-25 19:20:31uranusjrlinkissue38905 messages
2019-11-25 19:20:30uranusjrcreate