7 ms·

Recently found a command line library written in go that was so useful to me in a python webapp I'm building, I decided to just wrap the go app and call it from

Recently found a command line library written in go that was so useful to me in a python webapp I'm building, I decided to just wrap the go app and call it from a python subprocess. It is a bit slow to do it this way, but premature optimization, and all that. Anyhow, the bottom line is due to this I was forced to get a handle on Go this week so I could at least build the go library and make a few changes as needed. Wow, was I absolutely shocked to find out current package management in this go app is just pulling libraries from master on github. It really made me feel like go is far behind python in maturity. Pulling all these dependency libs from master definitely does not feel production ready. Maybe this will help resolve things.

aczerepinski 8y ago
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++?
- 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).
tomohawk 8y ago
I was likewise shocked at how good go compared to python in this regard. Resolve your deps once, at build time, and you're done. Compare that to dealing with the externalized deps that is deploying a python app on a machine that might have the correct version of python and all dependencies, or not. virtualenv? good luck. You end up bringing in docker and other tools just to deal with it. But what do you do if the machine is locked down by corporate IT and they don't allow docker or the installation of other python deps?
- orf 8y ago
  Pipenv.
  - weberc2 8y ago
    We use pipenv, but it's been buggy and quarelsome so far. I like what it promises to do, but so far my experiences with Go modules have been better (to my surprise, given how much newer Go modules are than pipenv).
- collinvandyck76 8y ago
  > at build time Unless you're using CGO, in which case you still have to make sure your target environment has the shared libraries your bindings will make calls to.
  - deleted 8y ago
    [deleted]
  - weberc2 8y ago
    Isn't this true for Python as well?
  - bitwalker 8y ago
    Unless you statically link your dependencies, but that comes with its own can of worms.
- mylons 8y ago

aczerepinski 8y ago

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++?
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).

tomohawk 8y ago

I was likewise shocked at how good go compared to python in this regard. Resolve your deps once, at build time, and you're done. Compare that to dealing with the externalized deps that is deploying a python app on a machine that might have the correct version of python and all dependencies, or not. virtualenv? good luck. You end up bringing in docker and other tools just to deal with it. But what do you do if the machine is locked down by corporate IT and they don't allow docker or the installation of other python deps?

orf 8y ago
Pipenv.
- weberc2 8y ago
  We use pipenv, but it's been buggy and quarelsome so far. I like what it promises to do, but so far my experiences with Go modules have been better (to my surprise, given how much newer Go modules are than pipenv).
collinvandyck76 8y ago
> at build time Unless you're using CGO, in which case you still have to make sure your target environment has the shared libraries your bindings will make calls to.
- deleted 8y ago
  [deleted]
- weberc2 8y ago
  Isn't this true for Python as well?
- bitwalker 8y ago
  Unless you statically link your dependencies, but that comes with its own can of worms.
mylons 8y ago