~skeeto/public-inbox

1

Re: Go's Tooling is an Undervalued Technology

Details
Message ID
<87pnfb69f3.fsf@bernat.ch>
DKIM signature
missing
Download raw message
The vendoring is still controversial. Notably, it makes the git
repository bigger, pollutes diff and makes merge requests more
difficult. But the tooling around Go is now very good for it. Notably,
you can be sure vendored dependencies are pristine.

Re: Go's Tooling is an Undervalued Technology

Details
Message ID
<20200122161125.7enac4n5rsxfnhg7@nullprogram.com>
In-Reply-To
<87pnfb69f3.fsf@bernat.ch> (view parent)
DKIM signature
missing
Download raw message
I agree, those are definitely all downsides to vendoring. I don't think 
it's appropriate for, say, open source projects that are collaborated 
upon over the internet. Though it's a trade-off, and in certain other 
situations — offline development, offline builds, etc. — it's worth 
accepting those downsides. It was one of those situations where I 
learned about "go mod vendor".

In my article I was specifically highlighting the case where you *don't* 
check them into source control, just distribute them in your a release 
tarball, so it has none of the downsides except making the "standalone" 
release tarball bigger. Future archivists would probably love to find 
these kinds of releases.