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: go.work: go build
requires versioned replace directive when replacing a used module with a local path
#54264
Comments
workspace
|
Same problem for me. Frankly I'm surprised, most of the go tooling is generally high quality, but |
In general we would expect modules that are included in a workspace to not also require a |
The reason I was looking to do this was to handle an environment where I cannot directly connect to the upstream git repo. I'm seeing go execute I can remove the |
don't know where you came up w/ that long versioning string, fyi:
to note that you shouldn't need the |
It appears to do that by running |
I am having the same problems in 1.19. Once I put in go.work everything goes haywire.
Thinking about trying the latest go to see if the behavior changes. |
As said above, since the beginning of go workspaces, and at least up to current Go 1.21.5 ; Tree structure :
CONTENT of module-A (no dependencies) :
CONTENT of mains-project (depends on moduleA) :
So, they are manually-crafted files, and the repos/gitlab doesn't event exists, go.mod.sum are missing, the v0.9.9 doesn't really exists, etc etc... but it reflects the SAME PROBLEM than really existing private git-cloned repos. Inside
So the full text above is not really interesting. The MAIN POINT is that go it trying to I would also like to specify, in aim to alleviate unneedy discussions, that for a real scenarios, my So, for the described scenario above, using only This WONT happen for even-dummy-er testbed scenarios where you would omit this from
Indeed, if you only use local-only never-git-pushed tagless/unversionned dependencies, the problem would not occur. If for some reasons (which seems valid to me), your ----8<----8<----8<----8<----8<----8<----8<----8< I severely miss a simple method to having this workflow working seamlessly :
I mean, all the above works seamlessly, except for me, the dev, which needs to constantly jungle with some go.work, use, and replace directives. This just doesn't work seamlessly, go.work ----8<----8<----8<----8<----8<----8<----8<----8< To me, it feels like the Googling around on "go.work", "git ls-remote", "use", "ignored", "without replace", etc... yields a lot of results of confused people which seems to have a bad time figuring out a workflow which would suits to them. I would just like a simple way to :
That's just hard in Go, having to constantly jungle with replaces directives. I cannot seem to have a fixed-once-figured-out-do-not-constantly-modify-replaces set of go.mod/go.work files where I would just No, Go is willing to |
I'd like to chime in too with the same issue and an additional potential bug (not sure if I should open a separate issue for that though). I felt it's most appropriate in this issue, but it's certainly also related to #50750 . FTR we're using Go 1.21. In our monorepo we gitignored
A local Go workspace enabled us to efficiently make updates to multiple modules in one change and test them without having to update versions. Push to CI/CD however, requires an update to the versions (e.g. if module To avoid this, we decided to add
Removing go.work for this change in CI fixed the issue. Repository with demo: https://github.com/mweibel/gomodreplace/tree/fail (please note, this is only a partial reproduction because we have an additional issue in our monorepo due to the fact that we are on an on-premise GitLab instance without a go module proxy in front). The issue with this approach is visible when running
Because I certainly might be doing something wrong and would love to get some help/documentation if that's the case. Thank you! |
There are a couple of solutions we could consider here:
(CC @matloob @samthanawalla) |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Given the following workspace structure:
With the following
go.work
:Build
realdeal
which depends onfubar
:What did you expect to see?
Nothing, the build should succeed
What did you see instead?
Found workaround
The only way I've found to fix this is to update the
go.work
to be as follow:This is not needed if a workspace is not used. It also seems to contradict the example from the documentation (https://go.dev/ref/mod#workspaces):
The text was updated successfully, but these errors were encountered: