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
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>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@docmerlin mentioned an interesting use-case for path-rewriting replacements. Suppose that a module previously existed at a path like To make matters worse, if the author of |
Change https://golang.org/cl/332571 mentions this issue: |
With everything else happening in Go 1.18, I think this is going to slip to 1.19. |
Looks like there are more than one thing slipping to 1.19 because of the same reasons. May I suggest to make 1.18 with all these items, and then make 1.19 to go with generics (maybe shortly after)? |
@tandr That could have been a good discussion six months ago, but at this point we only have one month left to the 1.18 feature freeze. We're not going to be able to significantly rearrange our priorities now. Sorry. |
Thanks Ian, I understand. |
* update jwt-go * update replace why? golang/go#26904
This commit reverts changes made in a previous PR [1] which attempted to use relative imports within the module. I'm quite new to go modules and unfortunately that change was equivalent to renaming the module - something that golang doesn't support.[2] This commit reverts the changes and adds warnings to previous releases that were published in error. [1]: e05c9d2 [2]: golang/go#26904
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: