Skip to content

mypy_test: Are exclude and filter useful? #8139

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

Closed
AlexWaygood opened this issue Jun 22, 2022 · 5 comments · Fixed by #8711
Closed

mypy_test: Are exclude and filter useful? #8139

AlexWaygood opened this issue Jun 22, 2022 · 5 comments · Fixed by #8711
Labels
project: infrastructure typeshed build, test, documentation, or distribution related

Comments

@AlexWaygood
Copy link
Member

mypy_test.py has two command-line arguments that I find somewhat useless: filter and exclude. (It looks like they've stayed more-or-less the same since the script's inception 7 years ago.) I'd like to get rid of them and replace them with flags that would allow me to run specific parts of mypy_test locally, instead of running the whole thing at once (e.g. --stdlib to only test the stdlib, or --test-cases to only test the test cases).

Any objections to that?

@AlexWaygood AlexWaygood added the project: infrastructure typeshed build, test, documentation, or distribution related label Jun 22, 2022
@AlexWaygood
Copy link
Member Author

Alternatively, we could have a single command-line argument, --dir. Running only on the stdlib would be --dir stdlib, etc.

@AlexWaygood
Copy link
Member Author

I'm actually somewhat inclined to remove the --verbose and --dry-run options as well. I've never found them useful (but I'm happy to keep them if somebody else has).

@srittau
Copy link
Collaborator

srittau commented Jun 27, 2022

I'm fine with changing exclude and filter. The approach I find most intuitive was to just run mypy_test stdlib/foo.pyi or mypy_test stubs/bar to test a specific file or directory.

--verbose seems useful in case you need the full mypy command line for some reason. --dry-run on the other hand seems mostly useful when developing mypy_test, so I don't think it's very useful in general.

Unrelated: I would prefer not to test our own scripts in mypy_test. Instead we should have a separate step in CI and just manually call mypy. In my view, testing stubs and testing our support script are two unrelated activities.

@AlexWaygood
Copy link
Member Author

AlexWaygood commented Jun 27, 2022

Unrelated: I would prefer not to test our own scripts in mypy_test. Instead we should have a separate step in CI and just manually call mypy. In my view, testing stubs and testing our support script are two unrelated activities.

This makes sense, and @hauntsaninja said something similar to me at PyCon. I'm fine with making this change.

@AlexWaygood
Copy link
Member Author

I'm fine with changing exclude and filter. The approach I find most intuitive was to just run mypy_test stdlib/foo.pyi or mypy_test stubs/bar to test a specific file or directory.

I generally just invoke mypy directly if I want to test just a specific file or subdirectory. I don't think it makes sense to try to reproduce all of the mypy command-line options in mypy_test, so I'd prefer to keep things simple and just remove these options, personally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
project: infrastructure typeshed build, test, documentation, or distribution related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants