4 ms·

I've wondered what the story was on Go's dependency management, so I'm glad someone brought it up at the end of the keynote. Pike said that it was up to the com

by gw 12y ago

I've wondered what the story was on Go's dependency management, so I'm glad someone brought it up at the end of the keynote. Pike said that it was up to the community to develop tools to deal with that. This is what happened in the Clojure community when Leiningen became the de facto standard, but its dependency management builds on a pre-existing system (Maven). I am curious if this is on anyone's radar, or if it isn't considered a problem.

msmith 12y ago
Ruby's dependency management (rubygems) also came from the community and is now part of the standard library. That seems like a good model to follow. Dependency management for Go is definitely on people's radar. https://github.com/tools/godep https://github.com/tools/godep has been getting some traction.
- cridenour 12y ago
  Same with Python/pip with 3.4
pjmlp 12y ago
Take some popcorn and go through the discussions on golang-nuts mailing list. There is a big discussion between those that think a language without dependency management tooling does not make sense in modern times. And those that think it should be abolished from the face of earth and replaced with git revisions and pure open source, regardless of industry needs.
valevk 12y ago
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.
- 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.

by gw 12y ago

msmith 12y ago

Ruby's dependency management (rubygems) also came from the community and is now part of the standard library. That seems like a good model to follow. Dependency management for Go is definitely on people's radar. https://github.com/tools/godep https://github.com/tools/godep has been getting some traction.

cridenour 12y ago
Same with Python/pip with 3.4

pjmlp 12y ago

Take some popcorn and go through the discussions on golang-nuts mailing list. There is a big discussion between those that think a language without dependency management tooling does not make sense in modern times. And those that think it should be abolished from the face of earth and replaced with git revisions and pure open source, regardless of industry needs.

valevk 12y ago

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