On Fri, Jun 25, 2021 at 1:23 PM josvazg <josv...@gmail.com> wrote: > When working on internal company projects, it makes sense to use a company > wide GO Proxy assuring that all go dependency code is available and > immutable. But when you move to an Open Source project, you cannot longer > use such private proxy. > > I wonder what is the best practice recommendation for Open Source projects. > > I can't comment about whether anything specifically is a "best practice", but here are my thoughts:
> For instance, reading about https://proxy.golang.org/ is says: > > Why did a previously available module become unavailable in the mirror? > > > proxy.golang.org <https://proxy.golang.org> does not save all modules > forever. > > Which means, your project may *not compile* anymore if someone pulls one > of your dependencies and proxy.golang.org decides to drop it. > The next line in that FAQ section mentions specific reasons why proxy.golang.org wouldn't persist a module version in its cache. (e.g. licences it doesn't recognize as letting it keep/distribute copies of the code) This seems like a non-issue if you are careful about your dependencies (and specifically, their licenses (which seems to be easy to tell now that pkg.go.dev will flag unrecognized licenses)). > When you read that, you may decide to just track the vendor/ folder in > your repo and forget about proxies for OSS projects. > > What is the recommendation from the Go community about this? > > - Are there public go proxies can be used for OSS projects ensuring you > will never lose any dependency? > > - Is https://goproxy.io/ giving such guarantee maybe? > > - Should we just vendor and forget about Go-Proxies for Open Source? > Now that Go Modules is relatively mature, please don't use vendoring in open source projects unless you have a really good reason. Vendoring makes it impossible for the rest of us to tell whether there are modifications to those dependencies and blows up your repo's size at the same time. (at least without some really complicated diffing) > Thanks, > > Jose > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/47c445ca-884d-49b5-8357-aeae8802e937n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/47c445ca-884d-49b5-8357-aeae8802e937n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANrC0BizsWRjdZSKXBqCKikhHcNbyWpP9d_pnr7odK3YQq_xgA%40mail.gmail.com.
