glide -> gps transition #565

As discussed in #384, there's a number of things to consider about transitioning glide onto gps. I figured I'd open this issue as a place to start just enumerating them, and we can decide where/how to split them all out later.

I intend to edit and update this list as I go, though, so probably better to think of this as a meta-TODO list, where we can check things off as we talk through them and agree on something, implement something, or whatever other solution we come to.

(This list is unlikely to be exhaustive until everything's actually checked, as it's a running checklist that I'll add to as we discover more things)

• Cannot specify 'vcs' param; this is deduced, or doesn't work. At most, it becomes a deducer question
• subpkgs (in manifest) no longer serve a purpose and are going away. They may remain in the lock, though. gps doesn't currently support that (Express set of packages actually used in result/lock sdboyer/gps#40), but adding support is pretty trivial (we have all the information).
• gps makes hard assumptions about things being available upstream, else fail. (So, if something's available in vendor, but not accessible upstream, it's a failure, whereas arguably it could/should be satisfied by what's sitting in vendor now).
• glide.yaml key is changed: s/Import/Dependencies/. It might be even more semantically accurate if it were DependencyConstraints or Constraints
• It seems like glide's current ignore and exclude in glide.yaml could both just be folded into gps' ignore, but I'm not fully sure.
• Selective arch/os support simply isn't present in gps, but the foundation's in place for a much more complete system than glide's current one. This'll be solved by Keep tags on selected deps so we know the context of their inclusion sdboyer/gps#44
• Also solved by Keep tags on selected deps so we know the context of their inclusion sdboyer/gps#44 is annotating in the solution/lock when a given dependency is only necessary for running tests (which glide currently does).
• There's currently no support for explicitly grabbing a pkg not named in the import graph (Allow args to inject required packages (graph "sources") sdboyer/gps#42)
  • This affects glide get, b/c it's kinda a no-op if it's not in the import graph - apart from updating the manifest. As described in gps issue, though, I think we could maybe safely defer that till later?
  • In the same vein, if a dependency is listed in glide.yaml, but is not present in the import graph, it will NOT show up in the result.
• User-facing output will be significantly different, most notably in that gps doesn't report that it's doing any repo fetching or management as it does it. We could build a communication channel for it if it's crucial, but it just doesn't exist now.