Skip to content
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 -getmode=noauto #26361

Closed
rsc opened this issue Jul 13, 2018 · 4 comments
Closed

cmd/go: add -getmode=noauto #26361

rsc opened this issue Jul 13, 2018 · 4 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Jul 13, 2018

CI systems need a way to test what's in the go.mod and fail if something is missing instead of looking to satisfy dependencies automatically. We meant for -getmode=local to mean this, but it really means something a little bit different. We should add a -getmode that does mean "you can't change go.mod". Maybe -getmode=noauto.

/cc @bcmills

@rsc rsc added this to the Go1.11 milestone Jul 13, 2018
@NfNitLoop
Copy link

NfNitLoop commented Jul 13, 2018

🚲 Don't want to get too far into painting the bike shed but a name like -getmode=repeatable or -getmode=read-only might make it more clear what that means.

I'm completely fine with it trying to automatically satisfy dependencies by downloading them. I just want to make sure there's a mode that will only download the exact versions which are captured in the go.mod/go.sum files and doesn't do anything beyond that.

(My personal preference would be that go build would default to such a mode for repeatable builds, and warn you if you need to run some command to update the file. But I understand that's likely been discussed and decided elsewhere.)

@bcmills
Copy link
Contributor

bcmills commented Jul 13, 2018

We meant for -getmode=local to mean this, but it really means something a little bit different.

I'm not actually sure what it means at the moment (see #26370). But I agree that we probably do want separate modes for “use only modules that are available” and “don't modify my go.mod at all”.

@bcmills
Copy link
Contributor

bcmills commented Jul 13, 2018

I don't think noauto fits in as a -getmode flag.

Currently, GO111MODULE determines whether we use modules and -getmode determines how we fetch them.

In contrast, CI systems may or may not care about how we fetch modules. (For example, a CI system with a reliable connection to a GOPROXY should be happy to fetch the modules from it on demand.) The important property for CI testing is that the module configuration does not change, and to me that seems more like a GO111MODULE setting than a getmode.

So I would suggest instead a new GO111MODULE setting, GO111MODULE=readonly. That would mean “fetch the active modules according to -getmode, but do not adjust go.mod or resolve imports that it does not provide”.

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 16, 2018
@gopherbot
Copy link

Change https://golang.org/cl/126696 mentions this issue: cmd/go: replace -getmode with -mod, $GOPROXY

@golang golang locked and limited conversation to collaborators Aug 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Development

No branches or pull requests

4 participants