On 11 September 2021 8:36:50 pm IST, Sebastian <seabass-lab...@gmx.com> wrote:
>Dear Michael,
>
>> Aren't the relevant checks disabled when GO111MODULE is set to off,
>> which dh-golang does?
>
>Thank you very much for your speedy response! With the information in
>your email, I was able to find https://golang.org/ref/mod#mod-commands
>(which describes the GO111MODULE environment variable). It is something
>of a radical change in behaviour for such an innocuously named setting!
>
>> It's always seemed to me that the go.mod approach _should_ be more
>> compatible with Debian packaging than the GOPATH approach, but I've
>> never scraped together the time to see if this is actually true, never
>> mind implementing anything...
>
>I would be very interested to see how this might work; presumably, for
>when the Go build tool attempts to download the dependencies, a proxy
>server would need to be used in the CI/CD to translate the package paths
>into ones pointing to the Debian packages.
>
In ruby team, we have rubygems-integration package which adds Debian paths to
rubygems search path and bundler with --local option resolves everything
locally. We recently started implementing yarn-plugin-apt for node modules as
well so yarn can transparently resolve apt installed modules as well. One extra
challenge would be usage of exact versions of modules in go.mod, unlike in
package.json or Gemfile which uses something like ^1.0.0 or ~> 1.0 which allows
news semver compatible versions to satisfy dependencies.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
