Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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

[1] https://github.com/tools/godep


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.


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.


My C, C++ and Java Ant scars in Fortune 500 consulting projects tell me otherwise.


That's fine. Some do it badly, and some do it well.


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.


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


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


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


It's true: not all features yield net benefit.


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.


I'm curious to know what you think proper dependency management looks like.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: