Incorrect baseline matching when using different working directories in same project

[Zeckie]

Describe the problem, ie expected/actual result (if it's not blatantly obvious)

Basedmypy isn't able to handle baseline matching when being run with a different working directory.

C:\myproject>mypy .
Success: no issues found in 1 source file

C:\myproject>cd somepackage

C:\myproject\somepackage>mypy somefile.py
somefile.py:1:5: error: Unsupported operand types for + ("int" and "str")  [operator]
Found 1 error in 1 file (checked 1 source file)

C:\myproject\somepackage>mypy --baseline-file ..\.mypy\baseline.json somefile.py
somefile.py:1:5: error: Unsupported operand types for + ("int" and "str")  [operator]
Found 1 error in 1 file (checked 1 source file)

I expect it to use the same baseline and so have no errors when run from any directory within the same project

Basedmypy version

basedmypy 1.4.1 Based on mypy 0.961

Operating system and version

Windows

[KotlinIsland]

Could you please minify the example. I was able to reproduce the no match situation, but not the error in your output, specifying the folder structure would be good.

myproject\somepackage>mypy --baseline-file ..\..\.mypy\baseline.json somefile.py

Shouldn't this be mypy --baseline-file ..\.mypy\baseline.json somefile.py?

I think this would be a positive change, storing the path relative to the baseline instead of the path relative to the cwd. While being inconsistent with how config options work (relative to the cwd) it would be more desired behavior as the baseline is tied directly to source files.

Downside is that it's a breaking baseline format change, unless we start from the parent folder of the baseline file

Also I think this is a very low priority change as running mypy from the non project root is already quite arduous: >mypy --cache-dir ../../.mypy_cache --config-file ../../pyproject.toml test.py

What use case do you have for this enhancement?

[Zeckie]

Use case would be where it is run by an IDE plugin that doesn't know that it needs to set working directory to the project root (some might set to the directory containing the file, others might even leave it as the working directory of the IDE and pass an absolute path of the file to check).

[KotlinIsland]

It is run by an IDE plugin that doesn't know that it needs to set working directory

Mypy isn't designed to be run from a sub-directory and can return errors warning as such

project/package/subpackage> mypy .
__init__.py:1: error: Cannot find implementation or library stub for module named "parent"  [import]
__init__.py:1: note: You may be running mypy in a subpackage, mypy should be run on the package root
Found 1 error in 1 file (checked 1 source file)

So any wrapper (like an IDE plugin) would be incorrect to do that. This is for multiple reasons:

1. The settings in the config file are applied relative to the cwd, not to the config file
2. config file/cache dir would need to be specified explicitly
3. The module discovery paths would be different

others might even leave it as the working directory of the IDE and pass an absolute path of the file to check

This would again be very incorrect and cause all sorts of false errors, the two Idea plugins for mypy use the project root directory.

It could even be set up as a shell integration, though would need some setup to make the window stay open when it finishes

I don't think registering mypy as an application for running python files is a good idea considering all the points above. Also there would be no way to specify the path to the config/cache/baseline file.

[Zeckie]

I've checked how pydev launches mypy - it uses:

• absolute path to the python file to be checked
• switches such as --show-column-numbers --follow-imports=silent --cache-dir=C:\Users\...
• environment variables such as MYPYPATH and PYTHONPATH (the python path includes project source, libraries, etc)

[KotlinIsland]

Does it set the working directory to be the project root?

[Zeckie]

This error also occurs when using the configuration no_silence_site_packages = true, and there are issues found in a site package.

 File "C:\Users\Zeckie\AppData\Local\Programs\Python\Python310\lib\pathlib.py", line 816, in relative_to
    raise ValueError("{!r} is not in the subpath of {!r}"
ValueError: 'C:\\Users\\Zeckie\\AppData\\Local\\pypoetry\\Cache\\virtualenvs\\myproj-F0-OrpkB-py3.10\\Lib\\site-packages\\pybadges\\__init__.py' is not in the subpath of 'C:\\Users\\Zeckie\\
git\\myproj' OR one path is relative and the other is absolute.

[KotlinIsland]

1.3 has resolved the crash in these scenarios.