5 ms·

Agreed. In addition I hope they provide a blog post about best practices w.r.t. vendoring in order to explain the problem and solution in more depth to a wider

by s3th 11y ago

Agreed. In addition I hope they provide a blog post about best practices w.r.t. vendoring in order to explain the problem and solution in more depth to a wider audience than the initial design doc.

driusan 11y ago
I don't think it's as obscure as a problem as you think. I've been trying to learn Go as a sideproject for less than a month, and even I realize what the problem is and how the vendor spec solves it (at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.) One of the things I miss the most when working in Go is PHP Composer, and it's pretty obvious how the vendor design doc solves the same problem in a more Go idiomatic way.
- mfer 11y ago
  Composer (or the alternatives for other languages) do more than the vendor/ directories do. Those tools manage the versions in the directories which are important for compatibility, ensuring versions around security issues, and so on. Glide[1] is a tool like Composer but for Go and it uses the vendor/ directory. It's designed to complement the go commands. disclosure: I'm one of the glide devs [1] https://github.com/Masterminds/glide https://github.com/Masterminds/glide
  - driusan 11y ago
    Submodules in git specify the specific commit to be checked out and don't automatically track the HEAD of a branch (unlike go get.) That's why I include the statement that Go vendoring is useful "(at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.)"
    - mfer 11y ago
      Submodules and even subtrees can be useful ways to link repos. But, I'm wary of commit ids as versions. From a commit id you can't tell if the version you can is after the version that fixed a security issues. You can't tell what version of the interface to the package you're using. The meaning we are able to pull from and even compare with version number is missing. And, submodules are pinned to commit ids.
      - driusan 11y ago
        I see where you're coming from and agree that commit IDs aren't very friendly, but from a technical perspective it solves the same problem of having dependencies on specific versions of software. Now that I've looked into glide a little more I'm curious: since the main benefit is the ability to use semantic versioning to manage your dependencies, why do you use a glide.lock file instead of making the "glide" command a simplified way to update/maintain vendor submodule references with semantic versioning? Then users wouldn't need the glide tool, only developers, and users could just use standard go tools.
        mfer 11y ago
        A few reasons we don't just use submodules - The Go community supports Git, Svn, Bzr, and Hg. We keep that up. According to the Eclipse community survey, 2014 was the year Git usage passed Svn usage. Svn usage is still quite high. - A lot of developers struggle with and even have strong negative opinions of submodules. So much so that we now have subtrees. I've find a lot of developers would prefer not to use them. - The way Glide works is in line with the package managers from the other major/popular languages. This way it's familiar to many people coming to Go by solving the same problem in the same way they're already used to.
      - koenigdavidmj 11y ago
        Typical Git usage is to create a tag for every release, giving it a nicer name than a raw SHA1 sum. You can check out a submodule to such a tag too.
  - awinograd 11y ago
    Thanks for glide! We're using it at Quizlet for our go builds and are fans. In conjunction with vendoring, makes it easy to have reproducible builds over time. Also, there's some good discussion of other approaches to dependency management on the go forum: https://forum.golangbridge.org/t/the-best-dependency-manager/1281/18 https://forum.golangbridge.org/t/the-best-dependency-manager...
mfer 11y ago
The go core team may not be the best group to describe the best practices. At Google they work on a large monorepo and don't do distributed packages the way many others do. They aren't intimately familiar with the problem and solution. I would expect the best patterns to come from the community which is something Rob Pike pointed to at the first Gophercon.

by s3th 11y ago

Agreed. In addition I hope they provide a blog post about best practices w.r.t. vendoring in order to explain the problem and solution in more depth to a wider audience than the initial design doc.

driusan 11y ago

I don't think it's as obscure as a problem as you think. I've been trying to learn Go as a sideproject for less than a month, and even I realize what the problem is and how the vendor spec solves it (at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.) One of the things I miss the most when working in Go is PHP Composer, and it's pretty obvious how the vendor design doc solves the same problem in a more Go idiomatic way.

mfer 11y ago
Composer (or the alternatives for other languages) do more than the vendor/ directories do. Those tools manage the versions in the directories which are important for compatibility, ensuring versions around security issues, and so on. Glide[1] is a tool like Composer but for Go and it uses the vendor/ directory. It's designed to complement the go commands. disclosure: I'm one of the glide devs [1] https://github.com/Masterminds/glide https://github.com/Masterminds/glide
- driusan 11y ago
  Submodules in git specify the specific commit to be checked out and don't automatically track the HEAD of a branch (unlike go get.) That's why I include the statement that Go vendoring is useful "(at least once getting to the end where it says that with vendoring enabled submodules are automatically retrieved with go get.. I don't know why they didn't get to that earlier.)"
  - mfer 11y ago
    Submodules and even subtrees can be useful ways to link repos. But, I'm wary of commit ids as versions. From a commit id you can't tell if the version you can is after the version that fixed a security issues. You can't tell what version of the interface to the package you're using. The meaning we are able to pull from and even compare with version number is missing. And, submodules are pinned to commit ids.
    - driusan 11y ago
      I see where you're coming from and agree that commit IDs aren't very friendly, but from a technical perspective it solves the same problem of having dependencies on specific versions of software. Now that I've looked into glide a little more I'm curious: since the main benefit is the ability to use semantic versioning to manage your dependencies, why do you use a glide.lock file instead of making the "glide" command a simplified way to update/maintain vendor submodule references with semantic versioning? Then users wouldn't need the glide tool, only developers, and users could just use standard go tools.
      - mfer 11y ago
        A few reasons we don't just use submodules - The Go community supports Git, Svn, Bzr, and Hg. We keep that up. According to the Eclipse community survey, 2014 was the year Git usage passed Svn usage. Svn usage is still quite high. - A lot of developers struggle with and even have strong negative opinions of submodules. So much so that we now have subtrees. I've find a lot of developers would prefer not to use them. - The way Glide works is in line with the package managers from the other major/popular languages. This way it's familiar to many people coming to Go by solving the same problem in the same way they're already used to.
    - koenigdavidmj 11y ago
      Typical Git usage is to create a tag for every release, giving it a nicer name than a raw SHA1 sum. You can check out a submodule to such a tag too.
- awinograd 11y ago
  Thanks for glide! We're using it at Quizlet for our go builds and are fans. In conjunction with vendoring, makes it easy to have reproducible builds over time. Also, there's some good discussion of other approaches to dependency management on the go forum: https://forum.golangbridge.org/t/the-best-dependency-manager/1281/18 https://forum.golangbridge.org/t/the-best-dependency-manager...

mfer 11y ago

The go core team may not be the best group to describe the best practices. At Google they work on a large monorepo and don't do distributed packages the way many others do. They aren't intimately familiar with the problem and solution. I would expect the best patterns to come from the community which is something Rob Pike pointed to at the first Gophercon.