3 ms·

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

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

mariusor 5y ago
> go generate I think both me and xyzzy_plugh were referring to go:embed. But I take your meaning that using go generate as a build step is not meant to be idiomatic. I guess I've been using it wrong all this time. :)
- q3k 5y ago
  > It is important to note that as a matter of both design and policy, the go command never runs user-specified code during a build. This improves the reproducibility, scalability, and security of builds. This is also the reason that go generate is a separate manual step rather than an automatic one. Any new go command support for embedded static assets is constrained by that design and policy choice. https://go.googlesource.com/proposal/+/master/design/draft-embed.md https://go.googlesource.com/proposal/+/master/design/draft-e...
  - mariusor 5y ago
    Yes, but I think that's mostly wishful thinking. Not all applications get built using strictly go tooling. I rely on make for mine because it's better suited for the platform I'm targeting.
    - q3k 5y ago
      Right, and because your dependencies don't shell out to some random tools during a go build it makes your build system less likely to break and makes your job easier. You have guarantees that unless you run a `go generate` no third-party code will run, and that every build step is fully hermetic. And since you're already using Make for the build, it's probably better equipped to perform the preprocessing than go embed or even go generate so you don't really need Go's build system to take care of that. `go build` & co are designed to easily integrate into complex or overarching build systems (which are inevitable for any large project, as you mentioned), and the lack of expectation of being able to shell out arbitrarily during a 'normal' build of some leaf library is what contributes to this ease of integration. Contrast that to how difficult it is to integrate with Rust/Cargo's build system where every second package has a `build.rs` which expects some undefined ambient environment to be present and makes any attempt to make the builds hermetic extremely painful.

by q3k 5y ago

mariusor 5y ago

> go generate I think both me and xyzzy_plugh were referring to go:embed. But I take your meaning that using go generate as a build step is not meant to be idiomatic. I guess I've been using it wrong all this time. :)

q3k 5y ago
> It is important to note that as a matter of both design and policy, the go command never runs user-specified code during a build. This improves the reproducibility, scalability, and security of builds. This is also the reason that go generate is a separate manual step rather than an automatic one. Any new go command support for embedded static assets is constrained by that design and policy choice. https://go.googlesource.com/proposal/+/master/design/draft-embed.md https://go.googlesource.com/proposal/+/master/design/draft-e...
- mariusor 5y ago
  Yes, but I think that's mostly wishful thinking. Not all applications get built using strictly go tooling. I rely on make for mine because it's better suited for the platform I'm targeting.
  - q3k 5y ago
    Right, and because your dependencies don't shell out to some random tools during a go build it makes your build system less likely to break and makes your job easier. You have guarantees that unless you run a `go generate` no third-party code will run, and that every build step is fully hermetic. And since you're already using Make for the build, it's probably better equipped to perform the preprocessing than go embed or even go generate so you don't really need Go's build system to take care of that. `go build` & co are designed to easily integrate into complex or overarching build systems (which are inevitable for any large project, as you mentioned), and the lack of expectation of being able to shell out arbitrarily during a 'normal' build of some leaf library is what contributes to this ease of integration. Contrast that to how difficult it is to integrate with Rust/Cargo's build system where every second package has a `build.rs` which expects some undefined ambient environment to be present and makes any attempt to make the builds hermetic extremely painful.