[Goopplesoft]

Is anyone else using golang dep[1] as their vendor/dependency tool?

I’ve used it and it works great (much better than glide, gb et al) but I don’t see it in the wild too often.

[1] https://github.com/golang/dep

[pjmlp]

Well, it is on its way out, have you missed the news regarding vgo?

https://research.swtch.com/vgo

[chimeracoder]

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

[kitd]

Er, thanks. We've just moved to go dep :)

Go's dependency management story is starting to resemble JS's modules story :(

[lobster_johnson]

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.

[1] https://research.swtch.com/vgo-intro

[2] https://sdboyer.io/blog/vgo-and-dep/

[lobster_johnson]

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.

[tynorf]

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.

[latchkey]

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.

[nzoschke]

Yes using dep full time for projects andnit has been great.

I think it’s the right choice for now. It was going to be the one true solution and many people have stopped working on the alternatives.

We’ll see where vgo lands, but dep is very practical right now.