On 4/30/20 3:56 AM, Anatol Pomozov via arch-dev-public wrote:
Thank you for coming up with this document.
Go is a fantastic language and I would love to see more people using it. Having things documented will help our users to get more comfortable with the golang packaging.
This RFC is about packaging code, not encouraging people to use a particular language when writing their next big project. :p Let's focus on that.
My concern was related to use of vendorized sources. "-vendor" was not created for the cache management. If one wants to warmup the gomodules download cache then "go mod download" should be used. See more info about this tool here https://github.com/golang/go/issues/26610
And if we plan to encourage adding the cache warmup to all golang PKGBUILD (that's gonna be thousands of packages) then this extra complexity need be justified. Anyone who wants to follow our advise needs to have clear answers to following questions: Is this feature solely to avoid the download during the build() step or there is something else? Why downloading in build() is bad, does it hurt the users? What use-cases does show an advantage of the cache warmup.. etc..
I'd like to elaborate on this again. Because I don't either understand what the initial purpose of this RFC suggestion was. Why does it matter to makepkg how the go compiler downloads source code, or using which options? Any download that is done outside the source=() array is violating the PKGBUILD contract, and is not cached in $SRCDEST. It is therefore not persisted between successive clean chroot builds since those use a temporary $HOME and $BUILDDIR which is deleted between uses. And regardless of any other factors, it will not be able to work if the makepkg tool is executed in an environment where the network has been disabled. So, we don't get caching and we don't get offline builds. That's beyond question. What is the intended goal anyone intends to solve by warming up the gomodules download cache, precisely? -- Eli Schwartz Bug Wrangler and Trusted User