Make the gps package importable

[spenczar]

Discussion in #527 resulted in gps getting moved to an internal path. I'd like to discuss moving out a stable subset of it to a public API that other projects can import.

---

One concrete use case to kick things off:

I work on a tool called retool which vendors executables. Right now, it can be pretty slow because it doesn't have any cache; invocations of retool have to do full git clones (via go get in a managed GOPATH), then git checkout the proper revision, then call go get again to lean on the go tool's ability to pull in dependencies at that particular revision.

Retool would be improved a lot by using some of the tools in gps.

For one thing, gps provides access to the local cache of packages, including their git metadata, which would speed up most of retool's operations.

A second (less crucial, to me) benefit would be gps's ability to compute the appropriate set of dependencies of a package, instead of relying on go get.

[davecheney]

Discussion in #527 <#527> resulted in

gps getting moved to an internal path. I'd like to discuss moving out a stable subset of it to a public API that other projects can import. I don't think that github.com/golang/dep/internal/gps is the project you want to import, this is a private for of gps. The intent is to iterate on this library fast without having to worry about causing API churn for anyone outside dep. If you want to import gps, maybe use Sam's original repo, github.com/golang/sdboyer

…

On Sun, May 14, 2017 at 4:19 AM, Spencer Nelson ***@***.***> wrote: Discussion in #527 <#527> resulted in gps getting moved to an internal path. I'd like to discuss moving out a stable subset of it to a public API that other projects can import. ------------------------------ One concrete use case to kick things off: I work on a tool called retool <https://github.com/twitchtv/retool> which vendors executables. Right now, it can be pretty slow because it doesn't have any cache; invocations of retool have to do full git clones, then git checkout the proper revision, then just call go get to lean on the go tool's ability to pull in dependencies at that revision. Retool would be improved a lot by using some of the tools in gps. For one thing, gps provides access to the local cache of packages, including their git metadata, which would speed up most of retool's operations. A second (less crucial, to me) benefit would be gps's ability to compute the appropriate set of dependencies of a package, instead of relying on go get. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#575>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA0GOceIr_dgA_YYAhl6d-IjTDsQnks5r5fQ2gaJpZM4NaJj0> .

[sdboyer]

While I haven't updated the original gps repo to say as much, I don't intend to maintain the original repo independent of what's in dep. As I indicated in #300, it was a move, not a copy, into dep; there's little benefit to having two instances of gps with subtly different internals or interfaces out there in the world.

Relying on gps in the original location is a reasonable stopgap, but I accepted moving gps into an internal directory on the premise that it was temporary, and we would make concrete plans for making it publicly visible again. I encouraged @spenczar to open this issue as a way of kicking off that discussion.

[kamilchm]

I don't mind hidden internals, but at the current state it falls shortly because many of dep top level functions returns internal/gps structures, so you need to build all your logic around dep in one function to use it without explicit import.
I don't even know how to test such functions when you can't build dep.Project without using gps imports :( (kamilchm/go2nix@32c22d1#diff-fca82a46466463d3c4a40031e14c453f)
3rd party tools needs better API.

[sdboyer]

Eeek. Yeah, good point. We totally missed that during the move. Thanks for pointing that out, @kamilchm - we really need to get a plan together and sort this out.

[kamilchm]

I thought about it little more and it could be my misuse of dep. What I really needed was some easy way to interact with dep structures in Go and using it as a library was the easiest way before hidding gps as internal implementation.
But there was and is another way to do it - read Gopkg.toml/Gopkg.lock and treat it as a contract between dep and other tools.
What could helps in that case is just a basic dep model expressed as public structs which maps directly to Gopkg files.
I'll move to parsing Gopkg files by my own for now, leaving this as non-issue.