Thank you very much for your reply. It seems to be a possible way to do it,
what do you think about the athens way? In my point of view it would be the
easiest way as far i can preload the athens cache with all the required
packages,
And then the only thing a developer has to do, is to set the GOPROXY to the
athens instance.
Cheers
Am Mittwoch, 12. Dezember 2018 23:51:08 UTC+1 schrieb ohir:
>
> On Wed, 12 Dec 2018 11:59:59 -0800 (PST)
> snmed <sandro....@gmail.com <javascript:>> wrote:
>
> > Hi all
> >
> > Our customer demands an offline development environment with no internet
> > connection, is there any best practices to handle package download and
> > project setup for such an use case?
>
> Such setups are supported by the Go from its onset.
>
> 1. DMZ box where `go get` can reach external repositories
> 2. IDP internal distribution point - with vetted go tools and vetted libs
>
> External downloads are done via the DMZ box then inspected.
> After security team OK's something it is moved to the IDP
> host from where devs ro mount:
>
> Std tools and libs - to the fixed GOROOT location, say /usr/local/go
>
> Vetted internal libs - to the fixed main GOPATH location, say
> /usr/local/gours [1]
>
> Vetted third party libs - to the second GOPATH location, say
> /usr/local/go3p.
>
> Local development takes place in the third GOPATH location,
> say /home/${USER}/project/go
>
> On the dev box:
>
> # GOROOT=; not set - it is present in the tools via GOROOT_FINAL
> # GOPATH=/internal:/thirdparty:/local [2]
> export GOPATH=/usr/local/gours:/usr/local/go3p:/home/${USER}/project/go
>
> [1] Authors of internal libs usually work on shadowmount within
> this path, then commit to the reviewers repo from where their vetted
> lib goes to the IDP.
>
> [2] Accidental `go get` of some privileged (or in sec rules violation)
> person
> will try to write to the first "/internal" path where either it errs
> because its read only
> or at most it will write to the local disk - then shadowed by the remote
> mount.
>
> read `go help gopath` for details.
>
>
> > And how would the new go modules fit in
> > in such an environment?
>
> It does not AFAICS. I can not elaborate on this due to the list's CoC.
> I just hope that Go team ultimately will not pull GOPATH from under our
> feet.
>
> > Any advise will be most appreciated.
>
> Hope this helps,
>
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
--
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.
