5 ms·

Isn't "go get ..." the dependency management tool for Go?

• pjmlp 12y ago
  Not really. Only works for source code packages, not binary dependencies. There isn't a way to specific source code versions/tags in a portable way. Also makes the import paths dependent on your repositories.
  • sagichmal 12y ago
    > [go get] Only works for source code packages, not > binary dependencies. There's no such thing as a binary dependency in the Go ecosystem. (At least, not without stretching some definitions.) It's one of Go's greatest strengths, actually. > There isn't a way to specific source code versions/tags > in a portable way. Well, the best practice is to vendor[0], and there are plenty of third-party tools like godep[1] that can manage it for you. ___ [0] http://peter.bourgon.org/go-in-production/#dependency-management http://peter.bourgon.org/go-in-production/#dependency-manage... [1] https://github.com/tools/godep https://github.com/tools/godep
    • pjmlp 12y ago
      Vendoring is a practice stuck in C and C++ archaic tooling support ideas. I am on the side for proper dependency management. > It's one of Go's greatest strengths, actually. Which will keep it outside the boring closed source enterprise commercial library tooling.
      • dsymonds 12y ago
        Vendoring is also a practice that Google and other large tech companies use extensively. Just because something is old doesn't mean it's a bad idea.
        • pjmlp 12y ago
          My C, C++ and Java Ant scars in Fortune 500 consulting projects tell me otherwise.
          • dsymonds 12y ago
            That's fine. Some do it badly, and some do it well.
            • pjmlp 12y ago
              So why is Google moving away from Ant to Gradle in Android, while having Pub Packages for Dart? Does not seem very supportive of vendoring.
              • dsymonds 12y ago
                I don't know anything about Android or Dart development, so I can't speak for them. All I can say is that internal Google development has been happily using vendoring of third-party code for many years (and not just C/C++ code), so I'm confident in saying that vendoring Go code can work just fine for "boring closed source enterprise commercial library tooling".
      • sagichmal 12y ago
        > I am on the side for proper dependency management. Vendoring is one of several proper dependency management options. It's also the option most suited to the Go ecosystem at this time.
        • coldtea 12y ago
          Responses to dependency management and generics from Go supporters always sound like la-la-la hands-in-the-ears denial to me. "X? We don't need no stinkin' X".
          • sagichmal 12y ago
            It's true: not all features yield net benefit.
            • NateDad 12y ago
              My car doesn't have a blender, a mini-fridge, or a hot tub. Some cars do. I don't think my car is worse off because of their lack. Along the same lines, my mother used to always buy cars that were manual transmission and without power windows or locks, because they were features which made the car cost more, broke often, and were expensive to fix. The minor conveniences they afforded were not worth the costs.
      • NateDad 12y ago
        I'm curious to know what you think proper dependency management looks like.
• rm445 12y ago
  It is, but it doesn't do versioning, and people often like to target specific versions of the libraries that their programs depend on.