You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Seeking feedback on a plug-in-like system for environment discovery #6014
I have searched the issues of this repo and believe that this is not a duplicate.
I have searched the documentation and believe that my question is not covered.
Issue
I asked in #5938 for feedback on a potential design to let tools like Poetry to participate in telling tools like VS Code and the Python Launcher for Unix where the virtual environments they manage exist, as well has help in finding Python interpreters. But I realized that directly opening a discussion may not be the workflow you prefer, hence this issue.
This sounds interesting, but I think would require a breaking change in Poetry. Is the idea to have a standard way to interrogate the Poetry binary (or module) about which environments it is responsible for, and which directory prefixes they are associated with?
Is the idea to have a standard way to interrogate the Poetry binary (or module) about which environments it is responsible for
Correct. Right now every tool that manages environments don't have a standardized way to share what environments they have for a certain directory/workspace. This idea is trying to solve that somehow, and in a way that allows users to write the locator if the tool in question hasn't done it or isn't interested.
Are you interested in asking a tool what venv(s) it knows of for a given path, or asking it what venvs it is aware of period (so both paths and venvs as some sort of mutual mapping)?
I guess I'm curious what data model you envision. Something like path: [list, of, venvs] could be supported by Poetry today, for what it is worth.
Also, I think an entrypoint would be the best, most portable way to discover this functionality and call it (with some standardized Protocol describing the function-level interface).
Are you interested in asking a tool what venv(s) it knows of for a given path, or asking it what venvs it is aware of period
The latter. Listing every single environment is not necessarily useful to know as that most likely doesn't apply to the current workspace. But if a tool wanted to list every environment as applicable to a workspace they could do that.
I think an entrypoint would be the best, most portable way to discover this functionality and call it (with some standardized Protocol describing the function-level interface).
I'm trying not to tie this to Python as this could be used by editors who may not be written in Python. Plus, it requires finding the installation of a tool to then find its entry_points.txt file to find out what entry points it defines which may or may not exist (e.g. PyFlow is written entirely in Rust).
It sounds like you were interested in the former of my two options, actually -- some sort of exhaustive mutual mapping that contains all workspaces and environments. It's possible, but only with changes in Poetry as currently we only map workspace path -> environment.
I'm fine with the approach you've outlined with a binary that returns a JSON blob. Do you have any ideas what input parameters might look like?
Activity
neersighted commentedon Sep 30, 2022
This sounds interesting, but I think would require a breaking change in Poetry. Is the idea to have a standard way to interrogate the Poetry binary (or module) about which environments it is responsible for, and which directory prefixes they are associated with?
brettcannon commentedon Sep 30, 2022
Correct. Right now every tool that manages environments don't have a standardized way to share what environments they have for a certain directory/workspace. This idea is trying to solve that somehow, and in a way that allows users to write the locator if the tool in question hasn't done it or isn't interested.
neersighted commentedon Oct 1, 2022
Are you interested in asking a tool what venv(s) it knows of for a given path, or asking it what venvs it is aware of period (so both paths and venvs as some sort of mutual mapping)?
I guess I'm curious what data model you envision. Something like
path: [list, of, venvs]could be supported by Poetry today, for what it is worth.neersighted commentedon Oct 1, 2022
Also, I think an entrypoint would be the best, most portable way to discover this functionality and call it (with some standardized Protocol describing the function-level interface).
brettcannon commentedon Oct 5, 2022
The latter. Listing every single environment is not necessarily useful to know as that most likely doesn't apply to the current workspace. But if a tool wanted to list every environment as applicable to a workspace they could do that.
It's in a link in the Discussion a linked to, but for ease of access it's brettcannon/python-launcher#168 .
I'm trying not to tie this to Python as this could be used by editors who may not be written in Python. Plus, it requires finding the installation of a tool to then find its
entry_points.txtfile to find out what entry points it defines which may or may not exist (e.g. PyFlow is written entirely in Rust).neersighted commentedon Oct 5, 2022
It sounds like you were interested in the former of my two options, actually -- some sort of exhaustive mutual mapping that contains all workspaces and environments. It's possible, but only with changes in Poetry as currently we only map workspace path -> environment.
I'm fine with the approach you've outlined with a binary that returns a JSON blob. Do you have any ideas what input parameters might look like?
brettcannon commentedon Oct 5, 2022
I have outlined some possibilities in brettcannon/python-launcher#168 (comment) .