Navigation Menu

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: cmd/go: permit replace in go.mod to act as path alias #35382

Closed
kaedys opened this issue Nov 5, 2019 · 4 comments
Closed

proposal: cmd/go: permit replace in go.mod to act as path alias #35382

kaedys opened this issue Nov 5, 2019 · 4 comments

Comments

@kaedys
Copy link

kaedys commented Nov 5, 2019

The go.mod system already has a replace directive that can be used to specify a different version, commit, or URL/path to use for a particular require directive. The current implementation of this requires that a version or SHA-pseudo-version be specified for all non-local replace line (replace targets that do not begin with ../ or ./).

Unfortunately, this design locks out a specific use case that prior vendoring tooling had available: the ability to "alias" an import path in a generalized way (ex. govendor has this capability via the syntax `github.com/kardianos/govendor/^::github.com/myself/govendor). This has several use cases:

  • Being able to "redirect" an import to a fork or alternative URL in a version-agnostic manner
    • Ex. Our corporate firewall tends to throw fits with certain redirect URLs (ex. go.opencensus.io redirects to github.com/census-instrumentation/opencensus-go). We have replace directives from the official URLs (which are compiler-enforced by the import comments) to the actual github endpoints to bypass this issue, but this means we have the "version" present in two places, the require block and the replace block, and have to hand-update the latter when we update the former.
    • Ex. We have an internal github repo for our company, but the URLs tend to be annoyingly long for imports due to the repo and team naming conventions. Unfortunately, the process of getting an internal vanity URL server set up has not gained traction, forcing us to use the full long internal github URL rather than our preferred vanity URL. If we could add a general replace directive that maps the vanity URL for a particular repo to the actual corporate github URL for that repo without specifying a version, it would solve this issue. As above, trying to do this currently would require us to hand-update the "version" specified in the replace block every time we update the require block.

In both of these cases, these are specifically dealing with redirect type replace directives, where the URL actually imported simply proxies or forwards to an underlying repo. The versions for these types of imports are by definition identical, because the imported URL does not maintain a separate versioning system from the underlying URL, it is simply an alternative URL referring to the same underlying resource.

Proposal

Permit replace directives without a version identifier (or alternatively, add a keyword to indicate such behavior). When operating in such case, the version or pseudo-version specified in the require directive for that import would be the one retrieved from the replace URL, but the package itself will still be imported in the code using the URL in the require block (which allows it to satisfy compiler-enforced import path comments).

@ianlancetaylor ianlancetaylor changed the title [Request/Proposal] go.mod replace as path alias proposal: cmd/go: permit replace in go.mod to act as path alias Nov 6, 2019
@gopherbot gopherbot added this to the Proposal milestone Nov 6, 2019
@ianlancetaylor
Copy link
Contributor

CC @bcmills @jayconrod

@bcmills
Copy link
Contributor

bcmills commented Nov 6, 2019

Duplicate of #26904

@bcmills bcmills marked this as a duplicate of #26904 Nov 6, 2019
@bcmills bcmills closed this as completed Nov 6, 2019
@bcmills
Copy link
Contributor

bcmills commented Nov 6, 2019

Actually, reading this again it may be a duplicate of #28176 instead, but it is not accurate — or, at least, not sufficiently unambiguous — to describe that as a “path alias”. (When we say “path” in the context of cmd/go, we generally mean a package import path, not a URL or a repo path.)

@kaedys
Copy link
Author

kaedys commented Nov 6, 2019

My mistake on the naming. Reading the two, #28176 does appear to more closely align with my desired use case. Apologies for not finding it, I didn't expect tickets that old to deal with this use case, so I didn't check much beyond that last few months for a similar ticket before submitting mine.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants