Broken fromEnvironment
fallback causing issue with monorepo workspaces
#331
Labels
fromEnvironment
fallback causing issue with monorepo workspaces
#331
TL;DR: #184 issue is annoying and doesn't have a convenient workaround for monorepo workspaces with non-Python workspace folders.
I am using this extension with import strategy
fromEnvironment
.I have a monorepo with workspace folders for different Python packages as well as the root folder.
Each Python package folder has a valid interpreter set as
./.venv/bin/python
with installed mypy.I don't want mypy type checking for the root workspace folder because it doesn't have a venv or any Python files associated with it, so I either leave the Python interpreter pointed to a non existent
./.venv/bin/python
or set it to/bin/python
, shouldn't really matter.But this extension tries to start the mypy server for every single workspace folder using the environment mypy, this for the root folder fails because it doesn't have mypy. The extension then tries to fallback to the bundled
mypy
but fails either like #184 when I tried to reproduce it in a new project, or on my monorepo project it fails with:Which seems maybe related to #217.
I also saw that this broken fallback behavior is also mentioned in this comment.
A workaround that I found is if I set the root workspace folder's python environment to some of the other package's .venv interpreter (which have mypy installed), then it works.
But this seems a little bit silly to either set it like that or to have to create a dummy venv with mypy for the root workspace folder (or any non-Python workspace folder).
Monorepo workspaces which have mixed Python and non-Python folders should be a common thing, and I don't see an obvious way to configure and use this extension in that context. Is there a way to disable certain workspace folders to not start mypy servers maybe?
This used to work for me for the previous version of the extension. That is I think it used to just fallback to the bundled mypy for the non-Python workspace folders.
This comment also seems to explain my issue.
The text was updated successfully, but these errors were encountered: