Seeking feedback on a plug-in-like system for environment discovery

[brettcannon]

• 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.

[neersighted]

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]

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.

[neersighted]

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]

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]

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 guess I'm curious what data model you envision.

It's in a link in the Discussion a linked to, but for ease of access it's brettcannon/python-launcher#168 .

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).

[neersighted]

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]

Do you have any ideas what input parameters might look like?

I have outlined some possibilities in brettcannon/python-launcher#168 (comment) .