feat(gazelle): generate py_pytest_main test target#2040

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

linzhp · 2024-07-05T20:30:02Z

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 main pointing 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 two py_test targets, so bazel test //some:all will execute all tests twice.

aignas · 2024-07-06T11:09:47Z

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?

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.

We can make this file a template and allow users to pass extra stuff.

I am concerned that adding this special one off for py_pytest_main we are not making orthogonal rulesets that are easy to compose and will require continuous maintenance to tweak things. Since there are other test frameworks (like behave, robot, etc), catering for test frameworks in the gazelle plugin means that we are willing to accept contributions for all, hence I think that solving this differently would be better.
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 pytest_main if the users are willing to define a macro and use it, so whilst that may require users to write more code, it does mean that the rules_python project stays better scoped.
We have a maintainers meeting every Monday evening US time and we could discuss it there next week if one of you joined?

A modestly sophisticated user can discover the pattern suggested in #2044 to copy-paste a macro into their codebase and configure a # map_kind directive. I think that's good enough for the use cases that gazelle is trying to address.
We might do something more novice-friendly specifically in Aspect CLI.

-Original file line number
+Diff line change
@@ Expand Up @@
 	actualPyBinaryKind := GetActualKindName(pyBinaryKind, args)
 	actualPyLibraryKind := GetActualKindName(pyLibraryKind, args)
 	actualPyTestKind := GetActualKindName(pyTestKind, args)
+	actualPyTestMainKind := GetActualKindName(pyTestMainKind, args)
 	pythonProjectRoot := cfg.PythonProjectRoot()
@@ Expand DownExpand Up @@
  result.Imports = append(result.Imports, pyTest.PrivateAttr(config.GazelleImportsKey))
 	}
+	if len(pyTestTargets) > 0 {
+ if m := cfg.GetGazelleManifest(); m != nil {
+ pipName := m.PipDepsRepositoryName
+ if m.PipRepository != nil {
+ pipName = m.PipRepository.Name
+ }
+ pyPyTestMain := createPyTestMainTarget(pipName)
+ // Check if a target with the same name we are generating already
+ // exists, and if it is of a different kind from the one we are
+ // generating. If so, we have to throw an error since Gazelle won't
+ // generate it correctly.
+ if err := ensureNoCollision(args.File, pyPyTestMain.Name(), actualPyTestMainKind); err != nil {
+ fqTarget := label.New("", args.Rel, pyPyTestMain.Name())
+ err := fmt.Errorf("failed to generate target %q of kind %q: %w. "+
+ "Use the '# gazelle:%s' directive to change the naming convention.",
+ fqTarget.String(), actualPyTestMainKind, err, pythonconfig.TestNamingConvention)
+ collisionErrors.Add(err)
+ }
+ result.Gen = append(result.Gen, pyPyTestMain)
+ result.Imports = append(result.Imports, pyPyTestMain.PrivateAttr(config.GazelleImportsKey))
+ }
+	}
 	if !collisionErrors.Empty() {
  it := collisionErrors.Iterator()
  for it.Next() {
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -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
@@ Expand DownExpand Up / @@ -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
@@ Expand All / @@ -97,4 +101,10 @@ var pyLoads = []rule.LoadInfo{ @@
  pyTestKind,
  },
 	},
+	{
+ Name: "@aspect_rules_py//py:defs.bzl",
+ Symbols: []string{
+ pyTestMainKind,
+ },
+	},
 }

-Original file line number
+Diff line change
@@ Expand Up / @@ -15,11 +15,13 @@ @@
 package python
 import (
+	"path/filepath"
 	"github.com/bazelbuild/bazel-gazelle/config"
+	"github.com/bazelbuild/bazel-gazelle/label"
 	"github.com/bazelbuild/bazel-gazelle/rule"
 	"github.com/emirpasic/gods/sets/treeset"
 	godsutils "github.com/emirpasic/gods/utils"
-	"path/filepath"
 )
 // targetBuilder builds targets to be generated by Gazelle.
@@ Expand DownExpand Up / @@ -171,3 +173,13 @@ func (t *targetBuilder) build() *rule.Rule { @@
 	r.SetPrivateAttr(resolvedDepsKey, t.resolvedDeps)
 	return r
 }
+func createPyTestMainTarget(pipName string) *rule.Rule {
+	resolvedDeps := treeset.NewWith(godsutils.StringComparator)
+	resolvedDeps.Add(label.New(pipName, "pytest", "pytest").String())
+	r := rule.NewRule(pyTestMainKind, "__test__")
+	r.SetPrivateAttr(resolvedDepsKey, resolvedDeps)
+	r.SetPrivateAttr(config.GazelleImportsKey, treeset.NewWith(moduleComparator))
+	return r
+}

-Original file line number
+Diff line change
@@ -1,4 +1,5 @@
 load("@rules_python//python:defs.bzl", "py_binary", "py_library", "py_test")
+load("@aspect_rules_py//py:defs.bzl", "py_pytest_main")
 # gazelle:python_generation_mode file
@@ Expand DownExpand Up / @@ -51,3 +52,8 @@ py_test( @@
  "//checking/py_test/works:too",
  ],
 )
+py_pytest_main(
+ name = "__test__",
+ deps = ["@gazelle_python_test//pytest"],
+)

-Original file line number
+Diff line change
@@ -1,4 +1,5 @@
 load("@rules_python//python:defs.bzl", "py_library", "py_test")
+load("@aspect_rules_py//py:defs.bzl", "py_pytest_main")
 # gazelle:python_generation_mode package
@@ Expand DownExpand Up / @@ -27,3 +28,8 @@ py_test( @@
  "//:bagel_from_include_dep_in_module1_test",
  ],
 )
+py_pytest_main(
+ name = "__test__",
+ deps = ["@gazelle_python_test//pytest"],
+)

-Original file line number
+Diff line change
@@ Expand Up @@
 	c.gazelleManifest = gazelleManifest
 }
+func (c *Config) GetGazelleManifest() *manifest.Manifest {
+	for currentCfg := c; currentCfg != nil; currentCfg = currentCfg.parent {
+ if currentCfg.gazelleManifest != nil {
+ return currentCfg.gazelleManifest
+ }
+	}
+	return nil
+}
 // FindThirdPartyDependency scans the gazelle manifests for the current config
 // and the parent configs up to the root finding if it can resolve the module
 // name.
@@ Expand Down @@

Uh oh!

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target#2040

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target #2040

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aignasJul 9, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target#2040

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target #2040

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aignasJul 9, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target#2040

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target #2040

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aignasJul 9, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target#2040

Uh oh!

feat(gazelle): generate py_pytest_main __test__ target #2040

Uh oh!

Uh oh!

Diff view

feat(gazelle): generate py_pytest_main test target#2040

feat(gazelle): generate py_pytest_main test target #2040

aignasJul 9, 2024•
edited
Loading

feat(gazelle): generate py_pytest_main test target#2040

feat(gazelle): generate py_pytest_main test target #2040

aignasJul 9, 2024•
edited
Loading

feat(gazelle): generate py_pytest_main test target#2040

feat(gazelle): generate py_pytest_main test target #2040

aignasJul 9, 2024•
edited
Loading

feat(gazelle): generate py_pytest_main test target#2040

feat(gazelle): generate py_pytest_main test target #2040

aignasJul 9, 2024•
edited
Loading

feat(gazelle): generate py_pytest_main test target#2040

feat(gazelle): generate py_pytest_main test target #2040