That's kind of the problem - well, issue - that I'm worried about. Now you have to do some special things in your build environment to vendor stuff (set env variables, compiler options), and by default your build infrastructure is depending on supposedly always-on external services.

I rather think it should be the other way around. By default your build environment should gather all required artifacts locally, and only if you want to depend on external services should you have to create non-default options.

I would have been slightly happier of vendoring was the default happy path, and module proxies were an alternative.

I wonder if Google folks are subconsciously influenced by the idea that all this infrastructure will exist forever and never decay because they have access to seemingly infalible and highly available Google services. The gradual decay of Perl CPAN (which I've always loved BTW) and the reliability/security issues with the Node ecosystem are instructive counterexamples.

I have to say that I'm not dogmatic about this, there are good cases to be made for certain features which go with module proxies. But ultimately if you've got a long running business you now have to do more work to make sure your code will still compile in 5 years - e.g. create and maintain a module proxy service in perpetuity. This as opposed to just archiving a bunch of files organized as a git repo.

Anyway, my experience says vendor all the things. You'll be glad you did.

> I thought vendoring was being deprecated in favor of modules. Maybe I misunderstood though.

The original proposal (or sketch) of modules eliminated vendoring. It was quickly updated to include support for vendoring in response to feedback.

The decision not to use vendoring (by default) has been controversial. That said, vendoring isn't "deprecated" in the sense that Go modules still allow for vendoring; they just happen not to vendor by default.