Thanks for your thoughts! > I'm not sure what the advantages would be over doing the normal approach of generating the files and committing them?
Mostly trying to improve the UX by avoiding generated code clutter during development. I concede that storing all your generated code in one directory inside your project isn't that big of a deal. Another solution could be to configure your editor to hide the generated directory. > So we are talking local development only. Yah, exactly. The CLI wraps "go run" anyway, so there's a place to generate code on new machines before starting the program. > In which case replace directives with a directory target is most likely your best solution: Replace is an interesting idea. I think replace would work well if there was a standard place to put generated code outside of your project. I guess that's what I'm looking for: a standard place to hide away generated code until you care about it and want to vendor it. And when you do want to vendor it, you can use the same code paths as your third-party dependencies. On Wednesday, October 21, 2020 at 8:25:33 AM UTC+2 Paul Jolly wrote: > I would personally steer clear of writing anything to the module cache. > > If you are only code generating into the module cache and not > publishing this generated code, by definition that generated content > will not be available remotely. Hence any code you publish that > depends on this generated content will fail to resolve. So we are > talking local development only. > > In which case replace directives with a directory target is most > likely your best solution: > > https://golang.org/ref/mod#go-mod-file-replace > > On Wed, 21 Oct 2020 at 00:12, 'Axel Wagner' via golang-nuts > <golan...@googlegroups.com> wrote: > > > > On a second read, I probably misunderstood what you intend to do. > > I still think what you intend to do might technically be possible - I'm > not entirely sure, though. The module cache is by default read-only, so > you'd want a tool that force-replaces a directory. And then, the go build > cache might get confused, if the contents of the cache change. I'd also > predict that you regularly run into issues where things don't build the > same on your machine as for other people, leading to hard to debug and > confusing errors. And, lastly, I'm not sure what the advantages would be > over doing the normal approach of generating the files and committing them? > It seems strictly more work, with no added benefits. > > > > On Wed, Oct 21, 2020 at 1:06 AM Axel Wagner <axel.wa...@googlemail.com> > wrote: > >> > >> Technically, I think this would be possible. Your code wouldn't be > usable together with code that doesn't use modules. And you'd need to have > a server that takes the code from the git repository and generates a .zip > file for any interesting version (possibly on demand), which you would > probably have to build yourself. It also means there is no reliable > provenance from your git repository to your published module, so > reproducing/forking what you do might be more difficult. Code analysis > running from the repository (like sourcegraph or githubs hover info) might > not understand the code anymore. > >> > >> But, yeah. In general, you can put *any* go code in an appropriate > .zip-file and serve it up as a module. You don't even have to publish the > repository itself at all, if you so wish. > >> > >> On Wed, Oct 21, 2020 at 12:39 AM Matt Mueller <mattm...@gmail.com> > wrote: > >>> > >>> Sorry, maybe cache is the wrong word. > >>> > >>> Wherever "go get -u ..." downloads modules, I'd like to stick my > generated code. > >>> > >>> Conceptually you could think of it as a virtual module used only > during development. If you're familiar with Node.js, You could also think > of it as creating a directory in node_modules/ and then importing it with > require(...). > >>> > >>> I'm just wondering if I'll run into issues doing this or mess up other > people's modules. > >>> > >>> On Tuesday, October 20, 2020 at 9:22:05 PM UTC+2 seank...@gmail.com > wrote: > >>>> > >>>> That doesn't really make sense? > >>>> The module cache is for immutable versions of modules, > >>>> ie. publish your (generated) code as a package/module, import that > >>>> it will then get cached > >>>> > >>>> On Tuesday, October 20, 2020 at 8:50:25 PM UTC+2 mattm...@gmail.com > wrote: > >>>>> > >>>>> Hey folks, > >>>>> > >>>>> I'm working on a project with a lot of code generation. I'd love to: > >>>>> > >>>>> - get the code generation out of the way when you don't care about it > >>>>> - be able to vendor the generated code when you do care about it > >>>>> > >>>>> That led me to an idea about generating code into the go module > cache. Do you see any downside in doing this? > >>>>> > >>>>> Thanks! > >>>>> Matt > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > >>> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/a26c4aca-bbe3-4dc5-9f66-09d1db521517n%40googlegroups.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF36cBaAhuxPqTK3dbF6tja3yVAYrcNaWkMsw%3D8LR_-Pw%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/43710960-2ef7-4b1e-a990-8528451f7049n%40googlegroups.com.
