5 ms·

I don't think your impression of the current state of dependency management in Go is accurate. Pretty much everybody uses this: https://golang.github.io/dep/do

I don't think your impression of the current state of dependency management in Go is accurate. Pretty much everybody uses this: https://golang.github.io/dep/docs/Gopkg.lock.html https://golang.github.io/dep/docs/Gopkg.lock.html

the_duke 8y ago
Some do, but many don't.
- yahyaheee 8y ago
  Every major stable library uses a form of package management. Anyone pulling from master is a new go developer
  - wereHamster 8y ago
    The fact that new go developers do that tells a lot about the state of documentation, tutorials, tooling etc. A language and its ecosystem should encourage best practices from the start. Not as some kind of late afterthought.
    - yahyaheee 8y ago
      Yeah thats the problem they have been looking to solve for a couple years now, but for what its worth the https://github.com/golang/go/wiki https://github.com/golang/go/wiki has information on dep tooling. My experience is that most people don't read it. Any tutorial worth its salt will mention this as well. Go has made it possible to pull right from master on deps fairly easily so many new developers do that so they don't have to learn dependency management. Proper dependency management is a skill that must be learned in any language, and often separates an entry developer from a mid level one.
      - wereHamster 8y ago
        There are many languages that make it explicitly difficult to pull directly from master. Nodejs packages are near impossible to install directly from a repository, you always have to go through npmjs.com. Haskell too (before stack became widespread), but even now most people install packages from hackage/stackage, where packages are strongly versioned.
        yahyaheee 8y ago
        This is where opinions will differ, I quite like go's ability to pull straight from a repository, and see outcomes like this as an unfortunate side effect of that feature. If a developer doesn't understand proper git and package versioning they will have a hard time in any language producing quality software. I'm not sure I want to give up the speed and ease of `go get` just to protect entry developers.
        masklinn 8y ago
        > This is where opinions will differ, I quite like go's ability to pull straight from a repository Having the ability to do so does not mean it should be the easiest and simplest way to get from A to B. Both pip and cargo can pull from repositories, but it's not the default and it's basically not covered in any tutorial. It's easy to do, but a developer is unlikely to find the information before they're actively looking for it. > If a developer doesn't understand proper git and package versioning they will have a hard time in any language producing quality software. I don't understand why you're using Go if your teaching methodology is to throw live chainsaws at people and berate them for not understanding proper power tool safety, why are you not just cutting out the middleman and using C++?
        yahyaheee 8y ago
        :sigh: clearly you just don't like Go, which is fine. Of all the languages I've picked up Go was far and away the simplest and most productive, which is why I continue to use it. When I wrote python we were constantly using pip to pull from repos, so moving to Go I liked their repository centric view. Just because python recommends pip, doesn't mean junior devs don't totally botch dependency management with it. Dep management and git are core skills developers need to learn well to produce good software. There is simply no substitute for a bit of elbow grease on the matter. I'm not berating anyone, software is hard and being good at it means taking the time to learn some core tools.
    - weberc2 8y ago
      I disagree with your characterization. `go get` is the right tool for new developers (hell, I've been using Go for 7 years and I still use `go get` for the initial phase of my projects); they don't need reproducible builds, they need to install third party libraries and compile code. The current official reproducible build tooling in Go is vendoring, and that's quite unnecessarily painful for the things new developers need to do. Fortunately, Go 1.11 will be out soon with support for modules, so new developers can learn how to install code with the added bonus of not needing to learn a new set of tools down the road when they need to care about reproducibility.
rustyfe 8y ago
I would say the state of Go dependency management is somewhere between what GP implies: "everyone is using go get to run things directly from master and that's terrible" and what you imply: "everyone has standardized around dep and that's fine". I picked 5 "important" Go projects without checking first, and here's the solutions they use: Kubernetes: The deprecated tool Godep + a pile of Make and Bash (which is the Go-est thing I've ever heard in my life) Docker (Moby): vndr Hugo: dep Etcd: A bit of a mish-mash of dep and vndr, but mostly dep. Cobra: Doesn't vendor dependencies, isn't a reproducible build (which is somewhat okay, as Cobra is primarily a library, not a tool in and of itself, but it does also have a CLI that probably breaks a lot). In short, things are not currently fine. Dep is an okay tool, but fails for some use cases, and the community has not really rallied around it. Lots of important projects are sticking with what they've got. Glide, gvt, vndr, and Godep all remain important. We're deluding ourselves if we discard an outsider's view that Go's dependency management situation is a dumpster fire, because it is. However, to GP, it isn't quite as bad as you suggest, most projects using Go have found some way or another of getting reproducible builds, and don't just run everything from tip of everyone else's master. I am cautiously optimistic that modules will finally solve this mess, but we'll see to what extent they win in the marketplace of dependency management solutions.
- mylons 8y ago
  this is an accurate assessment. i work in the dystopia of microservices and every service has it's own unique build. Godep, dep, glide, make files, you name it. it's a total dumpster fire.
- zumu 8y ago
  > Kubernetes: The deprecated tool Godep + a pile of Make and Bash (which is the Go-est thing I've ever heard in my life) I haven't written Go in a couple years, but I lol'd. This exactly what we used to do, except replace Godep with glide.
- atombender 8y ago
  Note that the Kubernetes people tried to migrate to Dep, but weren't successful. As I recall, it was due to several blocking issues (e.g. see https://github.com/kubernetes/client-go/issues/7 https://github.com/kubernetes/client-go/issues/7).

the_duke 8y ago

Some do, but many don't.

yahyaheee 8y ago
Every major stable library uses a form of package management. Anyone pulling from master is a new go developer
- wereHamster 8y ago
  The fact that new go developers do that tells a lot about the state of documentation, tutorials, tooling etc. A language and its ecosystem should encourage best practices from the start. Not as some kind of late afterthought.
  - yahyaheee 8y ago
    Yeah thats the problem they have been looking to solve for a couple years now, but for what its worth the https://github.com/golang/go/wiki https://github.com/golang/go/wiki has information on dep tooling. My experience is that most people don't read it. Any tutorial worth its salt will mention this as well. Go has made it possible to pull right from master on deps fairly easily so many new developers do that so they don't have to learn dependency management. Proper dependency management is a skill that must be learned in any language, and often separates an entry developer from a mid level one.
    - wereHamster 8y ago
      There are many languages that make it explicitly difficult to pull directly from master. Nodejs packages are near impossible to install directly from a repository, you always have to go through npmjs.com. Haskell too (before stack became widespread), but even now most people install packages from hackage/stackage, where packages are strongly versioned.
      - yahyaheee 8y ago
        This is where opinions will differ, I quite like go's ability to pull straight from a repository, and see outcomes like this as an unfortunate side effect of that feature. If a developer doesn't understand proper git and package versioning they will have a hard time in any language producing quality software. I'm not sure I want to give up the speed and ease of `go get` just to protect entry developers.
        masklinn 8y ago
        > This is where opinions will differ, I quite like go's ability to pull straight from a repository Having the ability to do so does not mean it should be the easiest and simplest way to get from A to B. Both pip and cargo can pull from repositories, but it's not the default and it's basically not covered in any tutorial. It's easy to do, but a developer is unlikely to find the information before they're actively looking for it. > If a developer doesn't understand proper git and package versioning they will have a hard time in any language producing quality software. I don't understand why you're using Go if your teaching methodology is to throw live chainsaws at people and berate them for not understanding proper power tool safety, why are you not just cutting out the middleman and using C++?
        yahyaheee 8y ago
        :sigh: clearly you just don't like Go, which is fine. Of all the languages I've picked up Go was far and away the simplest and most productive, which is why I continue to use it. When I wrote python we were constantly using pip to pull from repos, so moving to Go I liked their repository centric view. Just because python recommends pip, doesn't mean junior devs don't totally botch dependency management with it. Dep management and git are core skills developers need to learn well to produce good software. There is simply no substitute for a bit of elbow grease on the matter. I'm not berating anyone, software is hard and being good at it means taking the time to learn some core tools.
  - weberc2 8y ago
    I disagree with your characterization. `go get` is the right tool for new developers (hell, I've been using Go for 7 years and I still use `go get` for the initial phase of my projects); they don't need reproducible builds, they need to install third party libraries and compile code. The current official reproducible build tooling in Go is vendoring, and that's quite unnecessarily painful for the things new developers need to do. Fortunately, Go 1.11 will be out soon with support for modules, so new developers can learn how to install code with the added bonus of not needing to learn a new set of tools down the road when they need to care about reproducibility.

rustyfe 8y ago

I would say the state of Go dependency management is somewhere between what GP implies: "everyone is using go get to run things directly from master and that's terrible" and what you imply: "everyone has standardized around dep and that's fine". I picked 5 "important" Go projects without checking first, and here's the solutions they use: Kubernetes: The deprecated tool Godep + a pile of Make and Bash (which is the Go-est thing I've ever heard in my life) Docker (Moby): vndr Hugo: dep Etcd: A bit of a mish-mash of dep and vndr, but mostly dep. Cobra: Doesn't vendor dependencies, isn't a reproducible build (which is somewhat okay, as Cobra is primarily a library, not a tool in and of itself, but it does also have a CLI that probably breaks a lot). In short, things are not currently fine. Dep is an okay tool, but fails for some use cases, and the community has not really rallied around it. Lots of important projects are sticking with what they've got. Glide, gvt, vndr, and Godep all remain important. We're deluding ourselves if we discard an outsider's view that Go's dependency management situation is a dumpster fire, because it is. However, to GP, it isn't quite as bad as you suggest, most projects using Go have found some way or another of getting reproducible builds, and don't just run everything from tip of everyone else's master. I am cautiously optimistic that modules will finally solve this mess, but we'll see to what extent they win in the marketplace of dependency management solutions.

mylons 8y ago
this is an accurate assessment. i work in the dystopia of microservices and every service has it's own unique build. Godep, dep, glide, make files, you name it. it's a total dumpster fire.
zumu 8y ago
> Kubernetes: The deprecated tool Godep + a pile of Make and Bash (which is the Go-est thing I've ever heard in my life) I haven't written Go in a couple years, but I lol'd. This exactly what we used to do, except replace Godep with glide.
atombender 8y ago
Note that the Kubernetes people tried to migrate to Dep, but weren't successful. As I recall, it was due to several blocking issues (e.g. see https://github.com/kubernetes/client-go/issues/7 https://github.com/kubernetes/client-go/issues/7).