-
Notifications
You must be signed in to change notification settings - Fork 768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import could not be resolved
with [tool.setuptools.package-dir]
#5894
Comments
I believe you are hitting this issue (https://microsoft.github.io/pyright/#/import-resolution?id=editable-installs) unfortunately, currently we don't support the new dynamic setup behavior. you need to install using old legacy mode following legacy structure. |
I don't know much about what goes on under the hood with Pylance/Pyright/ In my example above, I was able to make Pylance work correctly by changing the location of my source file and removing |
Is there a way I can check whether the editable install is using .pth files that contain file paths rather than executable lines? If so I can check in both of the cases I described in the original issue and see if this is indeed the case |
I think this is the documentation for .pth on python.org When investigating similar issues, that's where I've seen them. |
@heejaechang you are correct! The In the first case, with
In this second case, with
So you're right, this does change whether the |
It's not clear to me why specifying |
it is related to https://peps.python.org/pep-0660/ as @debonte labeled this issue. Basically, problem of the approach is that something needs to run that script to find out where the source of editable install package is, and most of static analysis tools don't run (including us) random code (since tool can't trust what that install script would do) and there is no guarantee that env is set up properly to run the script for the analysis tool and etc. due to those various reasons, we don't support pep660 way of editable install. but only legacy ... about this,
this probably works because we discover them not as if you have your package in ... that said, underneath, all the legacy mode does for us is adding the path in the if you don't want to deal with if you set otherwise, the hope this helps. |
It would be nice if this could be fixed properly. Especially with people starting to use the much faster |
@ThiefMaster I will tag some people @debonte @luabud but I doubt it will be supported in static analysis tool anytime soon. I don't think other tools such as mypy support it for the same reason. |
related issue #3473 |
@ThiefMaster correct me if I'm wrong, but the impression I got from @heejaechang is that this is really an issue with other tools/standards, EG PEP660, |
Sure, ideally it'll eventually be fixed in the standard, but this isn't a battle that should be fought on the backs of the users/developers who just want to use good tooling (e.g. |
Pylance is built on top of the pyright type checker. Pyright is a standards-compliant type checker. The way to address this issue is to fix the Python standards so PEP 660 is compatible with static analysis tools and vice versa. The pylance issue tracker is not the right place to discuss this, so you're unlikely to make any headway here. If you would like to propose a standard way to make this work across the ecosystem (all packaging tools and static analysis tools), you can start a discussion in the Python forums. This issue spans both typing and packaging, so you could post in either and then cross-post to the other. This will ultimately require a PEP, but a public discussion in the appropriate forum is a good place to start. |
Fair enough, I just commented on what I believe is the corresponding issue on the pyright repo: microsoft/pyright#3880 (comment) And sure, coming up with a proper solution backed by a PEP is clearly the desired long-term solution. But why not be pragmatic and have a way that fixes an obvious problem pretty quickly, instead of waiting for a process that's certainly going to last many months if not over a year... |
Short-term hacks that work in some cases and for some combinations of tools is not the right answer here. Any solution to this problem will require a well-defined and sound design. If you think you have such a proposal and others in the community agree with your approach, you should be able to get to a draft PEP pretty quickly. Once there's a draft PEP that looks like it's likely to be accepted, I can implement provisional support for it in pyright. |
is there any update on this? |
As Eric mentioned above, this is an issue that needs to be resolved at the standards level and we have no intention to hack around the problem in Pyright or Pylance. Closing this issue as it's not actionable. |
Environment data
Repro Steps
I have this
pyproject.toml
:And this Python code in
src/__init__.py
:I install with
python -m pip install -e .
, then in a Python script:And I get the expected output
<function square at 0x7975b5123760> 9 27
, BUT I getImport "constructions" could not be resolved Pylance
in VS Code and warning squiggles:If I delete
[tool.setuptools.package-dir] constructions = "src"
frompyproject.toml
and movesrc/__init__.py
tosrc/constructions/__init__.py
and rerunpython -m pip install -e .
, and rerun the Python script, I get the same output, but now the Pylance message and warning squiggle is removed.The issue
The Python module works as expected in both cases, but PyLance is not working in the first case
src/__init__.py
, only in the second casesrc/constructions/__init__.py
.I would prefer to use the first case, so I don't need the extra unnecessary directory in the repository structure, but in this case PyLance doesn't work, and I expect that it should work, because the Python code itself works fine.
The text was updated successfully, but these errors were encountered: