----- Original Message -----
> From: "Ian Denhardt" <i...@zenhack.net>
> To: "Matthew Dempsky" <mdemp...@google.com>, "Nicolas Mailhot"
> <nicolas.mail...@laposte.net>
> Cc: "Russ Cox" <r...@golang.org>, "'Matthew Dempsky' via golang-dev"
> <golang-...@googlegroups.com>,
> golang@lists.fedoraproject.org
> Sent: Monday, March 11, 2019 7:18:49 PM
> Subject: Re: [golang-dev] proposal: public module authentication with the Go
> notary
>
> Quoting Matthew Dempsky (2019-03-11 13:54:07)
> > On Mon, Mar 11, 2019 at 8:01 AM Nicolas Mailhot
> > <[1]nicolas.mail...@laposte.net> wrote:
> >
> > And as I have explained in the detailed description Matthew
> > requested,
> >
> > To be clear, I was asking for details to reproduce the technical issues
> > you're running into. I may have missed them, but I don't believe you've
> > provided these.
> >
> > our construction of the CI/CD environment is incremental, so the
> > assumption in the go tool code that "everything is there and it it
> > is
> > not it can be downloaded directly" does not work for us
> >
> > If your build system provides the Go source/packages, then Go won't try
> > to download them directly itself. This is how Go works within Google's
> > build system (which, again, has the same no-network-access limitation
> > as the build system you're describing, and yet supports building Go
> > programs/packages).
> > It sounds like you're having trouble with providing the Go
> > source/packages in the format expected by cmd/go. If you would provide
> > reproduction steps of what you're doing and the problems you're running
> > into, we can help advise what changes you need to make, and maybe
> > identify tooling improvements to make that easier.
>
> In a parallel thread, a Nix developer was asking about basically the
> same use case, and was pointed at `go build -mod=vendor`. It seems like
> this does exactly what is wanted here -- just use the code we have
> locally. Nicolas, does that address your use case?
>
> -Ian
>
I think that our issue in Fedora is that we would like to continue using
something that resembles current "GOPATH/vendor" approach where the tooling is
not trying to kind of out smart us. As we have in distribution environment full
control about the build environment and dependencies and we want/will have to
retain it. I believe that having some "dumb mode" for operating all the go
commands/tools(without the hard need for a modules (verification), even with
reduced features) would be much appreciated(so you can use it as any other
compiler/interpreter by just throwing code at it).
IMHO we will tap the metadata that the Go modules carry to simplify our
processes and automations, but for example having to run our own notary(even
just in build environment) just to be able to use go build/go list/go vet...
might be really costly and we will be most probably looking for any alternative.
It has been mentioned several times, in this bunch of treads, that Google's
internal build infrastructure has same requirements and is facing similar
challenges. It would be great to hear how do they plan to "workaround" up
coming module changes.
JC
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
_______________________________________________
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
