Replies: 2 comments
-
Performance and semantics. Remember that all parent directories are also searched for virtual environments, so it's every directory from the current directory up which increases the search space. And you can't short-circuit the search as you would need to search at least the first directory with some virtual environment defined. It also makes it less error-prone to accidentally select a virtual environment when there's a very specific naming convention being followed versus some file in a directory. It also helps normalize the virtual environment name so there's less confusion in documentation, tooling, etc. between all the various names people come up with which are purely subjective preference. Plus the leading dot hides the directory from tools that ignore searching into dot-leading directories (e.g. ripgrep, VS Code, etc.).
I did a poll on Twitter and no name came out with a majority.
PEP 582 is still a draft PEP, so I would prefer to hold off on supporting it until it's accepted (if ever).
I have seen it many times and is common enough for it to be a concern. |
Beta Was this translation helpful? Give feedback.
-
|
I believe #168 will solve this. |
Beta Was this translation helpful? Give feedback.
-
Maybe there's a good reason for limiting virtualenvs to
.venvI'm missing. But I feel like it would be more flexible to use a glob like*/pyvenv.cfgto support other common(?) virtualenv names likevenvandenv. At least common in my experience 🤷♂️ Or something like__pypackages__as outlined by PEP 582I suppose if you had multiple virtualenvs in the same folder the behaviour might be a bit undefined. But that sounds like fair compromise. I can't imagine that being a very common case. There's Tox I guess, but it creates virtualenvs two levels deep so the glob wouldn't catch them anyway.
Beta Was this translation helpful? Give feedback.
All reactions