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: should 'go mod init' suggest (or run) 'go mod tidy'? #41712

Open
bcmills opened this issue Sep 30, 2020 · 4 comments
Open

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

bcmills opened this issue Sep 30, 2020 · 4 comments
Milestone

Comments

@bcmills
Copy link
Member

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

@dr2chase dr2chase commented Sep 30, 2020

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
Member Author

@bcmills 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
Member Author

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

@jayconrod jayconrod commented Oct 1, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.