PEP 832: virtual environment discovery

[brettcannon]

@steve.dower

it’s py or nothing/someone else

That’s what I’m assuming.working towards.

@barry

FWIW, uv already does this, but uv does a lot else too, so some narrowly focused shebang runner that handles 723 metadata and can be configured to do a thing with a local editable, would be very cool. py to me is the natural UX for that.

OT and one thing at a time; I have plans and this is an early step in those plans.

@barry

Now we’re getting somewhere! I alluded to this problem in my original message, but this really does clarify the problem the PEP is trying to solve, be

I can at least add it to the Motivation section explicitly.

@cjames23

I am a maintainer and have problems with PyCharm and VSCode based IDEs not always detecting the correct or even a single hatch environment, if I have this problem then someone using my tool definitely has faced these problems.

And as the person who used to manage the team that handled this for VS Code, I have seen the problems as well. Virtual environments and any tools that create/manage them can both sit at the top of one’s toolchain stack (i.e. running the tools in the terminal) or be one step down/parallel to other tools (i.e. theiir outputs being used by editors), which makes this whoel situation:

1. A pain that plenty of people see.
2. Something everyone has an opinion on how to solve since this touches people’s DX tools.

@steve.dower

Brett can answer definitively, but I would treat a symlink as if it’s the real file/directory (and let the OS figure it out when it appears in paths). So that’s a vote for “work the same as if it was a directory if it’s a link to a directory or the same as a file if it’s a link to a file” - in other words, don’t treat it specially at all.

That’s what I intended, so I will clarify that in the next/first update.