Hacker News new | ask | show | jobs
by willnorris 4263 days ago
Yes, we do vendor everything, in that we have a snapshot of all of our dependencies in our source control system. But we do it across the entire codebase, not per project. That is, we typically only ever have a single version of a library for the entire company (with a few exceptions). If a project needs to update to a later version, they basically update everyone using that library. For widely used packages, this can sometimes be a time consuming process, but we've found it to be preferable to the alternative of having version conflicts all over the place. This is generally true not just for Go, but all languages. So the idea of a project needing to pin to a very specific version of a dependency and never update doesn't really fly.
1 comments
Touche 4263 days ago
That sounds like a wildly unproductive way to work. Discourages ever changing anything.
link
wmf 4263 days ago
It sounds similar to the Linux kernel. If all the providers and consumers of an API are in the same repository, then you can change an API at any time as long as you update all consumers of the API at the same time.
link
ninkendo 4263 days ago
It also results in having a huge version control repo. From what I've heard, Google can't move to git because of this... they're stuck with Perforce because it's the only VCS that can support a repo of their size.
link
skybrian 4263 days ago
It does discourage upgrading until you really need it. On the other hand, if one person decides to do the work then everyone benefits.
link
noselasd 4263 days ago
That sounds quite implausible. Sure, one person can go and upgrade the library.

But I find it hard to believe that one person can go and fix up all the projects he's hardly ever heard of that depends on that library.

link
skybrian 4262 days ago
We have good tools for this. A Googler can create a patch that upgrades a library and run tests for all projects to see what breaks. The project owners review the changes. Of course, some upgrades are easier than others.

In some ways this is similar to what Linux distros do, but sharing common source control, build system, and test runner makes it easier.

link