-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: install: respect replace directive if the replaced module is in the same repository #69762
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
Comments
Before considering closing this request, like #44840 and #40276 please answer the question, how a repo can be organized in a way that allows the above behavior with the way go install currently works. It is not (only) about replace directives and go install, but about being able to have a repo with two modules where one uses the other and they can be released together. |
It is obviously for using |
Duplicate of #50698 there's no reason why you can't tag and update both in the same commit. |
Yes, there is a reason: The dependent can only get the correct go.sum entry when the repo is tagged and pushed. So when tagging in the same commit, the go.sum would be outdated. |
Since there the go.sum problem was not mentioned, can you please reopen this issue? |
That's not really an issue that prevents the code from working, and as mentioned in #50698 , this is in general infeasible. |
It defeats the purpose of go.sum. It would be feasible, if go install would allow the replace directive in this cases. We are running in circles. It is not really an argument so say, it does not work. Then nothing would ever happen. It is totally ignorant to the problem and the community. |
Go version
go 1.23.0
Output of
go env
in your module/workspace:What did you do?
What did you see happen?
What did you expect to see?
nothing, it should just install
Context
We have a repository with a library and a command that uses the library. This is pretty common and was never a problem in the pre go modules era.
This allows in principle for a library and a command to be released in sync with the same version number and the same behaviour.
An additional reasonable requirement is, that the command should be able to have more dependencies than the library. And therefor the library and the command are two different go modules (each has its own go.mod file with its own path).
In our case, there are other libraries depending on the library. These other libraries are used by the command. This is not possible without having two separate go modules in this repository.
I have set up three repositories to reflect the three different strategies for combining a command and a library here:
The problem is, that without a replace directive inside the go.mod file of the command, there is no way to release the command and the library at the same time, because the command depending on the library needs to find it first.
However, having a replace directive, even if it is pointing to the same repository, is not supported by go install yet (see above).
Changing this would help a lot and I can't see a reason, why it should not be supported in this case, because the repository needs to be downloaded anyway to compile.
As it is, we need to make double releases all the time: first for the library and then for the command. But before the release of the command we first need to update the version of the library that the command depends on, although it is in the same repo! This is error prone, unnecessary work and confusing for the users, since the same version of library and command might behave differently.
Maybe this should be changed to be a proposal, since another request was closed as "works as intended". But I would say, that this is a very reasonable and useful request with minimal implementation impact.
So it is not about allowing replace directives in general to be used by go install, but only in the very specific case, when:
Example
would be valid
would not be valid.
From resolving the paths it is actually very easy to check, that
from
gitlab.com/metakeule/cmdlibprob3/cmd/cmdlibprob3
to
../../lib/cmdlibprob3
is resulting ingitlab.com/metakeule/cmdlibprob3/lib/cmdlibprob3
so this, is exacly the same as the original path and should be allowed.go.sum Problem
Tagging both versions at the same time is possible. But the go.sum file of the dependant package is always one commit behind.
The text was updated successfully, but these errors were encountered: