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.

Sign up for GitHub

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

Jump to bottom

cmd/go: should 'go mod init' suggest (or run) 'go mod tidy'? #41712

Closed
bcmills opened this issue Sep 30, 2020 · 9 comments
Closed

cmd/go: should 'go mod init' suggest (or run) 'go mod tidy'? #41712

bcmills opened this issue Sep 30, 2020 · 9 comments
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Go1.16

Comments

@bcmills
Copy link
Contributor

bcmills commented Sep 30, 2020

(This issue is a follow-on to #40728, based on a discussion with @dr2chase.)

Now that we're defaulting to -mod=readonly, users who create a module from existing source code will generally need to run go mod tidy before they can actually build the packages in the module.

  • Should go mod init check for source files and suggest that command?
  • Should go mod init go ahead and tidy the module itself? (We don't know whether the user intends to prune out some nested modules before tidying, but nested modules should be rare anyway.)

CC @jayconrod @matloob
@bcmills bcmills added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. modules labels Sep 30, 2020
@bcmills bcmills added this to the Go1.16 milestone Sep 30, 2020
@bcmills bcmills changed the title cmd/go: should 'go mod init' suggest 'go mod tidy' if the module has existing source files? cmd/go: should 'go mod init' suggest (or run) 'go mod tidy'? Sep 30, 2020
@dr2chase
Copy link
Contributor

We could instead tie this to go build -- if go build sees no go.mod, and fails to find packages, it could suggest running go mod init and then go mod tidy. If it sees go.mod, and it is in the just-ran-go-init state, and fails to find packages, it could suggest running go mod tidy.

@bcmills
Copy link
Contributor Author

bcmills commented Sep 30, 2020

@dr2chase, as of CL 258298, go build will suggest running go get to obtain the missing package, although I suppose in theory we could further distinguish whether the importer is in the main module and suggest go mod tidy instead in that case.

@bcmills
Copy link
Contributor Author

bcmills commented Sep 30, 2020

Hmm, but that's a good point: we should not suggest go get or go mod tidy if we are not working within a module.

@jayconrod
Copy link
Contributor

I think go mod init should suggest go mod tidy if the directory is not empty and we aren't importing a configuration file from a vendoring tool. If the directory is empty, the user is creating a new project, and go mod tidy won't do anything yet. If we're importing a configuration file, go mod tidy might make sense, but we'll probably want different wording for the message.

I don't think go mod init should run go mod tidy automatically. It's almost always the next step, but I think if we keep those two commands discrete, users will be better able to understand their purposes. Users will learn that go mod tidy is the command that fixes dependencies. I'd be worried about people forgetting go mod tidy, then deleting go.mod and running go mod init again to fix dependencies.

@jayconrod
Copy link
Contributor

Something I noticed yesterday: when go mod init imports a vendoring configuration file (like Gopkg.lock), it translates the requirements pretty directly without fetching go.mod files or upgrading things for consistency with MVS. This conflicts with the new -mod=readonly default: you tend to start out with an inconsistent go.mod file, and you can't do anything until you run go mod tidy.

I still think go mod tidy should be an extra step, but go mod init should at least ensure an imported go.mod is consistent.

@gopherbot
Copy link

Change https://golang.org/cl/264623 mentions this issue: cmd/go: in 'go mod init', ensure imported requirements are consistent

@gopherbot
Copy link

Change https://golang.org/cl/264622 mentions this issue: cmd/go: in 'go mod init', suggest running 'go mod tidy'

@gopherbot
Copy link

Change https://golang.org/cl/264621 mentions this issue: cmd/go: refactor modload.InitMod

gopherbot pushed a commit that referenced this issue Oct 23, 2020
cmd/go: refactor modload.InitMod
d05e89a 
InitMod is split into two functions. LoadModFile parses an existing
go.mod file and loads the build list (or checks vendor/modules.txt for
consistency in vendor mode). CreateModFile creates a new go.mod file,
possibly inferring the module path and importing a vendor
configuration file.

Some logic is moved from runInit to CreateModFile. init-specific logic
is removed from other functions.

This CL shouldn't cause substantial differences in behavior, though
some error messages are slightly different.

For #41712

Change-Id: Ia684945cfcf5beca30bbb81e7144fc246c4f27ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/264621
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
gopherbot pushed a commit that referenced this issue Oct 23, 2020
cmd/go: in 'go mod init', suggest running 'go mod tidy'
5f616a6 
When 'go mod init' is run in an existing project, it may import
requirements from a vendor configuration file, but the requirements
may not be complete, and go.sum won't contain sums for module
zips. With -mod=readonly, the next build command is likely to fail.

'go mod init' will now suggest running 'go mod tidy' if there are .go
files or subdirectories in the current directory.

We could potentially run 'go mod tidy' automatically within
'go mod init', but it seems better to guide users to using 'go mod tidy'
as a separate command to fix missing dependencies.

For #41712
Updates #40278

Change-Id: Iaece607f291244588a732ef4c5d576108965ca91
Reviewed-on: https://go-review.googlesource.com/c/go/+/264622
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@jayconrod
Copy link
Contributor

Resolving this issue. It still seems better to me for go mod tidy to be a separate step. Please comment if you feel otherwise.

As of 1.16beta1, go mod init will suggest running go mod tidy if there are .go files in the current directory and no vendor configuration file is imported.

@jayconrod jayconrod mentioned this issue Jan 5, 2021
Closed
@golang golang locked and limited conversation to collaborators Jan 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Go1.16
Development

No branches or pull requests
4 participants
@jayconrod @dr2chase @bcmills @gopherbot