UX: `ensure -update acme.io/dep@v1.0.0` should update the dependency constraint

[tiborvass]

FWIW I'm a first-time user of dep.

• It feels natural to use dep ensure -update github.com/pkg/errors@v0.8.0 to update the constraint of an existing dependency (thus modifying Gopkg.toml)
• It would be very useful to have dep ensure -add work irrespective of whether the dependency exists already, and thus behave as -update in the point above, in the case where the dependency already exists.

The two points are related but orthogonal: first is about intuitiveness (use -update to update), the second is about usefulness (I can always use -add).

cc @ibrasho

[sdboyer]

hi, welcome!

so, some background first. we explicitly chose to move away from having the tool automatically update the Gopkg.toml file back in Feb/March (though it took a while to implement), for a couple reasons:

1. dep ensure is already pretty heavily loaded, and providing a set of CLI controls that sometimes manipulate the Gopkg.toml (in addition to everything else they manipulate) really weigh it down.
2. correctly regenerating Gopkg.toml in a way that preserves comments is quite difficult, but is required if we're going to make arbitrary changes to the file. we consider it important that it be possible for users to be able to make comments as to why certain constraints are expressed - for example, the explanations given here.

a bigger picture thing, though, and maybe related to being a first-time user of dep - i think part of the issue is that you're not thinking of the Gopkg.toml in the optimal way. there's a distinction between, "i want to update my project to use version X of some dependency," and "my project can only work with version X of some dependency." sometimes these are the same, but not always. updating Gopkg.toml is expressing the latter, but i'm guessing that you were primarily thinking about the former. the former is what's expressed in Gopkg.lock, and that's really the key concept here - dep works best when you trust Gopkg.lock, without trying to pin to specific versions in Gopkg.toml (as you may have been accustomed to with previous tools).

there's also a specific case here that we've been considering, as part of the new spec encompassed in #277 - having dep ensure -update acme.io/dep@v1.0.0 first check to see if the specified version is within the constraint range specified in Gopkg.toml, and if it is, then try to update to exactly that version, WITHOUT changing constraints. the idea there is that it makes it easier to try out new specific versions, without having to futz with editing a file.

however, you're in a uniquely useful position right now, given that you're relatively new to dep - what could we do differently with our docs/CLI help/whatever to make these ideas more readily obvious?