Could not find import of `dependency`, looked in these locations (from config in `/project/pyproject.toml`)

[dxvidparham]

Describe the Bug

Description: After installing and configuring Pyrefly in a Poetry-managed Python project (installed VS Code extension and package via poetry add -dev pyrefly"), I noticed that it fails to resolve imports for several installed dependencies such as yaml, loguru, numpy, and cv2. These packages are installed and available in the Poetry environment, and my code runs without issues. However, Pyrefly reports them as missing.

Reproduction steps:

1. Install Pyrefly and configure it in a Poetry project with the following structure:

   project/
   ├── pyproject.toml
   ├── poetry.lock
   ├── src/
   │   └── my_module/
   │       └── ...
   

2. Run poetry run pyrefly check

3. Observe unresolved import errors for packages that are available in the venv

Example error:

Could not find import of `yaml`, looked in these locations (from config in `/Users/username/Development/company/cbm-sorty/pyproject.toml`):
  Search path (from config file): ["/Users/username/Development/company/project/src"]
  Import root (inferred from project layout): "/Users/username/Development/company/project/src"
  Site package path (queried from interpreter at `/Users/username/.pyenv/shims/python3`): ["/Users/username/Development/company/project", "/Users/username/Development/company/project/export", "/Users/username/.pyenv/versions/3.11.9/lib/python3.11", "/Users/username/.pyenv/versions/3.11.9/lib/python3.11/lib-dynload", "/Users/username/.pyenv/versions/3.11.9/lib/python3.11/site-packages", "/Users/username/Library/Caches/pypoetry/virtualenvs/project-q0J9i8Xa-py3.11"]

pyproject.toml snippet:

# Pyrefly header
[tool.pyrefly]

#### configuring what to type check and where to import from
project_includes = ["src"]
project_excludes = ["**/.[!/.]*", "**/tests"]
search_path = ["src"]
site_package_path = ["/Users/username/Library/Caches/pypoetry/virtualenvs/project-q0J9i8Xa-py3.11"]

Expected behavior: Pyrefly should be able to detect and resolve all installed dependencies from the active Poetry environment.

Actual behavior: It reports unresolved imports for packages that are present and functional when running the project code.

Environment:

• OS: macOS
• Python: 3.11 (managed with pyenv)
• Poetry: Yes
• IDE: VS Code
• Pyrefly version: 0.15.2

Additional context:

• Poetry's virtual environment is located at: /Users/username/Library/Caches/pypoetry/virtualenvs/cbm-sorty-q0J9i8Xa-py3.11
• Interpreter is set correctly in VS Code and matches Poetry's venv
• Running poetry run python -c "import yaml, loguru, numpy" works without errors

Would appreciate any guidance on resolving this or confirming if it’s a configuration issue or a bug.

Sandbox Link

No response

(Only applicable for extension issues) IDE Information

No response

[connernilsen]

Hey @dxvidparham, thanks for reporting this!

I have it on my list to support Poetry in environment auto configuration, but haven't made it around to that yet. Hopefully soon you'll be able to do this without explicitly setting your site_package_path. https://github.com/facebook/pyrefly/issues/166

For resolving your issue, what's in the /Users/username/Library/Caches/pypoetry/virtualenvs/cbm-sorty-q0J9i8Xa-py3.11 directory? Is it a list of packages that are importable, or is it the root of a virtual env (e.g. has a structure like below)

/Users/username/Library/Caches/pypoetry/virtualenvs/cbm-sorty-q0J9i8Xa-py3.11/
├── bin/...
├── include/...
├── lib/...
├── pyvenv.cfg

Also, when running poetry run pyrefly ..., do you know if Poetry prefixes its virtual env interpreter to the $PATH Pyrefly is executed with? If so, then you might be able to get by without specifying the site_package_path and letting our auto configuration logic handle figuring it out.

[dxvidparham]

Thanks for addressing this! I've attached the requested directory structure for your reference. TY has incorporated the use of the VIRTUAL_ENV environment variable in their search strategy, which is overwritten or utilized by Poetry environments. This might be another avenue worth exploring:

echo $VIRTUAL_ENV
/Users/username/Library/Caches/pypoetry/virtualenvs/project-q0J9i8Xa-py3.11

As for your second question, to the best of my knowledge, Poetry behaves like a standard virtual environment. This means it temporarily prepends the bin/ folder from the virtual environments directory to the $PATH for the duration of the shell session. This can happen either with a single command using poetry run python ... or by starting a temporary Poetry shell with poetry shell.

---

Let me know if you need any further details I can provide.

[dxvidparham]

I reinstalled Pyrefly today to give it another try, and it appears to be working now. I'm not sure if something has changed since, or if the fact that I didn’t configure anything in pyproject.toml actually helped.

[komodovaran]

I must admit I can't figure it out either, whereas I have a big project working well with Mypy. Here's a minimal setup:

# some_file.py
from src.lib.libfile import foo

print(foo(a=1, b="2")) # Type error here

# libfile.py
def foo(a: int, b: int) -> int:
    return a + b

# pyproject.toml
[tool.pyrefly]
search_path = ["src"]
site_package_path = ["/opt/venvs/uvprod/lib/python3.12/site-packages"]

This works with python -m src.some_file (important sanity check!).

But pyrefly says:

(uvprod) jt-mbp:testproject johannes$ uvx pyrefly check src/
ERROR /Users/johannes/Documents/Code/testproject/src/some_file.py:1:1-32: Could not find import of `src.lib.libfile`, looked in these locations (from config in `/Users/johannes/Documents/Code/testproject/pyproject.toml`):
  Search path (from config file): ["/Users/johannes/Documents/Code/testproject/src"]
  Import root (inferred from project layout): "/Users/johannes/Documents/Code/testproject/src"
  Site package path (from config file): ["/opt/venvs/uvprod/lib/python3.12/site-packages"] [import-error]

It even claims that Import root (inferred from project layout): "/Users/johannes/Documents/Code/testproject/src" which should clear my misunderstanding of the pyproject.toml configuration, but clearly that isn't the case.

[connernilsen]

Hey @dxvidparham, sorry for the late reply, I was out for a lot of last week and catching up this week.

Yeah, the site_package_path your provided looks wrong for what Pyrefly needs. If you want to manually specify it, it would need to be $VIRTUAL_ENV/lib/python3.11/site-packages instead of just $VIRTUAL_ENV. If you run python -c "import site; print(site.getsitepackages())", you should see that .../lib/python3.11/... entry somewhere in there.

After what you said about how Poetry works, I think the reason removing it from your config worked is because the sourced environment's python executable points to your Poetry env's interpreter, which Pyrefly can query directly for the correct site package path.

Hope this helps, and let me know if you have other questions!

[connernilsen]

Hey @komodovaran, thanks for posting your issue!

The problem here is that if the import root is src, so you should actually be importing from there with from lib.libfile import foo, not src.lib.libfile.

Also, we recently added functionality to automatically use a src directory immediately under your project root as an import root (search_path entry), so you shouldn't have to specify search_path = ["src"] anymore if you don't want to!

Let me know if you have other questions!

[dxvidparham]

Hey @dxvidparham, sorry for the late reply, I was out for a lot of last week and catching up this week.

Yeah, the site_package_path your provided looks wrong for what Pyrefly needs. If you want to manually specify it, it would need to be $VIRTUAL_ENV/lib/python3.11/site-packages instead of just $VIRTUAL_ENV. If you run python -c "import site; print(site.getsitepackages())", you should see that .../lib/python3.11/... entry somewhere in there.

After what you said about how Poetry works, I think the reason removing it from your config worked is because the sourced environment's python executable points to your Poetry env's interpreter, which Pyrefly can query directly for the correct site package path.

Hope this helps, and let me know if you have other questions!

Thank you for helping clarify the root of the issue. You were absolutely right—the output of python -c "import site; print(site.getsitepackages())" revealed a different path than I had previously seen. With that insight, I was able to get Prefly working either by omitting the site_package_path entirely or by specifying the path returned by the command above.

[connernilsen]

Glad you were able to get it working! Please let us know if you have other issues.

[alan-isaac]

Possibly related ... Should pyrefly recognize the availability of globally installed packages? E.g., I installed matplotlib with pip in Python 3.13, and I'm writing some scripts without using a virtual environment. But pyrefly does not see it: "Could not find import of matplotlib [import-error]".

[yangdanny97]

I would expect global installations to part of the site package paths, and for pyrefly to be able to find it. The error should list which paths it looked in - could you share that, as well as which location you installed matplotlib to?

[alan-isaac]

@yangdanny97 Thank you for your interest! To answer your question: pyrefly started in my script directory and then backed up one level at a time until the root directory. It never looks anywhere else.

Background: I used pip for installation, and afterwards pip list does show pyrefly. However, pyrefly cannot be imported! Presumably this is the underlying problem: pip install firefly is not producing an importable module. Furthermore, Windows does not have which, which pyrefly apparently uses to search for a default Python. In the end, pyrefly init does not include an interpreter in pyrefly.toml and does not know how to find one. So I added python-interpreter to pyrefly.toml by hand, and now pyrefly correctly uses its site-packages.

tldr: I think there is an installation bug of some sort? The problem can be fixed by hand.

[yangdanny97]

Pyrefly not being importable from pip sounds like what we're tracking in https://github.com/facebook/pyrefly/issues/653

I'm glad you were able to get this working with some manual tweaks! But let's see if we can get things working out of the box for others

What would be the windows equivalent to which?

[connernilsen]

The which library we use should work for windows as well. Also, I'm pretty sure pyrefly init should not add an interpreter to the config unless we're migrating from another type checker that includes an explicit interpreter override. The assumption here is that if we're able to find an interpreter at migration time, that interpreter will likely continue to be available for future runs, and explicitly specifying an interpreter makes the config incompatible with almost every other environment.

@alan-isaac can you remove the interpreter from your config and run pyrefly dump-config for us? I'm curious to see what your site package path (which should contain the global installations) and interpreter we find are.

Also, if you're using venv or conda, please make sure it's sourced when your run the command.

[alan-isaac]

@yangdanny97 Yes, a fix to #653 is really what I need.

To your question: In principle, you can call where.exe py on Windows PowerShell, but this assumes that the Python Launcher is installed.

[alan-isaac]

@connernilsen To your question: "While finding Python interpreter.: Python environment (version, platform, or site-package-path) has value unset, but no Python interpreter could be found to query for values. Falling back to Pyrefly defaults for missing values. Configuration at ...\pyrefly.toml Using interpreter: <none found successfully>"

I'm purely guessing, but I suspect this turns on the following: I use the Python Launcher, which does not set a global interpreter. This is why I would (after a pip install) prefer to py -m pyrefly check, but that is not currently possible. (Contrast with ruff.)

However, as noted above, where.exe py does find the launcher (py.exe).

I am happy to answer more questions, with the understanding that I am already ok with my current solution. Thanks!

[connernilsen]

Oh interesting, I wasn't aware of py/py.exe as a Windows launcher, so I didn't include that in the search for an executable. Quick question, if you run py -3.13 -c "import sys; print(sys.path)", does that run correctly? If not, is there another way to specify a command to run in Python through the interpreter?

[alan-isaac]

@connernilsen Sure; yes. If that did not work, things would be broken indeed!

[yangdanny97]

@alan-isaac #653 is done and will be included in the next release

[connernilsen]

@yangdanny97 I'm actually not sure that will fix the problem here. @alan-isaac can you open a new issue for this and tag me on it? I have a possible solution, but I might need you to test it out since I don't have a Windows laptop I can use right now