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.wagner...@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 <mattmue...@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+unsubscr...@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 >> <https://groups.google.com/d/msgid/golang-nuts/a26c4aca-bbe3-4dc5-9f66-09d1db521517n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAEkBMfF36cBaAhuxPqTK3dbF6tja3yVAYrcNaWkMsw%3D8LR_-Pw%40mail.gmail.com.
