External file-based registry

[jan-g]

What does this do / why do we need it?

This is an example of an approach to #174

Projects building behind a corporate firewall need a way to deal with local projects - and, potentially, locally-cached versions of upstream projects.

Such builds may exist behind a strict firewall; additionally, it's not always the case that the import path "example.com/xyz/bar" actually has the go vanity metadata being served from it.

For these builds, we want a local way to intercept and redirect the actions of dep, to get it to fetch from alternative locations - without first attempting the HTTP(s) dereference of the importpath location.

We do this by introducing a registry. The only functionality that this object must supply is that of the Deducer interface (which is now exported).

The example code only has one kind of registry to resolve these import paths. It reads from the top-level file `Gopkg.reg, which should consist of lines containing whitespace-separated elements. These are:

• the import path to match; this is a Golang regexp
• the registry root corresponding to that import path. This may contain
  references to capture groups in the import path pattern.
• one or more git URLs; these may also contain $1-style backreferences.

Example content:

^example\.com/xyz/([^/]*)(/.*)?$ example.com/xyz/$1 ssh://git@local-repo.org/foo/$1

Imports of "example.com/xyz/bar" will be cloned from "local-repo.org/foo/bar".

The current implementation is just a POC: its parsing of Gopkg.reg is
rudimentary. It only supports git repositories. However, the principle
is demonstrated: it requires minimal code-change to get the registry
behaviour into dep. Registry implementations that talk to alternative
repository APIs are, of course, possible.

Note: the behaviour specified in Gopkg.reg is not inherited by any
importing packages; it is a function solely of the local environment.

What should your reviewer look out for in this PR?

Mostly, if this is a suitable approach; the code is just a quick sketch.

Do you need help or clarification on anything?

Which issue(s) does this PR fix?

(partially) fixes #174

NOTE:

README needs fixing prior to merge; you might or might not want to drop the Dockerfiles.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[jan-g]

CLA signed

[googlebot]

CLAs look good, thanks!

[googlebot]

CLAs look good, thanks!

[jan-g]

Couple of notes on this.

1. The registry lookup should come ahead of the wka lookup.

2. Registry, wka and http are all basically deducers. A second refactor has the top-level deducer calling out to implementations in order; the actual instances can be passed in (so configured at a higher level). We can maintain the Once-like behaviour of http for all of the pieces. As a refactor that's a reasonable second step but I'm not planning on moving ahead unless you think this has legs.

[mvdan]

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!