I have a sincere question on this topic, and one born from my potential lack of knowledge and understanding around here. Vendoring in the go tools way is as I understand it essentially a forking process. The whole mystery behind vendoring seems to be asking the Golang tool kit to provide a technical solution to something that is as I understand it not actually a new logistics problem.
What I’ve always done to this point if I absolutely needed to ensure an external dependency is preserved, is to fork the project into a repo under my own control.
My rationale is as follows:
If the library I depend on belongs to my organization forking isn’t necessary and I can just depend on pinning my import to a particular tag. I can rely on those in my organization responsible for that library. No forking required.
If the library I depend on belongs to an external organization then relying on them isn’t the safest option for the long-term preservation of my project.
I accept I may not understand things here. Please educate me. :-)
TL;DR, If you want to guarantee the mere presence of or a particular state of a library your Golang project depends on, or indeed your project in any other language for that matter, just fork it, tag it, and use your fork in the import.
Vendoring is “essentially a forking process” as it is implemented, but I think it’s a mistake to consider it a forking process semantically. The vendored copy should be understood as a static snapshot of an upstream: while technically you could modify it in place, you almost certainly shouldn’t.
Beyond that, you outline a totally acceptable approach. Many organizations share your view and “vendor” by maintaining a private CI server from which all dependencies must be taken. But the overhead for forking/tagging a dependency is definitely higher than bringing a specific copy of that dep into your repo. Not everyone can or should opt-in to maintaining private forks of their deps for all of their projects. Especially transitively! Goodness.
Bear in mind also that dep is about managing dependencies, ultimately a higher level of abstraction than the dirty business of repos and forks. The current mechanism of vendoring repos into the vendor/ subdirectory is an implementation detail. It will certainly change in a [far future] version of the dep tool.
I have a sincere question on this topic, and one born from my potential lack of knowledge and understanding around here. Vendoring in the go tools way is as I understand it essentially a forking process. The whole mystery behind vendoring seems to be asking the Golang tool kit to provide a technical solution to something that is as I understand it not actually a new logistics problem.
What I’ve always done to this point if I absolutely needed to ensure an external dependency is preserved, is to fork the project into a repo under my own control.
My rationale is as follows:
I accept I may not understand things here. Please educate me. :-)
TL;DR, If you want to guarantee the mere presence of or a particular state of a library your Golang project depends on, or indeed your project in any other language for that matter, just fork it, tag it, and use your fork in the import.
Vendoring is “essentially a forking process” as it is implemented, but I think it’s a mistake to consider it a forking process semantically. The vendored copy should be understood as a static snapshot of an upstream: while technically you could modify it in place, you almost certainly shouldn’t.
Beyond that, you outline a totally acceptable approach. Many organizations share your view and “vendor” by maintaining a private CI server from which all dependencies must be taken. But the overhead for forking/tagging a dependency is definitely higher than bringing a specific copy of that dep into your repo. Not everyone can or should opt-in to maintaining private forks of their deps for all of their projects. Especially transitively! Goodness.
Bear in mind also that
depis about managing dependencies, ultimately a higher level of abstraction than the dirty business of repos and forks. The current mechanism of vendoring repos into the vendor/ subdirectory is an implementation detail. It will certainly change in a [far future] version of thedeptool.I hope this helps clear things up.
Thank you Peter; you’re very helpful as usual. :-)
I think you’ve outlined a reasonable approach for some use cases. It’s simple and it can work well. However, consider some of these points:
Go doesn’t care how the files get there; git subtree would do more-or-less what you’ve described, I think.
Glide is pretty decent option right now: https://github.com/Masterminds/glide