Support a way for other tools to assist in environment/interpreter discovery #168
Replies: 43 comments 39 replies
-
Feedback has been provided via https://discuss.python.org/t/what-information-do-you-gather-for-interpreters-and-environments/13468/ from folks involved in editors/IDEs. |
Beta Was this translation helpful? Give feedback.
-
Asked for feedback on Twitter via https://twitter.com/brettsky/status/1491168621900402689?s=20&t=v2lxc5_E1U0zLOnKOkjGEw . |
Beta Was this translation helpful? Give feedback.
-
https://twitter.com/brettsky/status/1491908748129955840 was a poll for potential binary prefix names. Jannis suggested using |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
My current thinking on CLI flags:
A few open questions:
|
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
Instead of a prefix and relying on |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
Request for feedback from pyenv at pyenv/pyenv#2472 . /cc @Darsstar |
Beta Was this translation helpful? Give feedback.
-
Twitter poll at https://twitter.com/brettsky/status/1578101990625710080?s=20&t=JCU0NXB3sEwbBIs9qqT6_g about whether to prefer interpreters with more version details or less (e.g. select |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
To record my thought process on something ... I was considering dropping the |
Beta Was this translation helpful? Give feedback.
-
One thing I'm thinking about is how to display something in a list of interpreters/environments (i.e. Another solution is to introduce something like a |
Beta Was this translation helpful? Give feedback.
-
https://hynek.me/til/python-project-local-venvs/ covers how direnv users do things (from https://mastodon.social/@hynek/109561175719682337). |
Beta Was this translation helpful? Give feedback.
-
How dynamic is the data that would be retrieved? How often do you expect the information for a project to change? Would it make sense to keep the information in a file associated with the project, instead of invoking another program to look it up each time? For example, I could envision a plugin for virtualenvwrapper that updated a file (with a format defined by the launcher) with data each time an env is linked to a project directory via setvirtualenvproject or removed with rmvirtualenv. Then the launcher just needs to read that config file, and long running tools like IDEs could cache the results. |
Beta Was this translation helpful? Give feedback.
-
I brought back the |
Beta Was this translation helpful? Give feedback.
-
Having |
Beta Was this translation helpful? Give feedback.
-
I moved |
Beta Was this translation helpful? Give feedback.
-
The Launcher would look for binaries on
PATH
with an appropriate prefix, like_py_launcher_*
, and call them. These locators would find relevant environments and/or interpreters to help the Launcher makes it decision of what to use.The locators should probably be a bit more generic in what they return than what the Launcher might need so that people who have their own search needs can also use the binaries (for instance, the proposal covers everything that the Python extension for VS Code displays to users to help them select an environment). I also expect that a base crate will be created that will be directly embedded in the Launcher to cover its current semantics around things it already supports. That should make it easier to use the code separately and provide structs and such that other crates could use to make these binaries (and would eventually end up on PyPI).
The expectation is that these locators will provide as much cheap information as possible, but otherwise will prefer speed over completeness. The desire to reuse this work for other purposes than the Launcher means we want locators to provide as much info as they can naturally give quickly. But on the other hand we don't want to ask any locators to have to perform any expensive operations like querying the Python binary just to provide extra info that the user may not even care about. In the cases where a tool using these binaries needs more info, the missing info should be available via a Python code snippet. The provided information should also be enough to run Python interpreter/environment to get the rest of the details, e.g.
-c "import sys; print(sys.version_info)"
.The results from a locator will be returned in JSON format encoded as UTF-8 via stdout for portability. All names are valid Python identifier names.
There is no priority order of executions of binaries. The assumption is most people will at most have one binary on their machine to fit their workflow. This also allows for parallel execution if necessary. Otherwise people can create their own binary if they want to enforce execution order.
Proposed data in the JSON results are:
Beta Was this translation helpful? Give feedback.
All reactions