The problem with dependencies is that you can control what you depend on directly, but not what those dependencies depend on.
I understand what you are basically saying is https://proxy.golang.org should be safe as long as all your dependencies, including transitive ones, have proper licenses. Still, if you want to ensure your open source project will always compile, vendoring still seems like the simplest way forward. > 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) Indeed, all true. All specially important to consider if you are writing a library rather than a final program such as a CLI. That is why it would be great if there were a public proxy infrastructure that would blindly retain ANY code seen forever, the same way a private proxy would. Because if that does not exist, the incentives for people to do the right thing are against the odds, IMHO. On the other hand, such an infrastructure may lead to go open source projects not grooming their dependencies properly. Using unlicensed code, even indirectly, should be considered a liability even before such code might actually disappear. That aside of the fact that such public infra is given away for free and potentially growing storage needs without control. Tough call I guess. Thanks, Jose El viernes, 25 de junio de 2021 a las 22:54:56 UTC+2, david....@gmail.com escribió: > On Fri, Jun 25, 2021 at 1:23 PM josvazg <jos...@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...@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/57088582-e03b-4fdb-9746-e5413dea7e28n%40googlegroups.com.
