Open maeglindeveloper opened 6 years ago
@bcmills
@maeglindeveloper: There might well be a better answer, but I think one approach would be to run go get myrepo2@dev
in myrepo1 just before you want to test myrepo1. I suspect that would update the go.mod
file in myrepo1 to record the current meaning of the dev
branch for myrepo2 as a pseudo-version in the corresponding require
directive (without you needing to have tagged myrepo2 just before testing, which I think is part of your concern).
I have not tested your specific case before, but some related snippets from the documentation:
The go command accepts a "module query" in place of a module version both on the command line and in the main module's go.mod file. (After evaluating a query found in the main module's go.mod file, the go command updates the file to replace the query with its result.)
and (with emphasis added):
A revision identifier for the underlying source repository, such as a commit hash prefix, revision tag, or branch name, selects that specific code revision. If the revision is also tagged with a semantic version, the query evaluates to that semantic version. Otherwise the query evaluates to a pseudo-version for the commit.
and:
go get github.com/gorilla/mux@master # records current meaning of master
Those snippets are from a few different sections of the doc, but this section is perhaps most relevant: https://tip.golang.org/cmd/go/#hdr-Module_queries
Sorry if that is off base, but what do you think about trying that?
@maeglindeveloper and there is a little more background here:
https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies
I think part of the intent of modules is: "Day-to-day adding, removing, upgrading, and downgrading of dependencies should be done using 'go get', which will automatically update the go.mod file."
In addition, my understanding is the default behavior of a go.mod
file is that it locks the versions of dependencies into place until some other action occurs (in order to have reproducible builds).
Taking all of that together, maybe it is not crazy that go get
is a mechanism to tell one of your modules to update which version of your second module should be used at a given point in time?
(And go get
is one option, but I think a more-or-less equivalent option is editing the go.mod
directly to include the @dev module query, which I think then would be automatically converted and recorded back to the go.mod
file as a pseudo-version... Between those two workflows, it would then depend whether you prefer to run a command like go get
vs. edit a file).
Note that go mod -sync does not update dependencies. We renamed it to go mod tidy, which hopefully will be less confusing in that respect. go get -u is what updates dependencies, or just 'go get dependency-name', which defaults to @latest.
The command you want for an explicit update right now is just
go get myrepo2@dev
I've been thinking for a while about whether to have a special comment in the go.mod that means "when you update, look for this branch", in which case you could use go get -u
instead, but of course go get -u
would do all dependencies. If you really just want myrepo2, then go get myrepo2@dev
at least clearly expresses that.
The tricky part about a “use this branch” annotation is transitive dependencies.
If module A
depends on B
and C
, and B
depends on D@master
, and C
depends on D@dev
, what should happen if I go get -u
within A
?
For replace
directives, at least there is a clear answer: we use whichever branch A
specified explicitly, and otherwise we use the master
branch.
So I think if we support this sort of branch redirect, it — like replace
— should be local to the module in which it appears.
We definitely can't respect those annotations in dependencies. We might respect an annotation like that in the current go.mod.
Linking back the other way, I think this is probably related to/dup of https://github.com/golang/go/issues/26853
go get -u myrepo2@dev
This doesn't seem to work right if there is a replace
directive.
In our case we need to support the use of Gitlab subgroups, so we have to use a replace directive like:
require gitlab.acmecorp.uk/foo/bar/project v0.0.0-20190225143601-609ef8e30e26
replace gitlab.acmecorp.uk/foo/bar/project => gitlab.acmecorp.uk/foo/bar/project.git v0.0.0-20190225143601-609ef8e30e26
Using go get -u gitlab.acmecorp.uk/foo/bar/project@master
will change the go.mod file so it's:
require (
gitlab.acmecorp.uk/foo/bar/project v0.0.0-20190225143601-609ef8e30e26
gitlab.acmecorp.uk/foo/bar/project.git v0.0.0-20190225153601-12312312312
)
replace gitlab.acmecorp.uk/foo/bar/project => gitlab.acmecorp.uk/foo/bar/project.git v0.0.0-20190225143601-609ef8e30e26
At least it's generating the version string so I can copy that into the right place, but usability-wise it's a bit of a nightmare.
@Xiol, the behavior you are describing is #28176, but the particular use-case (resolving an import of /git
to the repository at /project.git
) is better suited to go-import
tagging than to replace
directives.
I have a same problem. But I fixed it by making sure there are no Go files using or refer to master
.
I hope it can help you too.
I'm using OpenAPI Generator trying to merge different language SDK into same repo,that cause I need go get can track on specified branch or it will take the wrong commit or tag with other language....
Hi everyone,
I already posted an issue regarding go.mod files. https://github.com/golang/go/issues/26640
This one is a little bit different but little bit linked to that old one.
I'm actually developping multiple repositories using 2 branches master and dev. Those branches are defined for each repositories. Lets assume I have the following ones:
I was wondering if there is a way to specify a branch for a specific repository inside the go.mod file. For instance:
The reason why I'm asking that is that, when I'm actually runing the
go mod -sync
cmd in my repo2, it will always check for the last commit in master (or maybe I'm wrong?). But I would like that it looks into my dev branch for the last commit.So I was thinking that maybe I can tag my dev branch and then specify the version I want to grab but it means that I will need to tag everytime I want to test my dev branch.
Does anyone have already face that pb?
Hope my explanations are clear :s
Thanks in advance ! :) @rsc