Log filenames when running pytest-mypy #4502
Conversation
Avasam
force-pushed
the
pytest-mypy-log-filename
branch
from
34f1a77 to
6c16a39
Compare
|
@jaraco if this is accepted, should a |
|
I kind-of like the "before" output, given that the filename is given in the header. Adding more details to the output makes it more likely that the most important detail is wrapped or off-screen. Can you tell me more about the motivation for the change? If it's a good practice or a best practice, why wouldn't pytest-mypy apply this behavior by default? I tend to try to align with the defaults from upstream and avoid customizing downstream, except where that customization is essentially needed, or documented by the upstream project as "recommended" boilerplate.
I'd like to avoid adding a conftest.py to the skeleton, because it's an unstructured format and will conflict easily with downstream projects. I'd be much more inclined to implement it as a plugin, such as |
I unironically didn't think to look at the error section header, maybe I was tunnel-visioning hard that day. I think I saw the I do have one functional use that's pretty standard across checker tools that I use: it's convenient to copy
It's a small convenience now that I noticed the header (which I feel silly about not noticing earlier). Although one I still have a preference for.
Given the filename is in the header, I can only assume they figured it's a good enough minimal default and left any additional information to custom formatter. (ie: let users use the generalized customizable system, rather than adding new configurations) |
Avasam
force-pushed
the
pytest-mypy-log-filename
branch
from
45615b7 to
dbae4e9
Compare
There was a problem hiding this comment.
tl;dr: If this behavior would still be useful to Avasam, let's add it (relative option) with a comment for future retirement. Regardless, let's also file an upstream issue with pytest-mypy (or maybe jaraco.test) to allow for opt-in or opt-out of this behavior (unless pytest-mypy is okay making it the new sole practice).
As I think about it more, I'm thinking this change becomes decreasingly useful as mypy issues are addressed, but it will linger as a divergent behavior indefinitely. How about we add a comment linking back to this PR and propose to consider it for removal in six months (e.g. after 2025-04-01)?
If it's a good practice or a best practice, why wouldn't pytest-mypy apply this behavior by default?
I'd feel much better if this behavior could be applied at the pytest-mypy level. If it's useful for Avasam on Setuptools, the same considerations should apply to other users on other projects. Maybe it should be an option that could be enabled with a flag (or maybe default and disabled by a flag). If we're to accept this change, I'd like to have an issue filed with that project to track that consideration.
Another thing to consider that I hadn't though of before - what do other plugins emit? In my experience, pytest itself shows relative paths and coverage shows relative paths.
collected 9 items
docs/conf.py .... [ 44%]
jaraco/compat/py38.py .... [ 88%]
. . [100%]
---------- coverage: platform darwin, python 3.12.5-final-0 ----------
Name Stmts Miss Cover Missing
-----------------------------------------------------
docs/conf.py 9 0 100%
jaraco/compat/py38.py 8 0 100%
-----------------------------------------------------
TOTAL 17 0 100%
Why should only pytest-mypy get the absolute path treatment? I don't think it should.
And indeed, when running native mypy, it emits relative paths:
jaraco.compat main [1] 🐚 mypy .
jaraco/compat/py38.py:36: error: Argument 1 to "startswith" of "str" has incompatible type "int"; expected "str | tuple[str, ...]" [arg-type]
jaraco/compat/py38.py:37: error: Argument 1 to "len" has incompatible type "int"; expected "Sized" [arg-type]
Found 2 errors in 1 file (checked 2 source files)
The more I think about it, the less I like this proposal. I personally prefer not to see absolute paths, because it add so much low-value, redundant context and pushes the crucial detail out to the right (to be invisible or wrapped).
I do have one functional use that's pretty standard across checker tools that I use: it's convenient to copy
setuptools/errors.py:32so my editor's "go to" command can directly go to the right line.
When the test is run in an editor's shell (Vscode, PyCharm) it also allows clicking the link bringing directly to the right line.
I don't see how these use-cases benefit from absolute paths. I'd expect editors to understand paths relative to the project root. Is that not the case? Does it really require an absolute path to open a file or make a hyperlink? In your example, you show the editor creating a hyperlink for a relative path. Is that hyperlink broken? If so, that sounds like a bug in the editor, and fixing it just for Setuptools is not sustainable.
Oh! I see now, there are two options for "after" (relative and absolute). I can see the value for relative paths (and not just line numbers). That sounds like a good feature for a plugin or for the plugin to implement as an option.
|
I agree absolute paths seem like the worst options of the three. I only included it for completeness sake.
Given your project setup for skeleton-based projects, which I'm getting more and more accustomed to, I also agree that the logic for this configuration would better live outside setuptools, with a minimal change to setuptools itself (preferably a config) realpython/pytest-mypy#90 was closed by realpython/pytest-mypy#93 but I don't see any discussion saying that they explicitly wouldn't want to add it as an option. |
|
Converting to draft since the solution should go outside setuptools (either https://github.com/jaraco/jaraco.test, https://github.com/jaraco/jaraco.develop, or https://github.com/realpython/pytest-mypy) |
Summary of changes
Reference: realpython/pytest-mypy#93
(please let me know whether you prefer relative or absolute filepaths)
Before: https://github.com/pypa/setuptools/actions/runs/10030930044/job/27720796247?pr=4352#step:9:66
After (relative path): https://github.com/pypa/setuptools/actions/runs/10030863175/job/27720645004?pr=4352#step:9:67
After (absolute path): https://github.com/pypa/setuptools/actions/runs/10030898174/job/27720720510?pr=4352#step:9:66
Pull Request Checklist
newsfragments/. (not user facing)(See documentation for details)