rules_python
rules_python copied to clipboard
Add a pytest rules
PR Checklist
Please check if your PR fulfills the following requirements:
- [x] Does not include precompiled binaries, eg.
.par
files. See CONTRIBUTING.md for info - [x] Tests for the changes have been added (for bug fixes / features)
- [ ] Docs have been added / updated (for bug fixes / features)
PR Type
What kind of change does this PR introduce?
- [ ] Bugfix
- [x] Feature (please, look at the "Scope of the project" section in the README.md file)
- [ ] Code style update (formatting, local variables)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] Other... Please describe:
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
- [ ] Yes
- [x] No
Other information
Firstly, I would absolutely love to see pytest
support in the stock bazel
rules.
However, one thing that worries me is capturing the invisible dependency between test files and conftest.py
files. Pytest-the-framework will load those to find customizations and fixtures which tests use without a paper-trail. (See pytest's doc).
So if the user is specifying the test, someone (is it them or the framework?) should be declaring those dependencies (conftest.py
all the way up). I would argue the framework should, as it's painfully easy to get wrong from the user's perspective.
The same goes for the test suit rule.
When someone comes back to this, consider adding extra arguments to change how pytest is changing the import path. I did some investigation as to why pytest tests where failing when I was using protobuf rules here: https://github.com/aignas/bazel_pytest_proto
@AutomatedTester are you planning/willing to pick this up again, or would you prefer someone else taking it over?
@everyone else in here: what would be a minimal setup of changes required here to get this merged?
i see the following todo-list:
- address (all) the review-comments
- clear up if we want to implicitly supply a
pytest
and if so how
i would argue we shouldn't aim for adressing all eventualities at first, otherwise this would never get in in any form.
just for clarification: i would be willing to take this over under the condition that there is a willingness for constructive cooperation and eventually compromise.
@AutomatedTester are you planning/willing to pick this up again, or would you prefer someone else taking it over?
Happy for someone to take this over, I haven't had time to do it.
Heads up that https://github.com/bazelbuild/rules_python/pull/723 may supersede this.
This Pull Request has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_python!
This PR was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"
Note, https://docs.aspect.build/rules/aspect_rules_py/docs/rules#py_pytest_main provides missing glue for pytest, thanks to @mattem and @f0rmiga