GNU bug report logs -
#50227
[PATCH 0/3] go-build-system and GOPATH improvements
Previous Next
Full log
Message #46 received at 50227 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 116 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.