4 ms·

A comprehensive guide to ‘go generate’

78 points by picture 5y ago

sneak 5y ago
This reminds me how much I hate the go ./... magic custom (that means this and all recursive subdirectories). We have the unix -r custom already. Now we have another, that makes no sense, that you just have to learn.
- GauntletWizard 5y ago
  Blame Blaze (Bazel) and it's file/directory/target globbing rules. Though, truthfully - I find ... far more meaningful as an extension of the unix "." for "this directory" and ".." for "parent directory".
  - rob74 5y ago
    Ah, so that's where it's coming from! I initially suspected Plan 9...
    - GauntletWizard 5y ago
      As another comment noted, Perforce used this syntax too - Which is probably where Blaze got it from. I can't speak to earlier examples, but it's "obvious" enough that I would not be surprised if someone found one. I often think that a substantial portion of my job is software archaeology...
  - Steltek 5y ago
    Perforce does "..." as well and I would assume it's older than Bazel since it's older than Google.
- simiones 5y ago
  What do you mean by "unix -r custom"? It's not like "-r" is some kind of standard, and many commands or programs have other ideas. For example, GNU cp uses -r or -R for recursive copy, but OpenBSD cp only uses -R. ls uses -R only (-r is listing in reverse order). scp uses -r only (-R is remote copy). rm allows both -r and -R. But then, commands like mv or find don't support anything like -r or -R, they implicitly affect the whole directory structure. Bash has * (with shopt -s globstar) for globbing with subdirectories. Make doesn't support any concept of recursive subdirectory traversal.
  - sneak 5y ago
    You're absolutely right it's not a standard, but neither is ./... and one is in widespread use (a custom) and one is not. Other software that supports -r: rsync, fdupes, zfs destroy, et c. I'm not saying they're breaking spec, I'm saying they're being weird and divergent for no particular benefit (and at a quite obvious cost in terms of Google-specific learning curve, as Go is used widely outside of Google).
- avaldes 5y ago
  > go ./... magic custom (that means this and all recursive subdirectories). There. I did just learn it without following a tutorial or somethin. It's so simple, easy to remember. It's even faster to write that -R or -r.
mariusor 5y ago
I wish I could replace go generate by //go:embed for the case where I want to embed static assets with a pre-embed pass (eg, for something like minification). Sadly there's no room in the current API for doing this.
- xyzzy_plugh 5y ago
  Not sadly. Purposefully. This is a huge attack vector. Enabling arbitrary execution at compile time creates two problems which the Go authors have done well to avoid: - all Go code builds without external tool dependencies (with a single exception). - no execution of untrusted software in the build environment. It would be comically easy to inject malware into a popular Go package otherwise.
  - mariusor 5y ago
    > - no execution of untrusted software in the build environment. Erm, I must say I disagree with the decision if it's true. Do you have a link supporting it? I don't recall seeing anything like that when the feature was released. Also I wasn't referring to "external tools" but a way to pipeline the embed.FS tree through a filepath.WalkFn function that the developer adds. > //go:embed assets/* minifyFn > var minifiedAssets embed.FS > var minifyFn filepath.WalkFn Making paternalistic decisions for your users from the presumption that they're idiots is never a good idea in my opinion. And I'm sure people can already use the aforementioned go generate to execute untrusted software.
    - q3k 5y ago
      > Erm, I must say I disagree with the decision if it's true. Do you have a link supporting it? I don't recall seeing anything like that when the feature was released. From the `go generate` design doc: > Second, go build should never cause generation to happen automatically by the client of the package. Generators should run only when explicitly requested. https://docs.google.com/document/d/1V03LUfjSADDooDMhe-_K59EgpTEm3V8uvQRuNMAEnjg/edit https://docs.google.com/document/d/1V03LUfjSADDooDMhe-_K59Eg...

78 points by picture 5y ago

This reminds me how much I hate the go ./... magic custom (that means this and all recursive subdirectories). We have the unix -r custom already. Now we have another, that makes no sense, that you just have to learn.

GauntletWizard 5y ago
Blame Blaze (Bazel) and it's file/directory/target globbing rules. Though, truthfully - I find ... far more meaningful as an extension of the unix "." for "this directory" and ".." for "parent directory".
- rob74 5y ago
  Ah, so that's where it's coming from! I initially suspected Plan 9...
  - GauntletWizard 5y ago
    As another comment noted, Perforce used this syntax too - Which is probably where Blaze got it from. I can't speak to earlier examples, but it's "obvious" enough that I would not be surprised if someone found one. I often think that a substantial portion of my job is software archaeology...
- Steltek 5y ago
  Perforce does "..." as well and I would assume it's older than Bazel since it's older than Google.
simiones 5y ago
What do you mean by "unix -r custom"? It's not like "-r" is some kind of standard, and many commands or programs have other ideas. For example, GNU cp uses -r or -R for recursive copy, but OpenBSD cp only uses -R. ls uses -R only (-r is listing in reverse order). scp uses -r only (-R is remote copy). rm allows both -r and -R. But then, commands like mv or find don't support anything like -r or -R, they implicitly affect the whole directory structure. Bash has * (with shopt -s globstar) for globbing with subdirectories. Make doesn't support any concept of recursive subdirectory traversal.
- sneak 5y ago
  You're absolutely right it's not a standard, but neither is ./... and one is in widespread use (a custom) and one is not. Other software that supports -r: rsync, fdupes, zfs destroy, et c. I'm not saying they're breaking spec, I'm saying they're being weird and divergent for no particular benefit (and at a quite obvious cost in terms of Google-specific learning curve, as Go is used widely outside of Google).
avaldes 5y ago
> go ./... magic custom (that means this and all recursive subdirectories). There. I did just learn it without following a tutorial or somethin. It's so simple, easy to remember. It's even faster to write that -R or -r.

mariusor 5y ago

I wish I could replace go generate by //go:embed for the case where I want to embed static assets with a pre-embed pass (eg, for something like minification). Sadly there's no room in the current API for doing this.

xyzzy_plugh 5y ago
Not sadly. Purposefully. This is a huge attack vector. Enabling arbitrary execution at compile time creates two problems which the Go authors have done well to avoid: - all Go code builds without external tool dependencies (with a single exception). - no execution of untrusted software in the build environment. It would be comically easy to inject malware into a popular Go package otherwise.
- mariusor 5y ago
  > - no execution of untrusted software in the build environment. Erm, I must say I disagree with the decision if it's true. Do you have a link supporting it? I don't recall seeing anything like that when the feature was released. Also I wasn't referring to "external tools" but a way to pipeline the embed.FS tree through a filepath.WalkFn function that the developer adds. > //go:embed assets/* minifyFn > var minifiedAssets embed.FS > var minifyFn filepath.WalkFn Making paternalistic decisions for your users from the presumption that they're idiots is never a good idea in my opinion. And I'm sure people can already use the aforementioned go generate to execute untrusted software.
  - q3k 5y ago
    > Erm, I must say I disagree with the decision if it's true. Do you have a link supporting it? I don't recall seeing anything like that when the feature was released. From the `go generate` design doc: > Second, go build should never cause generation to happen automatically by the client of the package. Generators should run only when explicitly requested. https://docs.google.com/document/d/1V03LUfjSADDooDMhe-_K59EgpTEm3V8uvQRuNMAEnjg/edit https://docs.google.com/document/d/1V03LUfjSADDooDMhe-_K59Eg...