Auto-detect .venv interpreter when configured path is invalid

[HamzaYslmn]

Summary

This PR improves the interpreter discovery logic to automatically fall back to a .venv directory in the project root if the configured python-interpreter-path is invalid or refers to a non-existent file.

Motivation

Modern Python workflows (using tools like uv, poetry, or standard pip) often create a local .venv directory in the project root by default. Currently, users are often required to explicitly configure the full path to this interpreter in pyproject.toml or [pyrefly.toml]

This change aims to reduce configuration boilerplate by attempting to auto-discover the .venv directory if the initially configured path fails validation. This makes the "out-of-the-box" experience much smoother for standard project layouts.

Changes

• Modified ConfigFile::configure in [crates/pyrefly_config/src/config.rs]
• Added a check: if interpreter.exists() returns false, the config now attempts to find a valid environment using crate::environment::venv::find(root).
• If a valid .venv is found, [pyrefly] automatically switches to using it instead of throwing an error or falling back to a system interpreter.

[meta-cla]

Hi @HamzaYslmn!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[connernilsen]

Hey @HamzaYslmn, thanks for making this!

I'm not sure I fully understand the use case you're trying to address though. Can you walk me through an example setup where you would expect to use this? Have you run into this problem before?

Right now, I'm kind of leaning toward the idea that explicitly configured interpreters are a source of truth, and we generally shouldn't be attempting to fall back to something else automatically, so I think trying to understand your reasoning behind this will help me to decide if this is the right approach, or if something else might work (maybe something like #1662).

Currently, users are often required to explicitly configure the full path to this interpreter in pyproject.toml or pyreflyl.toml

I just want to clarify, there are a lot of cases where this isn't required and should just work 'by default'. Are you seeing issues with this, or do you have a setup incompatible with auto-configuration?

[HamzaYslmn]

@connernilsen

My use case is: when I create projects with uv / pip, the layout is usually (global usage):

pyproject.toml
.venv/ (next to the project)

But Pyrefly can’t automatically detect the interpreter inside that .venv. Because of that, I end up having to add this to every project:

[tool.pyrefly]
python-interpreter-path = ".venv/Scripts/python.exe"

What my PR does is not to override anything. If an interpreter path is explicitly configured, it stays the source of truth. The change only applies when there is no configured path and auto-discovery fails , then it falls back to checking for a local .venv next to pyproject.toml.

So it’s a safe fallback, not a replacement.

Example:

Pyrefly cannot handle such situations. Have to manually configure .venv for every project, which is really tedious. Tools like uv automatically detect pyproject.toml and use the adjacent .venv, but with Pyrefly I still need to add an extra config each time.

[WhoIsMrSentry]

I want to echo that I’m hitting the same problems outlined in this PR. The current behavior has caused confusion and extra overhead in my own workflow, particularly in cases similar to the ones referenced here.

I’ve spent a fair amount of time trying to understand whether the issues were coming from my setup or my code, only to realize they align very closely with what’s being discussed in this change.

From my perspective, this PR targets a real and practical limitation rather than a theoretical edge case. Having this fixed would remove a lot of unnecessary friction when using Pyrefly on larger or more complex projects. Really appreciate the work going into this.