5 ms·
Honestly, with the release of Go 1.5, I've taken to using "go get" once to download the library, copy it over into the vendor folder, remove its .git folder, an
by dradtke 11y ago
Honestly, with the release of Go 1.5, I've taken to using "go get" once to download the library, copy it over into the vendor folder, remove its .git folder, and commit the whole thing to source control. It's easier than messing with version numbers or commit hashes, and more stable than always using the latest master.
- cakeface 11y agoI really like this approach and it reminds me of the approach that Google takes with their versioning. Everything in one giant source repository. It has a nice effect where every change to a library requires a commit which can trigger a build. There are no hidden updates.
- vinceguidry 11y agoIt puts you in the driver's seat of dependency managing, but now you have to be a lot more careful to actually update them when the time comes. If you tend to put something into production and leave it there for months / years, coming back to do maintenance will be a real chore. With Ruby I can 'bundle update', run the tests, and have reasonable certainty that everything's working. If I took over a Ruby project with vendored gems I'd mark them all for replacement for standard Bundler-managed gems at first opportunity. Vendored code has a bad tendency to become 'unmaintained code' otherwise. Just because it works and is stable doesn't mean it doesn't have security vulns.