Go: awkward UX with ./pants check and third-party packages
#13175
Comments
|
cc @tdyas @stuhood @patricklaw . What do you think of the proposed solution? Do you have any other ideas? |
I agree with this solution. We are using targets as an implementation detail to make it easier to build third party code, but the user does not expect |
Probably save this as a motivating use case for lazy target generation some time in the future. |
|
Closing as answered. |
This lets you compile a package without needing to run tests or package a binary. Note that you can only directly compile a first-party package - to check if a third-party package is buildable, it must be a dependency of a first-party package. Works around #13175. This does not yet have an optimal UX. It's overly chatty: ``` ❯ ./pants check testprojects/src/go:: 13:36:38.57 [INFO] Initializing scheduler... 13:36:39.20 [INFO] Scheduler initialized. 13:36:39.71 [ERROR] Completed: pants.backend.go.goals.check.check_go - go failed (exit code 1). Partition #1 - github.com/pantsbuild/pants/testprojects/src/go/pants_test: ./testprojects/src/go/pants_test/foo.go:3:1: syntax error: non-declaration statement outside function body Partition #2 - github.com/pantsbuild/pants/testprojects/src/go/pants_test/bar: 𐄂 go failed. ``` We also should be streaming the result of each compilation as it happens, which has an added benefit of that output happening when compilation happens as a side effect of `run`, `package`, and `test`. Those fixes will be in a followup. [ci skip-rust] [ci skip-build-wheels]
Many third-party packages end up never being used in a Go project. Pants pessimistically uses target generation to create a
go_third_party_packagetarget for every package belonging to a third-party module, even if it will never be used:pants/src/python/pants/backend/go/util_rules/third_party_pkg_test.py
Lines 284 to 299 in f3ffa37
This is necessary for dependency inference to work: we need to have a mapping of every possible package used to map back imports.
--
However, this means that
./pants check ::will end up compiling substantially more packages than are actually needed. Not only is this wasted performance, but some packages might not compile such as from us not yet supporting cgo files, c files, etc.--
It is not acceptable to require the user first do
./pants filter --target-type=go_first_party_package :: | xargs ./pants check.Instead, I think the solution is to not hook up
go_third_party_packageto./pants check. The only way to compile a third-party package is because it's a dependency of a first-party package.The text was updated successfully, but these errors were encountered: