> Well, it is on its way out, have you missed the news regarding vgo?
Dep will have a clean migration path to vgo, and the latter isn't really production-ready yet.
For now, I'd recommend using dep for daily use, until you have a compelling reason to switch to vgo, at which point the migration will probably be automatic.
Yeah... In defense of the Go folks (1) they are working hard to make the transition as smooth as possible (2) dep was always just considered an experiment (though with aspirations by the author to have it become the official solution) (3) vgo almost certainly marks the end of the churn, and looks really nice.
> Go's dependency management story is starting to resemble JS's modules story
It's worse tbh. npm was actually always usable if you knew what you were doing. Complaints with npm were generally down to misunderstanding, people not being aware of features like 'npm shrinkwrap' (which has now been replaced with a lockfile-by-default strategy) and of course registry issues (allowing unpublishing) that weren't unique to npm, and were only an issue for people relying on public registries at deploy-time, a bad idea.
vgo is at least phrased as being a proposal, not necessarily the future of Go [1]:
This post sketches a proposal for doing exactly
that, along with a prototype demonstration ...
I intend this post to be the start of a productive
discussion about what works and what doesn't.
Based on that discussion, I will make adjustments
to both the proposal and the prototype, and then
I will submit an official Go proposal, for
integration into Go 1.11 as an opt-in feature.
Of course, this is Russ Cox, so chances are that his proposal will carry more weight with his fellow core Go team than that of Dep's authors.
Sam Boyer's follow-up is interesting reading [2]. I get the feeling that despite their ongoing discussions, the Dep team was/felt ambushed by this move.
We use Dep. It's good, much better than the buggy mess that is/was Glide.
My only criticism is that "dep ensure" will actually parse the code to discover dependencies through import statements, which is also what Glide does. To me, this is antithetical to the purpose of a Gopkg.toml/lock file. In other words, Dep's full list of dependencies isn't actually in the Gopkg.toml file; it's a sum of Gopkg.toml and your code. That is confusing.
My desired behaviour:
* "dep ensure" should always used the lock file, nothing else, to install;
* "dep ensure -update" should update the lock file to what is specified in Gopkg.toml (and only that);
* "dep ensure -add" (which I think should be "dep add") should b required to add new dependencies to the Gopkg.toml file.
Aside: I wish Go projects weren't stuck with BSD style flags (-update instead of --update). GNU style is more common and arguably more practical. I applaud whenever a project (e.g. Prometheus, recently) finally sees sense and goes over to GNU flags.
I'm fairly certain you can use `--flag` with the standard flag package from stdlib: https://godoc.org/flag (in the section on command line flag syntax).
Though supporting `-flag` does remove the very nice combining of short flags.
Interesting, I didn't know that. I never liked the flag package, and the downside you mention is a reason not to use it. Kingpin (used by the Prometheus projects) and go-flags are nicer. Lots of Google code uses spf13's pflag, which I'm not a fan of, but it does do GNU flags correctly.
The weird thing is if you -add a dependency before you import it, then you get a warning that the dependency isn't used in the codebase yet. Of course it isn't, I just added it! My IDE (IDEA) resolves the imports for me, so I can't add the import until after I add the dependency. Nice little catch-22.
https://research.swtch.com/vgo