You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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
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.)
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.
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 particularrequire
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:
go.opencensus.io
redirects togithub.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, therequire
block and thereplace
block, and have to hand-update the latter when we update the former.replace
block every time we update therequire
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 therequire
directive for that import would be the one retrieved from thereplace
URL, but the package itself will still be imported in the code using the URL in therequire
block (which allows it to satisfy compiler-enforced import path comments).The text was updated successfully, but these errors were encountered: