PEP 832: virtual environment discovery

[brettcannon]

@pf_moore

unless you’re declaring those use cases as unsupported, it needs to. I don’t yet know what that solution will be, but why wouldn’t it also work for projects that do have a pyproject.toml?

It would, but that’s assuming we come up with some solution outside of pyproject.toml that people like.

The best I can think of is based off of Provide structured output for environment/interpreter discovery · brettcannon/python-launcher · Discussion #168 · GitHub and having workflow tools install an entry point with a certain name prefix like how Git plug-ins work (e.g. _py_wsp_<tool name>). The tricky bit with that is it would require asking all workflow tools whether they apply or not to a project on first run. Now, my guess is most people don’t have more than one workflow tool installed at once, so it wouldn’t be a huge concern or performance hit. You could also cache which tool said they should be the one to work with the project (or as a way to override if you manually set the cache). This doesn’t provide a way for a project to explicitly say, “please use this workflow tool” and allow overriding (e.g. committing some .python-wsp file wouldn’t be easy to override). But it’s one possible alternative approach that may avoid pyproject.toml. There’s also may be some combination of discovery via PATH and pyproject.toml that works out. Or environment variables to point at workflow tools locally.

@pf_moore

And too many of the key questions I have aren’t answered, except by a vague “your IDE might let you do this”. Sure it might, but equally it might not

Yep, just like any tool you use.

@pf_moore

But I use multiple tools (tox, nox, VS Code, vim, …) and I also want a tool-agnostic way to say “this is my preferred workflow”, and “please use my preference rather than the project recommendation”.

And yet all of those tools all have their own way of doing things, and I don’t know where they draw the line on what they are okay with us dictating to them for how they operate.

@pf_moore

Wow, that’s way more complex than I’d imagined. I didn’t look up what JSON-RPC involved, I’d assumed it was a “read a line of JSON from stdin, write a line of JSON to stdout, repeat” protocol.

You can if you don’t care about being as robust as the code Cary showed is. The spec is at JSON-RPC 2.0 Specification and as you can see it isn’t very long or complicated.

@pf_moore

you can’t say the PEP supports a use case by assuming that tools implementing the PEP will support that use case without the PEP requiring them to…

I wouldn’t say it supports it as much as wouldn’t prevent it while encouraging tools to support it.

@pf_moore

I’d want to change my vote to a Python protocol.

That’s fair, but I will say the workflow tool authors who voted seemed to prefer the JSON-RPC approach.

@steve.dower

JSON-RPC is really only trivial if you rely on a helper library, which likely means a minimum 3 dependencies

And why supporting inline script metadata would be important.

@pf_moore

At a minimum, I’d want the PEP to say that tools MUST provide a way for the user to disable workflow settings in pyproject.toml.

Do we mandate allowing people to opt out of a setting for any other standard?

@pf_moore

Hmm, saying that I’m assuming this will be a core PEP, not a packaging one. If it’s a packaging PEP, and I’m PEP-delegate, I’ll need to have a re-think, looking at what I think is best from an ecosystem POV, rather than just what I want for my wokflow…

That I don’t know. I expect to remove the changes to the venv module which required needing the SC to be the ones deciding on this PEP. If I move forward with using pyproject.toml then it might get messy as to whose “jurisdiction” the PEP falls under.

---

To try and tie all of this back to the problem I’m trying to solve: how do we make it so tools like VS Code know where any environments exist (if any)? There’s a matrix here (do note that “fancier” support subsumes simpler ones, e.g. WSP can also cover what .python-envs does):

Preference	First time loading the project	Already run workflow tool
Project has a preference	pyproject.toml	.python-envs
User has a preference	VS Code supports it?	.python-envs
No one cares	VS Code’s choice?	.venv

These are the scenarios I’m looking to (potentially) cover. Basically the bootstrapping of a fresh checkout is the “hard” problem to solve here.