3 ms·
> What's the reason for yet another utility? > Some copy the source code of dependencies into the vendor directory: I don't agree with any of the stated probl
by vruiz 10y ago
> What's the reason for yet another utility?
> Some copy the source code of dependencies into the vendor directory:
I don't agree with any of the stated problems there. Unless you are building a library you should commit your dependencies and not rely on third party repos being available.
I can't stress enough how useful govendor [1] is if you do Go professionally.
[1] https://github.com/kardianos/govendor https://github.com/kardianos/govendor
- boomlinde 10y agoCopying the source code of the dependencies into your repo isn't the only alternative to relying on third party repositories, though. You could fork the dependencies that you work with into locally managed repos and use submodules to include them in your own project. That way you can easily update your dependencies without breaking everything and also maintain their commit history.
- vruiz 10y agoThat's how we started back in the day. It works but setting up everything and doing the rebase/commit dance to update can be quite cumbersome when you have more than a couple dependencies. Nothing wrong with it if you are willing to do the work though.
- bmon 10y agoDoes the go toolchain allow you to freeze your dependencies to specific versions like pip, etc? I think that could be preferable to committing all your dependencies.
- vruiz 10y agoThe go toolchain doesn’t but many of these vendoring tools do something similar. But you still don’t want to depend on the origin repo being up and have missing/altered repos break your builds.