Allow discovery of venv in VIRTUAL_ENV env variable#16853
Allow discovery of venv in VIRTUAL_ENV env variable#16853AlexWaygood merged 10 commits intoastral-sh:mainfrom
Conversation
|
| impl PythonPath { | ||
| pub fn find_virtual_env() -> Option<Self> { | ||
| let virtual_env = std::env::var("VIRTUAL_ENV").ok(); | ||
| if let Some(virtual_env) = virtual_env { | ||
| tracing::debug!("Found virtual environment at {:?}", virtual_env); | ||
| return Some(Self::ActiveEnvironment(SystemPathBuf::from(virtual_env))); | ||
| } | ||
| None | ||
| } | ||
| } |
There was a problem hiding this comment.
Using this approach for when VIRTUAL_ENV is set does make sense to me because we probably want Red Knot to fail if whatever VIRTUAL_ENV is pointing to doesn't turn out to be a virtual env.
I'm not sure if it's the right approach to e.g. support .venv because we then only want to use the folder if it actually is a virtual env.
There was a problem hiding this comment.
I should probably look at this for parity with uv..
There was a problem hiding this comment.
(there's actually not much to review here — uv's discovery is far more complicated and doesn't really seem relevant for this particular change)
|
crates/red_knot_python_semantic/src/module_resolver/resolver.rs
Outdated
Show resolved
Hide resolved
Co-authored-by: Alex Waygood <[email protected]>
Co-authored-by: Alex Waygood <[email protected]>
Co-authored-by: Alex Waygood <[email protected]>
MichaReiser
left a comment
There was a problem hiding this comment.
Nice!
I think we can use SysPrefixPath in more places to avoid having to reduce the number of arguments that need to be routed through the different levels.
|
Could anyone help with testing, I'm unsure about how to go about testing this |
I'm curious if @MichaReiser has any ideas but my best idea here is lots of manual testing:
|
|
An automated CLI test would be great, but it's probably somewhat painful to set up because |
AlexWaygood
left a comment
There was a problem hiding this comment.
I manually tested with both "good" and "broken" virtual environments, and it all looks great. Thank you!
Co-authored-by: Alex Waygood <[email protected]>
* main: (26 commits) Use the common `OperatorPrecedence` for the parser (#16747) [red-knot] Check subtype relation between callable types (#16804) [red-knot] Check whether two callable types are equivalent (#16698) [red-knot] Ban most `Type::Instance` types in type expressions (#16872) Special-case value-expression inference of special form subscriptions (#16877) [syntax-errors] Fix star annotation before Python 3.11 (#16878) Recognize `SyntaxError:` as an error code for ecosystem checks (#16879) [red-knot] add test cases result in false positive errors (#16856) Bump 0.11.1 (#16871) Allow discovery of venv in VIRTUAL_ENV env variable (#16853) Split git pathspecs in change determination onto separate lines (#16869) Use the correct base commit for change determination (#16857) Separate `BitXorOr` into `BitXor` and `BitOr` precedence (#16844) Server: Allow `FixAll` action in presence of version-specific syntax errors (#16848) [`refurb`] Fix starred expressions fix (`FURB161`) (#16550) [`flake8-executable`] Add pytest and uv run to help message for `shebang-missing-python` (`EXE003`) (#16855) Show more precise messages in invalid type expressions (#16850) [`flake8-executables`] Allow `uv run` in shebang line for `shebang-missing-python` (`EXE003`) (#16849) Add `--exit-non-zero-on-format` (#16009) [red-knot] Ban list literals in most contexts in type expressions (#16847) ...
Summary
Fixes astral-sh/ty#171
Allows the cli to find a virtual environment from the VIRTUAL_ENV environment variable if no --python is set
Test Plan
Unsure how to mock a venv to test that this works