-
-
Notifications
You must be signed in to change notification settings - Fork 45
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
mypy+poetry - using the wrong mypy. #917
Comments
It's just using |
Pardon my ignorance, but why activate? coc-pyright works very hard to use the correct workspace root. Then coc-pyright is correctly automatically using the python from the env without explicitly activating it, based on the workspace root inference.
Seems reasonable to use the mypy inside the venv (or otherwise use a mypy that has knowledge about the venv). Alternately, But I think the better solution is to run mypy through the selected python executable (via something like |
@nipunn1313 If you want to use the Currently, in coc-pyright, each tool for linting and formatting is implemented as command execution rather than module execution. The process of determining whether a tool can be executed as a module in an existing Python environment may vary for each tool and may become complex. Furthermore, |
coc-pyright runs third Python tools, parses results and applies. The key point: how to run third tools. coc-pyright supports sub process execution and module execution. The previous:
This should be what you want, but this solution has another problem: we need to install the tool in every projects, we can't use global tool for projects. In 3d987bc, I've changed to:
The new logic broken the module mode, but with some better use cases:
For your case, you have both global and project-level tool installed, but they're different, you can activate venv first to use it. We can find for a better way to run third tools. |
Thank you for your feedback, coc-pyright did a lot to use the correct Python/tools, to work as correctly as possible. |
Couldn't the logic be something like this? If You could maybe even do that logic during startup and save the absolute path to the binary so you don't have to run a subprocess twice in the global case. |
Great point - thanks for clarifying. Using the mypy in the venv does this automatically, but broadly speaking, if working on a project whose workspace root finds a venv (eg via poetry), setting Is there a way to configure this? Something like this, where coc-pyright fills in the workspace root.
|
@nipunn1313 try v1.1.304. |
Tried it out! Works great! Thanks @fannheyward . |
From command line
I found that coc-pyright is using
mypy
rather than.venv/bin/mypy
, meaning it's not grabbing the venv dependencies when typechecking.Issue is similar, but different from #324
I've set up my workspace root correctly (
:CocList folders
looks good).As you can see here, it's appropriately using
.venv/bin/python
.However, it's using the mypy I have installed globally rather than
.venv/bin/mypy
(or alternately.venv/bin/python -m mypy
.What's the output of
:CocCommand pyright.version
[coc.nvim] coc-pyright 1.1.303 with Pyright 1.1.303
What's the output of
:CocCommand workspace.showOutput Pyright
more relevant is coc-pyright-linting here
Appreciate all the work you do on coc-pyright. It's a good plugin!
The text was updated successfully, but these errors were encountered: