1. 7
  1.  

  2. 2

    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:

    1. 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.
    2. 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.

    1. 8

      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 hope this helps clear things up.

      1. 1

        Thank you Peter; you’re very helpful as usual. :-)

      2. 3

        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:

        1. What if everyone did what you did?
        2. What if I am maintaining an open source library that has dependencies?
        3. What if I am maintaining an open source library that has public dependencies?
        4. Compare and contrast the processes for incorporating a new patch release from upstream.
        1. 1

          Go doesn’t care how the files get there; git subtree would do more-or-less what you’ve described, I think.

        2. 2

          Glide is pretty decent option right now: https://github.com/Masterminds/glide