-
-
Notifications
You must be signed in to change notification settings - Fork 650
feat(gazelle): generate py_pytest_main __test__ target #2040
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,9 +19,10 @@ import ( | |
| ) | ||
|
|
||
| const ( | ||
| pyBinaryKind = "py_binary" | ||
| pyLibraryKind = "py_library" | ||
| pyTestKind = "py_test" | ||
| pyBinaryKind = "py_binary" | ||
| pyLibraryKind = "py_library" | ||
| pyTestKind = "py_test" | ||
| pyTestMainKind = "py_pytest_main" | ||
| ) | ||
|
|
||
| // Kinds returns a map that maps rule names (kinds) and information on how to | ||
|
|
@@ -79,6 +80,9 @@ var pyKinds = map[string]rule.KindInfo{ | |
| "deps": true, | ||
| }, | ||
| }, | ||
| pyTestMainKind: { | ||
| MatchAny: true, | ||
| }, | ||
| } | ||
|
|
||
| // Loads returns .bzl files and symbols they define. Every rule generated by | ||
|
|
@@ -97,4 +101,10 @@ var pyLoads = []rule.LoadInfo{ | |
| pyTestKind, | ||
| }, | ||
| }, | ||
| { | ||
| Name: "@aspect_rules_py//py:defs.bzl", | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similarly to how we discussed the gazelle plugin being agnostic to the rule sets, it would be good to have a solution for pytest that is not specific to any specific python ruleset. Having rules_py specific logic in a rules_python gazelle plugin sounds like our abstractions within the bazel python ecosystem are not working well enough. We had a similar discussion about rules_pycross and rules_python targets having different naming conventions and decided to make the plugin configurable, but in this case this is overstepping that boundary and starts tailoring the gazelle plugin to very specific implementation logic. Are there different ways to achieve the same thing?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could put the plugin logic in rules_py itself, and then teach users how to compile a gazelle binary that has the plugins listed in the right order. I don't think we want to grow a Go dev-dependency if we can help it though.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can make this file a template and allow users to pass extra stuff.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am concerned that adding this special one off for I liked the solution that @linzhp proposed in #2044. It does not add extra test framework specific concepts to the gazelle plugin and it would work with We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a We might do something more novice-friendly specifically in Aspect CLI. |
||
| Symbols: []string{ | ||
| pyTestMainKind, | ||
| }, | ||
| }, | ||
| } | ||
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.
This will make Gazelle generate a pytest main target and multiple py_test targets at the same time on the first run, and then generate another py_test target with the
mainpointing to the__test__target in the second run. People will have to run Gazelle twice to reach a stable state. At this state, every test file will be consumed by twopy_testtargets, sobazel test //some:allwill execute all tests twice.