On Wednesday, March 13, 2019 at 7:25:35 PM UTC+1, Wael Nasreddine wrote: > > On Monday, March 11, 2019 at 10:01:04 AM UTC-7, Manlio Perillo wrote: >> >> Do you perhaps have the same requirements as in the thread >> https://groups.google.com/forum/#!topic/golang-dev/DD88cds-LuI >> as reported by Nicolas Mailhot? >> >> That is, you need to patch the upstream source but keep the same version, >> because you can't (or don't want to) update all the versions of the >> required modules. >> >> > Not precisely. In my case, I'm doing the build in two stages a) fetch > dependencies and make sure they pass the hash >
How do you fetch the dependencies? > and b) use (a) to build the module. I can add patches to the stage (a) to > patch dependencies, but obviously, it does need some patching work due to > the path of the dependency itself. I'm not too worried about patching at > this time as I'm more worried about packaging instead. > > >> In this case vendoring is, IMHO, currently the only solution, because the >> go tool ignores the go.sum files in this case. >> You can try to open a bug report about the incorrect behavior of `go mod >> vendor` when using cgo. >> >> Or you can patch cmd/go. However instead of writing a patch specific to >> Nix, I suggest to write a more generic patch. >> > > > [...] > None of these patches seems to work if I remove the entire > $GOPATH/pkg/mod/cache directory. > What -mod=trust do is to make cmd/go ignore go.sum hashes. This is exactly what vendoring do, but instead of having the required modules in a per module vendor directory, you have a shared pool of modules, accessible using GOPROXY. By the way, note that only the first patch is correct. Again, I'm removing this entire directory because of both > $GOPATH/pkg/mod/cache/vcs and $GOPATH/pkg/mod/cache/download seem to change > whenever upstream has changed even though go.mod/go.sum are still on the > same commit. > I still don't understand why you need to remove the cache directory. vcs contains the clone for each of the module repository required. Cloning a module repository may be a very *expensive* operation. download contains the module data synthesized by cmd/go from the vcs repositories (AFAIK). This is *not* an inexpensive operation. When cmd/go download all the dependencies of a module, it may download different versions of the same module, even if they are not used in the build. For this reason both vcs and download are updated, but each module version data is immutable. > I do agree with you, however, that the correct solution is to rely on > vendoring instead of patching the module support. I will report a bug in > vendoring with regards to cgo. > Regards Manlio Perillo -- 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. For more options, visit https://groups.google.com/d/optout.
