-
Notifications
You must be signed in to change notification settings - Fork 8
Improve how mypy is run
#128
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
Conversation
|
First commit has a weird phrasing "Most options can be specified in the pyproject.toml file and this have some advantages." |
| "mypy == 1.5.1", | ||
| "types-setuptools >= 67.6.0, < 68", # Should match the global dependency | ||
| "types-setuptools == 68.1.0.0", # Should match the build dependency | ||
| "types-Markdown == 3.4.2.10", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this updated when the mypy version changes? Like, who keeps it in sync? Dependabot would just pick the latest versions no? And if those don't match what mypy deps need?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mypy is not in charge of these dependencies, they usually need to match the python package, like types-markdown should have the sameish version as the markdown package that we are using.
We are actually not pinning transitional dependencies, which at some point could be problematic (this is a problem to think about in the future, there are many optional package managers that take care of this, like pipenv). For example, in this case we don't depend directly on the markdown package, so it is a bit strange that we need the stub.
All that mypy does is somehow looking for packages without type info and look for them in https://github.com/python/typeshed to see if there is a stub package providing it and then installing that via pip.
|
two comments, otherwise LGTM |
|
Rephrased the commit, squashed the fixup commits and added a few more commits, most notably release notes and the |
|
Not tested in frequenz-floss/frequenz-sdk-python#587 anymore because all the |
|
The fix for |
b7de292 to
ac96b0b
Compare
|
New PR for testing this: frequenz-floss/frequenz-sdk-python#620 |
|
The test PR seems to be working well, so this is ready for the final review and merge (and release). |
|
Enabling auto-merge. |
This new release will not require a function `yield`ing `None` to have a `Yields:` section. Signed-off-by: Leandro Lucarella <[email protected]>
Flake8 is faster, so we prefer it. Signed-off-by: Leandro Lucarella <[email protected]>
We want to run the checks from the fatests to the slowest, so we get errors as early as possible. Signed-off-by: Leandro Lucarella <[email protected]>
It is possible to define most options within the `pyproject.toml` file, which offers several advantages: the tool can be used from the command line directly (bypassing the need for `nox`), without having to remember the options. It also facilitates other integrations that need to invoke mypy directly. Signed-off-by: Leandro Lucarella <[email protected]>
`mypy` tends to have issues with checking source files inside a `src/` directory. There are tricks[1] but it seems like the only way to do it is to run `mypy` on `.` using `MYPYPATH=src`, which will still check the whole `.` directory (include whole virtualenvs if there are any), which is not what we want. For now we've been using `-p` to check for packages instead of files, which seemed to have done the trick, but we need to pass directories that don't really have a package structure (like benchmarks or examples or tests) as packages, which is also not great. This commit tries a different approach, we check the source code as a package separately, and then check the development files (tests, examples, etc.), which are passed as simple paths. This also opens up the door to using more relaxed rules for these development files if needed in the future. To achieve this we also move the `packages` specification to the `pyproject.toml` file, so now `mypy` can be called without any arguments to check the source code package, making it easier to call it without relaying in `nox`. [1] https://mypy.readthedocs.io/en/stable/running_mypy.html#mapping-file-paths-to-modules Signed-off-by: Leandro Lucarella <[email protected]>
This was used by the `mypy` `nox` session. Signed-off-by: Leandro Lucarella <[email protected]>
Signed-off-by: Leandro Lucarella <[email protected]>
When installing stubs automatically with `mypy` we can't pin the dependencies, and we make it harder to just run `mypy` without going through `nox`. From now on, dependencies must be explicitly declared in the `pyproject.toml` file, in the optional `dev-mypy` dependencies. Signed-off-by: Leandro Lucarella <[email protected]>
This option avoids using a cache. It is slower but prevents some issues with `mypy` giving different results on different runs (typically complaining about some `type: ignore[issue]` not being used but when removing it complaining about an `issue` again. It is included so it has more visibility to users in the hope that they can spend less time debugging if they hit this `mypy` issue. Signed-off-by: Leandro Lucarella <[email protected]>
Signed-off-by: Leandro Lucarella <[email protected]>
This is to prepare for the release. Signed-off-by: Leandro Lucarella <[email protected]>
Signed-off-by: Leandro Lucarella <[email protected]>
This PR mainly split
mypycheck for the source package and dev files.mypytends to have issues with checking source files inside asrc/directory. There are tricks1 but it seems like the only way to do it is to runmypyon.usingMYPYPATH=src, which will still check the whole.directory (include whole virtualenvs if there are any), which is not what we want. For now we've been using-pto check for packages instead of files, which seemed to have done the trick, but we need to pass directories that don't really have a package structure (like benchmarks or examples or tests) as packages, which is also not great.We try a different approach, we check the source code as a package separately, and then check the development files (tests, examples, etc.), which are passed as simple paths. This also opens up the door to using more relaxed rules for these development files if needed in the future.
To achieve this we also move the
packagesspecification to thepyproject.tomlfile, so nowmypycan be called without any arguments to check the source code package, making it easier to call it without relaying innox.We also move all the options to the
pyproject.tomlfile, somypycan be run consistently also outside ofnox, and the stub dependencies now need to be specified manually in thepyproject.tomlfile, so they can be pinned.This is also a step towards removing
nox(#71).Footnotes
https://mypy.readthedocs.io/en/stable/running_mypy.html#mapping-file-paths-to-modules ↩