Personally I think I'd much rather have my dependencies be explicit rather than inferred from what I require across my code base. The idea of a tool which supports both Bower and Component packages is quite nice though.
I keep meaning to spend some time playing with Go, but I haven't yet so I don't know how that feels. However, I wonder what it says that several dependency management tools have emerged for Go.
> However, I wonder what it says that several dependency management tools have emerged for Go.
In the case of Go, it's more meaningful to note that most larger Go projects have been developed for quite some time without needing any of these tools.
If you need specific versions, the standard, idiomatic Go approach is to vendor your dependencies. Google, for example, does not use any Go-specific tool for vendoring IIRC. The last tool you mentioned, Godep, is one Go-specific approach at vendoring. It's also the one that I have anecdotally heard recommended, but this comes with absolutely zero personal experience and is solely hearsay.
But most projects don't even need to vendor - I've been writing Go as my primary language for almost 2 years both at work and for personal use, and I have never once needed godep. YMMV, obviously.
(Looking at tools that exist isn't meaningful in se, because people will try to build libraries to replicate pattern from other languages whether or not they apply. They will look for what they're familiar with, see that it's "missing", and then decide to write one, rather than questioning whether that idiom is actually appropriate for this new language.)
Fair enough that the existence of tools isn't really indicative of anything. Although at least the three I mentioned have a few hundred stars on GH which suggests some people are actually using them.
Anyway, thanks for sharing your experience! Your comment suggests to mean that you haven't had the need to fix the versions of any of your dependencies. Is that really true? I would find that quite surprising given that you've been coding in Go for a couple years.
Just to be clear, you can actually pin down the dependencies by creating a `component.json` manifest and adding the specific versions you want. You'd want to do this when publishing your own components, or when building a large app, but for quickly sketching out ideas you can just require them inline. Basically the manifest is optional, so you can choose when it makes sense to lock things down.
Not quite yet, but it totally could. We've been talking about trying to find a way to directly pin in the source with the help of a nice CLI instead. So that we can keep having no manifests, but get pinned deps at the same time without having to manually go through them all.
