https://pantsbuild.org/ logo
Join Slack
Powered by
<@U0N6C2Q9F> I just noticed the `go-generate` goal...
# development
p
@fast-nail-55400 I just noticed the 
go-generate
goal in a 2.15 release notes PR. Thinking about differences between other pants codegen and this: I think pants codegen is designed for generated code that is NOT version controlled. But the product of 
go-generate
(and the underlying 
go:generate
statements) are expected to be committed in git (or similar version control). Is that an accurate comparison? Second question: Would a lint step be helpful for the go-generated code such that lint fails if go-generate would update the generated files?
f
But the product of 
go-generate
(and the underlying 
go:generate
statements) are expected to be committed in git (or similar version control). Is that an accurate comparison?
Yes. Which is how users using 
go
and not Pants would expect 
go generate
to work.
From https://go.dev/blog/generate
Go generate does nothing that couldn’t be done with Make or some other build mechanism, but it comes with the 
go
tool—no extra installation required—and fits nicely into the Go ecosystem. Just keep in mind that it is for package authors, not clients, if only for the reason that the program it invokes might not be available on the target machine. Also, if the containing package is intended for import by 
go
get
, once the file is generated (and tested!) it must be checked into the source code repository to be available to clients.
(bold added by me)
Second question: Would a lint step be helpful for the go-generated code such that lint fails if go-generate would update the generated files?
Maybe but it would be a feature that 
go
itself does not offer, so I would not expect users familiar with 
go
to expect Pants to offer that. So I don't see a great need to add such a feature.
(given limited maintainer resources for development of the Go backend)
p
Thank you! I'm drafting a proposal that I'll probably post later this week. Thanks for validating my assumptions.
@fast-nail-55400 here is my proposal: https://github.com/pantsbuild/pants/discussions/18235
If a target needs to depend on files created by 
go-generate
then those files need a BUILD target that owns them, right? So you'd end up running sometime like 
go-generate
and then 
tailor
. In other words, pants has no idea that a given file was created via 
go-generate
.
f
In other words, pants has no idea that a given file was created via 
go-generate
.
Correct. I will add if there is a 
go_package
already and if the 
go generate
invoked program writes 
.go
files, then the 
go_package
will automatically see the sources. The intention with 
go-generate
was to match the 
go generate
experience as exactly as possible.
👍 1
3 Views
Open in Slack
PreviousNext
Powered by