4 ms·

the author commits the generated files to the source repository, so that they are available to clients that use go get Treating generated files as primary sour

by pcl 12y ago

the author commits the generated files to the source repository, so that they are available to clients that use go get Treating generated files as primary source is a disaster waiting to happen. Someone will end up just doing a quick edit of the derived file because yacc isn't set up right, or running a sed command to do a refactoring, or just not understand the difference. One of the things that I like about go is that it does a good job of keeping the codebase clean; recommending a solution that sets up this sort of trap is a big departure. I wonder what other approaches are available for packages that intend to distribute in source form, however. I could imagine adding a parallel directory structure for the generated files, to make it clear that they are out of bounds, akin to the mvn source / target layout.

mrweasel 12y ago
I completely agree. If you're going to add generated files to a source code repository, they need to be clearly marked in one way or another. If the author truly want a "go generate" they good sell it much better. I understand the yacc idea, it can be a pretty good solution for something like configuration files. OpenBSD use yacc to do the grammar for many of they tools and that has worked out create. The big sell though would be WSDLs. I understand the aversion towards SOAP and WSDL, but it's here and having Go support would be nice. Generating Go code from a WSDL wouldn't be to hard a sell I think, and it fits nicely into this idea.
- iand 12y ago
  I think you misunderstand the context. go generate is already in Go tip and will be released as part of Go 1.4
  - pcl 12y ago
    Thanks; good to know. Here's a link to the original discussion thread on the Go newsgroup from July: https://groups.google.com/forum/#!topic/golang-dev/ZTD1qtpruA8 https://groups.google.com/forum/#!topic/golang-dev/ZTD1qtpru...
NateDad 12y ago
Actually it's not really a big deal. You just put a header at the top that tells people not to hand modify it. Every C# winforms project already did that. The nice thing is that you can diff the newly generated code versus the old code and make sure changes make sense.

by pcl 12y ago

mrweasel 12y ago

I completely agree. If you're going to add generated files to a source code repository, they need to be clearly marked in one way or another. If the author truly want a "go generate" they good sell it much better. I understand the yacc idea, it can be a pretty good solution for something like configuration files. OpenBSD use yacc to do the grammar for many of they tools and that has worked out create. The big sell though would be WSDLs. I understand the aversion towards SOAP and WSDL, but it's here and having Go support would be nice. Generating Go code from a WSDL wouldn't be to hard a sell I think, and it fits nicely into this idea.

iand 12y ago
I think you misunderstand the context. go generate is already in Go tip and will be released as part of Go 1.4
- pcl 12y ago
  Thanks; good to know. Here's a link to the original discussion thread on the Go newsgroup from July: https://groups.google.com/forum/#!topic/golang-dev/ZTD1qtpruA8 https://groups.google.com/forum/#!topic/golang-dev/ZTD1qtpru...

NateDad 12y ago

Actually it's not really a big deal. You just put a header at the top that tells people not to hand modify it. Every C# winforms project already did that. The nice thing is that you can diff the newly generated code versus the old code and make sure changes make sense.