cmd/go: dependency module in workspace has go version requirement loaded before local replacement #66516
Comments
seankhliao
changed the title
seankhliao
added
NeedsInvestigation
|
can you provide a reproducer for the issue? |
seankhliao
added
the
WaitingForInfo
|
I tried reproducing with a simple reproducer and I'm having difficulty myself. The basic mechanism works as expected. I do have a reproducer but for a complex case which I'll include at the bottom of the post. I think the problem is being caused by the main project using a dependency that is not a versioned release and only pointing to a git commit. If I checkout the correct commit in the cloned repository, change the required go version in the go.mod file, then I would want that to work. However, it does not. Go doesn't seem to be matching the dependency with the cloned repository, even when it has been checked out at the correct commit. This is the main project: https://github.com/f1gopher/f1gopher And the reproducer: |
seankhliao
removed
the
WaitingForInfo
seankhliao
changed the title
|
it does work using |
|
This is the intended behavior although I do understand the inconvenience of it. What's happening is that although You'd need to remove the dependencies on that version of Locally I created a workspace with f1gopher and f1gopherlib in the same directory and otherwise followed your instructions. Then in the f1gopher directory I ran |
Understood. As @seankhliao says the replace directive works so it's still possible to do what I wanted in this instance, just not through workspaces. I'm happy with that 👍🏾 and I think the issue can be closed However, I do think there's work that can be done here with error messages. I think error messages from the Go tool are generally quite poor (messages from the compiler itself are fine) and I think the error message in this case is a great example of that. To be clear, the error message is entirely accurate but it's not helpful. Thank you for looking into this for me. |
|
Hi, we appreciate the feedback. What do you think would be a more helpful error message in this case? |
Great question. In this case it wasn't clear why the error message was talking about a module that I thought I had "replaced" with the workspace entry. The error message is the same with ./f1gopherlib in the workspace as it when there is no go.work at all. That's confusing. So I think the message could be improved by acknowledging the existence of the local version of the module and going on to explain that it is the module as stated in the go.mod that does not pass the MVS check. Maybe my issue is that the workings of MVS is opaque. Maybe there should be a way of listing the decisions that MVS makes. That might have helped me diagnose and to understand what caused the problem. |
Actually, there is a slight difference: Without a go.work file:
With a go.work file:
It's not clear why the second message includes |
|
Got it- I think it could be very useful to make MVS decisions more visible, but that would be a pretty complex undertaking. We need to think about how we might implement that, how we would expose such a feature, and what the messages would look like |
Go version
1.21.7
Output of
go envin your module/workspace:What did you do?
I want to build a project with Go version 1.21.7
The go.mod file says version 1.22.0 is required. However, I know this isn't strictly true and will compile with <1.22.0 except for the go.mod file
The project has a dependency which also requires version 1.22.0 according to its go.mod file, but which uses no 1.22.0 features and will compile with the lower version of the Go compiler (except for the go.mod file)
I have local copies of both the project and the dependency cloned from github
I change the version requirement in the go.mod of both projects and begin a go.work file with "go work init"
I add both projects to the go.work file with "go work use "
What did you see happen?
The project will not build with the lower Go version despite the changes to the version requirements in the local copies of the go.mod files
The error message shown as below:
go: module github.com/project/project@v0.9.1-0.20240221103349-46ee8a99748c requires go >= 1.22 (running go 1.21.7; GOTOOLCHAIN=local)This project (name changed because it is not a public repository) is the dependency that was cloned and added to the go.work file after changing the Go version requirement in the go.mod file
What did you expect to see?
I expected the project to be compiled because there are no 1.22.0 features used in either project and because I changed the Go version requirements in the local copy of both the project and the dependency
It seems like Go is checking the version requirements of the remote version of the dependency and not the local version pointed to by the go.work file
NOTE
I understand that if I set GOTOOLCHAIN to auto then this would work. But I believe that a GOTOOLCHAIN set to local should still allow me to change the Go version requirements in local copies of projects in the way described
NOTE 2
I have checked that my Go workspace is working correctly by compiling the project with a local version of 1.22.0. In that case the version check passes and local copy of the dependency is used
The text was updated successfully, but these errors were encountered: