wish to add mirror support

[ziyouchutuwenwu]

as title, i wish to add mirror support, for the gfw, somethinig can like glide mirror setting

mirror just mean，in china, the gfw always block the access from google, if i want to use some google deps, mirror from github is the best choice, here is my configfile of glide

repos:
- original: https://golang.org/x/crypto
  repo: https://github.com/golang/crypto
- original: https://golang.org/x/image
  repo: https://github.com/golang/image
- original: https://golang.org/x/mobile
  repo: https://github.com/golang/mobile
- original: https://golang.org/x/net
  repo: https://github.com/golang/net
- original: https://golang.org/x/sys
  repo: https://github.com/golang/sys
- original: https://golang.org/x/text
  repo: https://github.com/golang/text
- original: https://golang.org/x/time
  repo: https://github.com/golang/time
- original: https://golang.org/x/tools
  repo: https://github.com/golang/tools
- original: https://google.golang.org/grpc
  repo: https://github.com/grpc/grpc-go

[nvcnvn]

I think this is a must have feature, maybe something like:

dep ensure -fork="github.com/myfork/errors" -vcs="git" github.com/pkg/errors@^0.8.0

will overide the manifest and for later time we don't need to specific the fork address and vcs type.

[sdboyer]

@nvcnvn support for specifying an alternate source location exists today. In a glide context, "mirrors" means something else - it's a local path to what's presumed to be a mirror of an upstream repository. That's what I'm assuming @ziyouchutuwenwu is asking about.

It may be possible to support the local mirror case, but doing so is enmeshed with a bunch of other considerations, and I'm hesitant to add the feature until the cases have been sufficiently disentangled.

[darasion]

I think the mirror is important, it can be used as a disaster tolerant cache for something like repository service outage.

[sdboyer]

@darasion if the goal is reliability, then there are still better ways of going about it than this - a central proxy managed by your own organization, for example. If we were to follow the approach outlined in the OP, it would put the responsibility on all team members individually to configure their environments correctly.

Also, we already keep local instances of repositories hidden away; for a number of outage use cases, simply adding a no-network mode - where dep interacts exclusively with whatever the current version of the data is in these local repo instances - would provide equivalent assurances. And we want that anyway, so that you can do things like using dep on a plane.

[darasion]

@sdboyer thanks, it seems better that a proxy with caches inside it.

[sdboyer]

closing this in favor of the other issues re: a registry, etc., e.g. #286