4 ms·

> And the "just vendor" stuff pushed by some Go pundits is stupid. I see it as an excellent way to allow me to ensure that no matter what my project continues

> And the "just vendor" stuff pushed by some Go pundits is stupid. I see it as an excellent way to allow me to ensure that no matter what my project continues to build and work. And dont say "just pin a version" because there have been packages that lose or update their tags and break things, or the distribution channel (npmjs, github, w/e) go down and suddenly I am up a creek for a deploy/build. When I vendor, I have what I need to build and deploy my code with a lot fewer points of failure.

nyan4 10y ago
...until the unfortunate end user that needs to run tenths of systems runs in a security issue. Then the admins cannot possibly learn how to fork, patch, rebuild, test, deploy in 20 different languages. And they cannot rely on security updates from Linux Distributions because they installed vendorized code blobs.
- zwily 10y ago
  This has more to do with the lack of dynamic linking than vendoring.
  - nyan4 10y ago
    The two are very connected. Yet, even with dynamic linking, the libraries could be always and only bundled with the application, and the application could be designed to work against the bundled versions and not even tested against other versions. On a practical level this makes it extremely expensive to perform updates.
- skybrian 10y ago
  Vendoring is what Linux distributions do. They also provide multi-language automatic builds, security updates and all the other things you mention. So the problem is not vendoring itself. For a large organization like a Linux distribution, it's a valid technique. However, nobody is maintaining a distribution for the Go ecosystem, or at least not one that's publically available.
bbatha 10y ago
vendoring is a solution to the problem of reproducability, not the problem of distribution. Vendoring particularly for application code should be at least an optional part of whatever solution is chosen by the go team. Vendoring is not the only solution in this space, at $work we mirror any third party repository we use. However, vendoring doesn't solve the problem of getting a library that I have reasonable guarantees will work with the rest of the ecosystem. You can use vendoring in libraries but you can only use their types internally in your apis, if you put them on the boundaries you will run into compatibility issues.
rat87 10y ago
Most systems have package managers with versions and a central repo and dependency tracking. Problems with fetching builds are rare but if you care package managers frequently have some not exactly recommended plugin to allow vendoring. Plus with the package manager you can update the optionally vendored dependencies quickly. Central repos are less likely to be deleted then github repos and some like Crates.io have a policy not to remove crates(or allow authors to remove crates) unless there are legal issues. A better solution (then vendoring) for larger organizations that is also usually available in the form of mirroring or partial mirroring of the central repository(and pulling from that instead).

nyan4 10y ago

...until the unfortunate end user that needs to run tenths of systems runs in a security issue. Then the admins cannot possibly learn how to fork, patch, rebuild, test, deploy in 20 different languages. And they cannot rely on security updates from Linux Distributions because they installed vendorized code blobs.

zwily 10y ago
This has more to do with the lack of dynamic linking than vendoring.
- nyan4 10y ago
  The two are very connected. Yet, even with dynamic linking, the libraries could be always and only bundled with the application, and the application could be designed to work against the bundled versions and not even tested against other versions. On a practical level this makes it extremely expensive to perform updates.
skybrian 10y ago
Vendoring is what Linux distributions do. They also provide multi-language automatic builds, security updates and all the other things you mention. So the problem is not vendoring itself. For a large organization like a Linux distribution, it's a valid technique. However, nobody is maintaining a distribution for the Go ecosystem, or at least not one that's publically available.

bbatha 10y ago

vendoring is a solution to the problem of reproducability, not the problem of distribution. Vendoring particularly for application code should be at least an optional part of whatever solution is chosen by the go team. Vendoring is not the only solution in this space, at $work we mirror any third party repository we use. However, vendoring doesn't solve the problem of getting a library that I have reasonable guarantees will work with the rest of the ecosystem. You can use vendoring in libraries but you can only use their types internally in your apis, if you put them on the boundaries you will run into compatibility issues.

rat87 10y ago

Most systems have package managers with versions and a central repo and dependency tracking. Problems with fetching builds are rare but if you care package managers frequently have some not exactly recommended plugin to allow vendoring. Plus with the package manager you can update the optionally vendored dependencies quickly. Central repos are less likely to be deleted then github repos and some like Crates.io have a policy not to remove crates(or allow authors to remove crates) unless there are legal issues. A better solution (then vendoring) for larger organizations that is also usually available in the form of mirroring or partial mirroring of the central repository(and pulling from that instead).