-
Notifications
You must be signed in to change notification settings - Fork 120
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
Unpredictable "Code generated by" comment when invoking peg with "go run" #129
Comments
mark-rushakoff
added a commit
to tendermint/tendermint
that referenced
this issue
Jul 26, 2022
The code to generate the pubsub queries was dependent on an unspecified version of the peg tool. This brings peg into go.mod so it is on a fixed version. This should also enable dependabot to notify us of future updates to peg. The version of query.peg.go generated from the current version of peg correctly contains the special "Code generated by..." line to indicate to other tools that the file is automatically generated and should therefore be excluded from linters, etc. I removed the make target as there were no git grep results referencing "gen_query_parser"; directly running "go generate" is a reasonable expectation in Go projects. Now that "go run" is module aware, I would typically use "go run" inside the go:generate directive, but in this case we go build to a gitignore-d directory in order to work around the nondeterministic output detailed in pointlander/peg#129.
mark-rushakoff
added a commit
to tendermint/tendermint
that referenced
this issue
Jul 27, 2022
* libs/pubsub/query: specify peg version in go.mod The code to generate the pubsub queries was dependent on an unspecified version of the peg tool. This brings peg into go.mod so it is on a fixed version. This should also enable dependabot to notify us of future updates to peg. The version of query.peg.go generated from the current version of peg correctly contains the special "Code generated by..." line to indicate to other tools that the file is automatically generated and should therefore be excluded from linters, etc. I removed the make target as there were no git grep results referencing "gen_query_parser"; directly running "go generate" is a reasonable expectation in Go projects. Now that "go run" is module aware, I would typically use "go run" inside the go:generate directive, but in this case we go build to a gitignore-d directory in order to work around the nondeterministic output detailed in pointlander/peg#129. * libs/pubsub/query: check error from (*QueryParser).Init() The newly generated peg code returns an error from Init(); the previous version was niladic. Co-authored-by: Sam Kleinman <[email protected]>
+1, I'd love for this to be fixed! |
@mark-rushakoff @matthewmueller Did #138 fix this? :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since
go run
has been made module aware, it is convenient to usego run
with//go:generate
directives, so that your project is able to trivially use a fixed version of its external dependencies.I want to write my
go:generate
directive like this:But
go run
builds the target binary in a temporary directory, andmain.go
passes the entirety ofos.Args
to the template, such thatos.Args[0]
contains the full path to the builtpeg
binary in a random temporary directory:peg/main.go
Line 87 in e7588a8
This results in a diff every time go generate has been run:
(The
go-build
portion of the directory is different on each invocation above.)It would be nice if
os.Args[0]
was just set topeg
by default, but if it is important to maintain backwards compatibility, you could add a new flag to peg. I would lean towards something like-fixedname
to mean "just set os.Args[0] topeg
regardless of its actual value". Another option would be something like-arg0name=peg
, but I doubt anyone would need it customized to anything than some arbitrarily fixed name, hence my preference to a simple boolean flag.In the meantime, I can work around this by changing my
//go:generate
to just build the binary into a fixed directory:Then, the comment does not change on subsequent
go generate
calls.The text was updated successfully, but these errors were encountered: