This would make e.g. uvx --with Foo ty check script_using_Foo_library.py work as a one-liner. Today it doesn't work. uv creates an ephemeral env with Foo installed, and then invokes ty's Python shim from that env, but ty doesn't care about that. uv doesn't set VIRTUAL_ENV, and the ephemeral env isn't located anywhere ty's searching will find it, so ty never finds the env it was invoked from.

I suspect this would also make things "just work" for a significant number of end-user cases, where they are running ty from the same Python installation their dependencies are installed in, without VIRTUAL_ENV set. (Either because they have a venv and are running its binary directly without shell activation, or because they aren't using a venv at all.)

Uv has specific logic to do this (for itself), see https://github.com/astral-sh/uv/blob/a186fda2d27d74c631c50ffccb9413d31f95cc89/python/uv/__main__.py#L35 and https://github.com/astral-sh/uv/blob/2c54d3929c11fd9b5c8b0235ab201fe9d5501751/crates/uv-python/src/discovery.rs#L487-L493 -- we could borrow this approach.

We would still need to decide where in the priority this would fall. I think it would probably be last in fallback order, after explicit config and .venv and VIRTUAL_ENV.