You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Python version (& distribution if applicable, e.g., Anaconda): Python 3.9.7 (via mayapy)
Type of virtual environment used (e.g., conda, venv, virtualenv, etc.): Not really using a venv
Operating system (and version): macOS 14.7 (23H124)
Version of tool extension you are using: v2024.0.0
Behaviour
Expected Behavior
The mypy extension should fully respect the config in the pyproject.toml and I should see identical results to what I get when running directly on the cli.
Actual Behavior
I am trying to get mypy in VSCode to ignore maya.* modules. When I run mypy directly via the command line using my pyproject.toml config, it does not raise errors as expected, but when I refresh mypy in VSCode, no matter what I do, it always hightlights error related to the maya.cmds module that I am using in my code.
More info on the maya.* modules: These are made available via Autodesk Maya's utility mayapy, which sets things up to use the maya.* packages that are internal to your Maya installation (previously, this was a shell script, but it appears to be a binary these days). I had previously set VSCode to use mayapy as the interpreter in order to get better auto-completion, but it turned out that is actually what caused a lot of new errors to show up due to how the maya.cmds module is written (it seems the functions only have the "short names" for their params as far as VSCode/mypy are concerned, but the long versions still work and are what I prefer to use e.g. maya.cmds.ls(sl=True) vs maya.cmds.ls(selection=True)).
Oddly, when I change the interpreter that VSCode uses to a different empty venv, it still raises errors that it could not possibly know about unless it followed the imports somehow, but that should not even be possible in an empty venv that does not have any connection to Maya. I'm also curious: is it possible to unset the Python interpreter? That setting doesn't seem to be store in the project's .vscode/settings.
I have tried various other possibilities for the module name/pattern, including maya.cmds, cmds (since I import as that), etc. Unfortunately, nothing works, and it still complains about an error that it could not possibly know about based on the current interpreter selected.
Extra Details
Medium size monorepo
10+ python packages that all use their own pyproject.toml
The text was updated successfully, but these errors were encountered:
@taranlu-houzz Where is your pyproject.toml located in relation to the python files? Would it be possible to share the logs from Output > mypy?
A thing you can try that was recently added is support for ${nearestConfig}. You can set "mypy-type-checker.cwd": "${nearestConfig}" to let the extension find and use the nearest pyproject.toml.
Hi @karthiknadig, this is what the structure of the of the project is:
.
└── src
└── Dev
└── Pipeline
└── Maya
├── icons
├── mel_scripts
├── plugins
├── presets
├── scripts <this dir contains python scripts>
│ └── hz_p3d_tools <this is a package with subpackages/submodules which is where I noticed this issue>
└── shaders
The pyproject.toml is at the top level alongside the src dir. The structure is a little goofy, because this is actually code that gets copied over to an legacy layout in perforce. This is actually a subproject in a larger monorepo.
Thank you for the tip about mypy-type-checker.cwd, I'll have to try that out when I get a chance.
@taranlu-houzz The logs should show which directory was used by mypy. If it is not using the right directory, you can also explicitly set the interpreter to use with mypy and/or you can point it to specific pyproject.toml.
Look at mypy-type-checker.interpreter setting to set a specific interpreter. You can also set mypy-type-checker.args to specific config file. You can make used of system variables like ${workspaceFolder}/pyproject.toml .
Diagnostic Data
mayapy
)Behaviour
Expected Behavior
The
mypy
extension should fully respect the config in thepyproject.toml
and I should see identical results to what I get when running directly on the cli.Actual Behavior
I am trying to get
mypy
in VSCode to ignoremaya.*
modules. When I runmypy
directly via the command line using mypyproject.toml
config, it does not raise errors as expected, but when I refreshmypy
in VSCode, no matter what I do, it always hightlights error related to themaya.cmds
module that I am using in my code.More info on the
maya.*
modules: These are made available via Autodesk Maya's utilitymayapy
, which sets things up to use themaya.*
packages that are internal to your Maya installation (previously, this was a shell script, but it appears to be a binary these days). I had previously set VSCode to usemayapy
as the interpreter in order to get better auto-completion, but it turned out that is actually what caused a lot of new errors to show up due to how themaya.cmds
module is written (it seems the functions only have the "short names" for their params as far as VSCode/mypy are concerned, but the long versions still work and are what I prefer to usee.g. maya.cmds.ls(sl=True) vs maya.cmds.ls(selection=True)
).Oddly, when I change the interpreter that VSCode uses to a different empty venv, it still raises errors that it could not possibly know about unless it followed the imports somehow, but that should not even be possible in an empty venv that does not have any connection to Maya. I'm also curious: is it possible to unset the Python interpreter? That setting doesn't seem to be store in the project's
.vscode/settings
.Reproduction Steps:
This the
mypy
config from mypyproject.toml
:I have tried various other possibilities for the module name/pattern, including
maya.cmds
,cmds
(since I import as that), etc. Unfortunately, nothing works, and it still complains about an error that it could not possibly know about based on the current interpreter selected.Extra Details
pyproject.toml
The text was updated successfully, but these errors were encountered: