This issue is a generic enhancement request for go.

Background

An experimental package called "golang.org/x/net/context" exists. This package was brought into the standard language in go 1.7 as "context". This is one example - it will happen again in the future many times over.

Problem

The import directive does not allow for alternatives or versioning to facilitate a smooth transition between experimental and official standard package status. While go is backwards compatible, this transition is not, and it has impacted many projects.

Proposal

Modify the import directive in the language to allow for a fallback position, for example:

ImportDecl       = "import" ( ImportSpec | "(" { ImportSpec ";" } ")" ) .
ImportSpec       = [ "." | PackageName ] ImportItems .
ImportItems      = ImportPath [ [ "or" ImportPath ] ... [ "silently" ] ] .
ImportPath       = string_lit .

for example:

    import "context" or "golang.org/x/net/context" silently

The two packages in this case have compatible APIs and therefore this single line of code would have spared hundreds of projects from having to deal with the transition of the context package into official status. The silently keyword would omit any warnings; without the keyword a warning would be emitted when an alternative is loaded.

Proof of Problem

1. Build Failing - Missing "context" package mock#116 (resolution: please update your go)
2. fix backwards compatibility with golang < 1.7 mock#118 (resolution: switched back to golang.org/x/net/context)
3. Go 1.7 uses import "context" grpc/grpc-go#711
4. Proposal: add context import path upgrade to go tool fix #17040 (tool proposal to help people move forward)
5. Context package and go 1.7 protobuf#217 (discuss when to make the switch)
6. Move to Standard library Context package go-kit/kit#420
7. package context: unrecognized import path "context" labstack/echo#899
8. x/tools/cmd/goimports: prefer golang.org/x/net/context #15471
9. The Apache Thrift project detects the go version at build time and inserts different files into the build to support <1.6 or >1.7 based solely on this package and imports "the right one".

There are many other examples of this.