[bug#50227] [PATCH 0/3] go-build-system and GOPATH improvements

[Maxim Cournoyer]

Hello,

[...]

>> I'm not sure what a similar idiom for Guix-like hacking in module-aware
>> mode would be; we'd have to set GOMODCACHE or something, but it would be
>> very easy for Go to overwrite (or fail to overwrite) things without
>> GOPROXY=off.  Alternatively, if we make a "full" go proxy directory
>> layout, we can do
>>
>>   GOPROXY=file://path/to/gomodcache
>>
>> or even a search path like
>>
>>   GOPROXY=file:///gnu/store/p1/gomodcache|file://gnu/store/p2/gomodcache
>>
>> though I'm not sure how well that would scale w.r.t. number of packages.
>>
>> Both of these GOPROXY methods have the advantage over setting GOMODCACHE
>> that the user could modify GOPROXY to include the default proxy, and
>> would still be able to get packages and versions not packaged by Guix.
>>
>> I suppose there's no reason we couldn't set both GOPATH and
>> e.g. GOPROXY.
>
> GOPROXY seems like a great middle ground for local development.
>
> Given the conflicting work here, what do you think we should do?  I'm
> happy to scrap this PR as it was largely an exercise to learn
> go-build-system, in addition to scratching a very minor itch.
>
> Is the reduced complexity worth it while waiting for the gomodules
> rewrite, and if so, are there parts that can be merged with your work
> such as using $out/share/go?
>
> Let me know if I can be of assistance.  :-)

I'm confused by the status of this series :-) Is there something to
salvage, or do we scrap it, awaiting for a proper gomodules solution?

Thanks!

Maxim