go get-like CLI API

[VojtechVitek]

Proposal:

The dep CLI commands and flags to be much more similar to go get.

dep get github.com/pkg/errors@^0.8.0
dep get -u github.com/pkg/errors (latest)

[sdboyer]

We (the committee) went back and forth over the naming of the verbs and flags quite a lot, and settled intentionally on ensure. It's not even that it does more than go get does - it's that their behavior really only has partial overlap:

1. dep has nothing to do with go install-ing code; it will never* generate a binary. As such, the -d flag has no analogue.
2. go get's -f and -fix flags have no possible analogue in dep. -t, if we even make an analogue, would likely be done as part of a wider system of os/arch/build/release tags, and would be a permanent choice recorded in the manifest.
3. Once we add support for doing individual dep updates, the equivalent of dep ensure -u github.com/pkg/errors would get you the latest version of pkg/errors that's allowed by the constraint in manifest.json. That may or may not be the same as the "latest" from upstream
   • ...assuming that the solver can find a workable solution, at all.
   • It also might find a version that's not the very latest, because the very latest didn't satisfy all other constraints in the depgraph.
   • It would also NOT update the transitive dependencies of pkg/errors, unlike go get -u ....
4. go get has no concept of an override, but that's a crucial control option in dep.
5. Similarly, there's no analogue in go get to ignores or requires - we've not dropped those in yet, but they're planned and described in the spec doc, and you can hand-write them into the manifest today (ensure: add tests and behavior for when a dep is unused #108 actually has preliminary code for require)
6. dep ensure, no args, covers an entire project. go get operates just from the current package.

Basically, go get has us all in the mentality of directly mutating state on disk. In dep, that's almost more of a side effect - instead, you're focused on setting up constraints, and dep then works out the solution. This is the standard tradeoff between direct, imperative control and safety - the very same class of tradeoff Go makes for its memory safety. Making the dep commands and flags similar to go get would just reinforce the expectation that they behave the same way.

While I do believe it's important to make transitioning to dep as easy as possible, I think that setting up false expectations is a poor way to do it. Plus, the command set that we're trying to provide with dep is complicated in its own right. I think it's preferable to focus on internal consistency of the design, rather than saddling it with the additional requirement of being like go get.

Finally, I'm hoping for a future in which go get still exists, but as a tool solely for the consumers/installers of go code. I think that's an important distinction (I give basic reasons for this in the introduction to my pkg mgmt article - PDM vs LPM), and it's worth trying to avoid blurring that line.

To be clear, I'm not saying the verbs or flags are final - not at all. I'm just rejecting "be like go get" as a design goal.

[sdboyer]

I'm closing this, as the design goal is a non-starter. Please feel free to open specific issues about particular verbs or flags, though!

[VojtechVitek]

Closing after 4h doesn't look like a very nice approach to the community.

[sdboyer]

The issue's not locked, just closed. I'm not preventing you from discussing it. I'm just trying to clearly signal that we believe this is a settled question; leaving the issue open indicates that the maintainers consider something unresolved here.

To reiterate, there are lots of rough edges and things needing improvement with the current verbs and flags. And I, really truly seriously, invite you to open specific issues about them with specific arguments.