Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/vgo: Ensuring VGO allows people to build enterprise support #24811
VGO Caching Strategy and Enterprise Development
Can't use internet go repositories directly
Generally somthing like this is done via a tool like Artifactory and only allowing vetted libraries into it.
This can be solved with firewall in some cases. However, tools like maven solve this by having you list repositories and only hitting those with a default of mvncentral (I think) if no repos are configured.
Versions of libraries aren't the same across all projects
Now even worse, lets say I'm a dev for loglib, and working on both watchy and chatty fixes. I need to have a go development env for watchy setup, and a different one for chatty. If I use unified system cache then these 2 projects will be stepping on each other and really these unreleased versions don't resolve across gopaths.
This may sound wierd but artifactory lets you setup project specific views into packages.
In general it might make more sense to tie the cache to the "compilation directory".
Tho I do think that the ability to setup the cache directory with a envvar is a workaround. Just may be awkward and lead to many issues.
Go Version Dependent?
Inability to provide your own cache system
That's great! vgo is designed to work in your environment. You'll want to deploy a company proxy probably (see below).
That is interesting. vgo doesn't upgrade to point versions automatically (unlike most other systems), which means rather then using un-released versions for some projects, you can actually tag these point releases as real releases, then only update projects to that version that require it. Please refer to MVS (minimal version selection).
vgo works on Go code. What you are talking about is the build cache I think. This is much improved in go1.10 (like night and day better).
External cache systems are part of the design. There is an initial implementation of one here: https://github.com/gomods/athens
It sounds like vgo is already well designed to meet all of your needs you listed here. Even though some of the tools like vgo and athens are immature early versions, your needs are well known, common, and designed to have first class support in vgo.
We're aware of all these concerns, and I believe the current module design does allow people to build the enterprise support you are describing. Over time I expect that some of it will be standard instead of having to be built separately.
I'm going to close this issue, though, since there's not a specific bug to fix.