Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: enhance import directive to allow for alternatives on failure to better support promotion of experimental packages into the standard library #22358

Closed
jeking3 opened this issue Oct 20, 2017 · 3 comments
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Milestone

Comments

@jeking3
Copy link

jeking3 commented Oct 20, 2017

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.

@ALTree ALTree changed the title Enhance import directive to allow for alternatives on failure to better support promotion of experimental packages into the standard library proposal: enhance import directive to allow for alternatives on failure to better support promotion of experimental packages into the standard library Oct 20, 2017
@gopherbot gopherbot added this to the Proposal milestone Oct 20, 2017
@ALTree ALTree added the LanguageChange Suggested changes to the Go language label Oct 20, 2017
@ALTree
Copy link
Member

ALTree commented Oct 20, 2017

I've tagged this proposal but you'll definitely need to clarify the exact semantic of the change you are proposing to make this report a serious language change proposal.

Also, please note that Go tools almost never emit warnings, so I'm not convinced that the silently modifier will be well received.

@ianlancetaylor
Copy link
Contributor

Since the concern is mainly for packages brought into the standard library, I think you need to explain why build tags are insufficient.

For example, for the context package, as long as you want to support versions of Go before 1.7, import "golang.org/x/net/context". That package is written to use build tags to make the right thing happen: if using Go 1.7 or later, you will in effect get the standard library "context" package.

@dsnet dsnet added the v2 An incompatible library change label Nov 10, 2017
@ianlancetaylor
Copy link
Contributor

Closing in favor of build tags and the ongoing package versioning work (#24301).

@golang golang locked and limited conversation to collaborators Mar 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Projects
None yet
Development

No branches or pull requests

5 participants