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: add signal for `go get -u` to track branch? #26964

Open
maeglindeveloper opened this Issue Aug 13, 2018 · 8 comments

Comments

Projects
None yet
7 participants
@maeglindeveloper

maeglindeveloper commented Aug 13, 2018

Hi everyone,

I already posted an issue regarding go.mod files.
#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:

  • myrepo1 (dev and master) using myrepo2
  • myrepo2 (dev and master)

I was wondering if there is a way to specify a branch for a specific repository inside the go.mod file.
For instance:

module github.com/myrepo1

require (
	github.com/myrepo2 v@sometag or @somebranch
}

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

@andybons

This comment has been minimized.

Member

andybons commented Aug 13, 2018

@thepudds

This comment has been minimized.

thepudds commented Aug 13, 2018

@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?

@thepudds

This comment has been minimized.

thepudds commented Aug 13, 2018

@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?

@thepudds

This comment has been minimized.

thepudds commented Aug 13, 2018

(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).

@rsc rsc changed the title from cmd/go: go modules from branches to cmd/go: add signal for `go get -u` to track branch? Aug 18, 2018

@rsc

This comment has been minimized.

Contributor

rsc commented Aug 18, 2018

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.

@rsc rsc added the NeedsDecision label Aug 18, 2018

@rsc rsc modified the milestones: Unplanned, Go1.12 Aug 18, 2018

@bcmills

This comment has been minimized.

Member

bcmills commented Sep 6, 2018

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.

@rsc

This comment has been minimized.

Contributor

rsc commented Oct 24, 2018

We definitely can't respect those annotations in dependencies. We might respect an annotation like that in the current go.mod.

@myitcv

This comment has been minimized.

Member

myitcv commented Oct 25, 2018

Linking back the other way, I think this is probably related to/dup of #26853

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment