Dep: (re)Spec and implement command set

[sdboyer]

In the original spec, the committee elected to aim for explicit commands and an entirely CLI-driven UI for dep. However, after some discussion and getting our hands dirty, we decided (https://github.com/golang/dep/issues/213#issuecomment-278831924) to change course and focus instead on a workflow that presumes hand-edited manifest files and a more minimal command set.

This meta-issue is to track the writing of a new spec (WIP here), and then implementing it.

While we of course expect these commands will continue to evolve in the future, this issue specifically aims to track implementation with the goal of having a command set that could reasonably be merged directly into the go toolchain. Basic completeness per the spec (not bug free-ness), is the rubric for completion of this issue.

Related/sub-issues:

• [x] #186 - alternate init modes
• [x] #145 - no-op on ensure should actually be no-op
• [x] #161 - dep status, memo
• [x] #302 - report when manifest contains ineffectual constraints
• [x] #303 - incorporating non-imported packages
• [x] #343 - generate Gopkg.toml with examples
• [x] #481 - drop remove subcommand
• [x] #489 - overhaul ensure

[jbrodriguez]

With regards to this WIP flag for init

-no-tools: skip searching for metadata files from legacy tools

Shouldn't the default be to skip and the flag to actually search for legacy tools ?

Eventually there will be no legacy and you'd still need to pass the flag.

[sdboyer]

@jbrodriguez i was gonna say that that seems like a good comment to make in the doc...then realized i had comments disabled 😛

It shouldn't be necessary to pass -no-tools, even if there's no tool metadata available. It should fall through just fine on its own. Might be more intuitive if the flag is -skip-tools, though; I've updated accordingly.

[sdboyer]

I made considerable progress on the WIP spec last night; a new approach to dep ensure is now at least mostly sketched out. It's certainly in a place where folks could start iterating on it, though we'll doubtless need to take it over the course of a few PRs. I'd prefer to avoid it, but we could also use a long-running feature branch if need be.

[agnivade]

@sdboyer - Shouldn't the checkbox beside #302 be ticked now in your first comment ?

[sdboyer]

it should, heh, now that that's finally finally done

[sdboyer]

and so, this long-open issue can go away, finally

[ancarda]

This issue is linked on the Roadmap page as "Stable command set" but doesn't have a strike-through like "Stable manifest and lock files". Is this considered closed? If so, is there some way to edit that page (e.g. via a pull request)?