Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions gazelle/python/generate.go
Original file line number Diff line number Diff line change
Expand Up @@ -93,6 +93,7 @@ func (py *Python) GenerateRules(args language.GenerateArgs) language.GenerateRes
actualPyBinaryKind := GetActualKindName(pyBinaryKind, args)
actualPyLibraryKind := GetActualKindName(pyLibraryKind, args)
actualPyTestKind := GetActualKindName(pyTestKind, args)
actualPyTestMainKind := GetActualKindName(pyTestMainKind, args)

pythonProjectRoot := cfg.PythonProjectRoot()

Expand Down Expand Up @@ -476,6 +477,31 @@ func (py *Python) GenerateRules(args language.GenerateArgs) language.GenerateRes
result.Imports = append(result.Imports, pyTest.PrivateAttr(config.GazelleImportsKey))
}

if len(pyTestTargets) > 0 {
Copy link
Contributor

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 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.

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
16 changes: 13 additions & 3 deletions gazelle/python/kinds.go
Original file line number Diff 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 Down Expand 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",
Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator

@aignas aignas Jul 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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 # 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.

Symbols: []string{
pyTestMainKind,
},
},
}
14 changes: 13 additions & 1 deletion gazelle/python/target.go
Original file line number Diff 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 Down Expand 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
}
6 changes: 6 additions & 0 deletions gazelle/python/testdata/annotation_include_dep/BUILD.out
Original file line number Diff 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 Down Expand 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 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 Down Expand Up @@ -27,3 +28,8 @@ py_test(
"//:bagel_from_include_dep_in_module1_test",
],
)

py_pytest_main(
name = "__test__",
deps = ["@gazelle_python_test//pytest"],
)
6 changes: 6 additions & 0 deletions gazelle/python/testdata/monorepo/coarse_grained/BUILD.out
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
load("@aspect_rules_py//py:defs.bzl", "py_pytest_main")
load("@rules_python//python:defs.bzl", "py_library", "py_test")

# gazelle:python_extension enabled
Expand Down Expand Up @@ -26,3 +27,8 @@ py_test(
"foo/bar/bar_test.py",
],
)

py_pytest_main(
name = "__test__",
deps = ["@root_pip_deps//pytest"],
)
Original file line number Diff 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")

py_library(
name = "python_target_with_test_in_name",
Expand All @@ -20,3 +21,8 @@ py_test(
srcs = ["test_reality.py"],
deps = [":python_target_with_test_in_name"],
)

py_pytest_main(
name = "__test__",
deps = ["@gazelle_python_test//pytest"],
)
9 changes: 9 additions & 0 deletions gazelle/pythonconfig/pythonconfig.go
Original file line number Diff line number Diff line change
Expand Up @@ -268,6 +268,15 @@ func (c *Config) SetGazelleManifest(gazelleManifest *manifest.Manifest) {
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