cmd/go: allow replacement modules to alias other active modules #26904
Comments
And this crazy stuff could happen only in non-go.mod repositories, because you can't use both upstream and fork at the same time if they have
You are forced either to use your fork as So no one will ever hit such an issue in the brave new world of |
Ideally, I think the long-term solution will be to treat replacements as rewriting the import paths rather than the source code, to allow for precisely this kind of fork-unification behavior. (For an example of how this can go wrong otherwise, see the code in #26607.) |
@bcmills you set "Go1.12" milestone for the issue. Maybe we could at least fix the error string in Go1.11 to eliminate the confusion?
|
Oh, yeah, that's an easy fix. |
Change https://golang.org/cl/128878 mentions this issue: |
Updates #26904. Change-Id: If7f381c3f3a41bd62c5f8bcf4f92720badcaf5c6 Reviewed-on: https://go-review.googlesource.com/128878 Reviewed-by: Russ Cox <rsc@golang.org>
I am also seeing this problem when using I added:
to However, if I run
|
Recommended here: golang/go#26904 (comment) Signed-off-by: Craig Rodrigues <craig@portworx.com>
Just a heads up that one of the linked answers is the top result on Google when you search for "used for two different module paths" so it might be good to provide some easy guidance here on how to solve that problem. As it stands you have to read a lot to get your head around how this solves the issue. |
This issue is currently labeled as early-in-cycle for Go 1.16. |
I'm dropping the |
To add another real case where this is causing pain: cc @marwan-at-work in case he's open to fixing this in his module directly. |
@mvdan done on the vecty-router side thanks to @NateWilliams2 marwan-at-work/vecty-router#12 |
Another case where this is causing pain: An upstream dependency (A) is pointing to a git repo that has been deleted (B). Another dependency (C) is using a fork (D) of the repo that has been deleted. The fork (D) and the repo that has been deleted (B) are both exactly the same, just B no longer exists. So a simplified Dep tree would look like this:
As a stopgap to continue our builds until the upstream dependency (A), we thought we could just replace B with D, but that's throwing the "X used for two different module paths", even though that's exactly what we want to do. |
I have another issue with 1.15.3. Maybe I need to file another Issue, but will post here for now:
Results in: |
@Dragomir-Ivanov, no need to file a separate issue. This is next on my list after #36460, although it might not make 1.16 before the freeze. However, note that That could well produce type errors if types from the imported packages are used in the exported API, since each distinct package also defines its own types. It seems that what you ideally need is exactly what we haven't implemented yet, which is a way to reinterpret |
@bcmills Thanks for your reply and all the efforts! I workaround my issues so far, by making private fork, and replaced all self import paths in There are lots of abandoned packages, then revived by someone else and continued (as this I am in no rush what so ever, and can wait for 1.16, 1.17, etc. |
go 1.12.17 used for two different module paths for To fix this, I replace all my import path of 'golang.org/x/protobuf' to 'github.com/golang/protobuf'. Sincerely I think these two import pkgs should support work together and not just force user to abandon one of it, because everything work fine in GOPATH and just go bad in GOMODULE. It's just not that smooth. |
Can anyone explain me why it's not possible to make go point to the same version of package from multiple aliases? Will it be resolved somehow? Any progress of that? Thanks! |
@Rikanishu, #26607 is why aliasing is currently disallowed. I plan to address this in Go 1.17. |
Maybe go chain will only find pkg source code by one and the only one specific key, this key is module-name. Why two pkg sharing a same module-name will conflict. It(go chain) might use a map to storage a source code ref like:
key is module-name, value is where source code put. Here it meet a question!
So only extend |
What version of Go are you using (
go version
)?Go tip:
go version devel +f2131f6e0c Wed Aug 8 21:37:36 2018 +0000 darwin/amd64
Does this issue reproduce with the latest release?
Yes (it is not reproduced with
go version go1.11beta2 darwin/amd64
)What operating system and processor architecture are you using (
go env
)?What did you do?
Sorry, no standalone reproduction, since issue is connected with repository forking
Assume we have a repository A: https://github.com/mwf/vgo-a with the only feature:
Than we have a
fork1
https://github.com/mwf/vgo-a-fork1, adding a feature B :Unfortunately
fork1
will never be merged to the upstream, just becausea
author don't like this feature.It's important to note, that both😄
a
anda-fork1
don't havego.mod
, they are too conservative for thatThen we got a happy user, using both projects in his repo.
go.mod:
main.go
All just works fine:
Here appears
fork2
https://github.com/mwf/vgo-a-fork2, forked fromfork1
, and fixing some bugs both in the upstream and infork1
.We use the fork2 with
replace
in our main repo: https://github.com/mwf/vgo-a-user/blob/master/go.modWhat did you expect to see?
Building this with
go1.11beta2
works just fine:Output:
What did you see instead?
Building with the tip (and beta3) returns an error:
Output:
More comments
I understand that this case is very specific and arguable - this should not ever happen ideally, but we have the real case here:
https://github.com/utrack/clay/blob/master/integration/binding_with_body_and_response/go.mod
There is a little workaround, to define
go.mod
at fork2 and make a replace upstream -> fork2_with_go.mod, but it's too dirty :)It works with tip and beta3:
If you decide that the case is too specific and crazy, and you'd like to close as "Won't fix" - then I assume we should change the error string, because it's confusing now:
It should look like this:
because it's
github.com/mwf/vgo-a-fork2
who's to blame for the error.The text was updated successfully, but these errors were encountered: