mypy, flycheck, directories and stuff
Update: Retracting both the snark and the advice.
It turns out the
mypy_path = ../foo/ for terrible and obsolete reasons.
This explains the bad behaviour, and goes to show you should minimise the number of terrible things you do.
Ethics! It's good for what ails you.
Just hit a problem getting mypy to work in Emacs.
I have a project with a directory structure like:
/ README.md mypy.ini src/ project/ foo/ bar.py bar/ qux.py
But there's also a top-level third-party package called
bar/qux.py looks like:
import bar from foo.bar import specifics
flycheck will run
mypy from the
src/project/bar/ directory like this:
mypy --show-column-numbers --config-file /Users/jml/src/project/mypy.ini /Users/jml/src/project/src/project/bar/qux.py
But it will yield this error:
../foo/bar.py: error: Source file found twice under different module names: 'project.foo.bar and 'bar'
Which is terrible.
If you run the same command from the top-level directory of the project, everything is fine.
This only seems to be an issue with mypy 0.800. Happily the release notes point to an obvious ~culprit~ fix.
When you use
--namespace-packages, mypy assumes that only the current directory and directories explicitly specified in MYPYPATH (or mypy_path in the config file) are valid package roots.
I honestly don't think we are using namespace packages, but who cares. Shoving those options into the invocation gives a plausible list of type errors, and means I don't have to figure out how to get flycheck to run mypy from the top-level of the project.
mypy --show-column-numbers --namespace-packages --explicit-package-bases --config-file /Users/jml/src/project/mypy.ini /Users/jml/src/project/src/project/bar/qux.py
I'm going to add those to the config file and see what happens.
Have a great weekend, and remember, next time someone tells you Python is easy, be generous, kind, and patient, they have been through an awful lot of suffering to get to that point.