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

x/tools/gopls: handle import aliases automatically #40278

Closed
muirdm opened this issue Jul 17, 2020 · 4 comments
Closed

x/tools/gopls: handle import aliases automatically #40278

muirdm opened this issue Jul 17, 2020 · 4 comments

Comments

@muirdm
Copy link

@muirdm muirdm commented Jul 17, 2020

It is annoying when your file needs to import multiple packages with the same name. Tooling often offers no relief from having to manually import and alias the second package. It would be nice if gopls could help by automatically adding package import aliases when possible and appropriate.

I propose we do something like this to start:

  1. When loading packages we keep track of package aliases we see in existing imports. We could store the alias counts by containing package to avoid over counting as a package gets re-type checked.
  2. When offering unimported package completions, if a candidate package's name is already used by an existing import in the file, automatically include the "best" alias we have seen elsewhere for that package. We probably want to make the aliased unimported package addressable by both the alias and the package name since the user may or may not anticipate the alias.
@gopherbot gopherbot added this to the Unreleased milestone Jul 17, 2020
@heschi
Copy link
Contributor

@heschi heschi commented Jul 17, 2020

Think this is a dupe of https://golang.org/issue/36077#issuecomment-567741352. Though goimports currently only scans the current package and gopls could do more.

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 23, 2020

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

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 23, 2020

Change https://golang.org/cl/264620 mentions this issue: cmd/go: don't import requirements into existing go.mod files

gopherbot pushed a commit that referenced this issue Oct 23, 2020
Previously, if a go.mod file was present, and it only contained a
module directive, any module-aware command would attempt to import
requirements from a vendor configuration file like Gopkg.lock.

This CL removes that functionality. It was undocumented and untested,
and it can cause problems with -mod=readonly. It should never come up
for go.mod files created with 'go mod init', since they have a "go"
directive.

For #40278

Change-Id: I64c0d67d204560aa5c775d29553883d094fd3b72
Reviewed-on: https://go-review.googlesource.com/c/go/+/264620
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopherbot pushed a commit that referenced this issue Oct 23, 2020
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>
@gopherbot
Copy link

@gopherbot gopherbot commented Dec 21, 2020

Change https://golang.org/cl/279490 mentions this issue: cmd/go: set cfg.BuildMod to "readonly" by default with no module root

gopherbot pushed a commit that referenced this issue Jan 5, 2021
modload.Init now sets the default value for -mod if it wasn't set
explicitly. This happens before go.mod is loaded, so
modload.LoadModFile sets the default value again in order to enable
automatic vendoring.

Previously, cfg.BuildMod wasn't set at all if LoadModFile wasn't
called, as is the case for commands that run outside of a module
root. This problem only affected 'go install pkg@version' since other
commands are either forbidden in module mode or run with -mod=mod
(like 'go get' and 'go mod' subcommands).

This change also suppresses "missing sum" errors when -mod=readonly is
enabled and there is no module root.

Fixes #43278
Related #40278

Change-Id: I6071cc42bc5e24d0d7e84556e5bfd8e368e0019d
Reviewed-on: https://go-review.googlesource.com/c/go/+/279490
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
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