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

Jump to bottom

cmd/go: diagnose collisions between standard-library packages and packages provided by modules #39285

Closed
mdempsky opened this issue May 27, 2020 · 6 comments
Closed

cmd/go: diagnose collisions between standard-library packages and packages provided by modules #39285

mdempsky opened this issue May 27, 2020 · 6 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@mdempsky
Copy link
Member

mdempsky commented May 27, 2020 •
edited

As discussed on golang-dev@, this currently runs without warnings/errors, but doesn't do what I'd intuitively expect:

$ go mod init example.com/main
go: creating new go.mod: module example.com/main
$ go mod edit -replace go/types=./nonexist
$ echo 'package main; import _ "go/types"; func main() {}' > main.go
$ go build .

/cc @bcmills

Edit: For posterity, my "intuitively expected" behavior here is/was that the import of "go/types" should be remapped to "./nonexist", and cause a build error because it doesn't exist.
@andybons andybons added GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 28, 2020
@andybons andybons added this to the Unplanned milestone May 28, 2020
@bcmills
Copy link
Contributor

bcmills commented May 29, 2020 •
edited

If the replacement path is ./nonexist, then this is working as intended: you could use this approach to slot in experimental subpackages (perhaps named go/types/internal and go/types/generic 😁) without modifying the rest of the standard library.

The thing we should diagnose is a module (either the main module or one slotted in by a replace directive) for which the target contains at least one .go source file at the same import path as a standard-library package, which we apparently do not today:
https://play.golang.org/p/WMIbECf3o0s

@bcmills bcmills added the modules label Jun 1, 2020
@bcmills bcmills modified the milestones: Unplanned, Backlog Jun 1, 2020
@bcmills bcmills changed the title cmd/go: should warn/error about replacements of standard library packages cmd/go: diagnose collisions between standard-library packages and packages provided by modules Jun 1, 2020
@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Jun 1, 2020
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 1, 2020
@deven96
Copy link

deven96 commented Aug 26, 2020

By diagnose, what exactly do you expect @bcmills , a log that warns of collisions at the same import path?
Can I work on this as a first time contributor?

@bcmills
Copy link
Contributor

bcmills commented Aug 28, 2020

By “diagnose” I mean ”emit an error for the affected packages if they are ever loaded”.

I wouldn't recommend that anyone work on this issue right now, because I'm in the middle of refactoring the module-mode loader for #36460 and the merge conflicts would probably be pretty unpleasant.

@bcmills
Copy link
Contributor

bcmills commented Nov 19, 2020 •
edited

This also isn't specific to replace directives, since the main module itself could have a name that is (or is a prefix of) a package path in the standard library (#42721).

@bcmills bcmills mentioned this issue Nov 19, 2020
Closed
@luojiego
Copy link

luojiego commented Jan 5, 2022

go mod init http is ok, but when I use go mod init sort, Something terrible happened, the VS Code Show me an error.
image
But it was still good a few days ago. I began to suspect that it was a problem with VS Code, and then a problem with the Go version. Until I reinstalled them all, I even tried to download GoLand to find a solution. Finally I found could‘t use sort. This feels too bad. If all the package names of the standard library cannot be used, I agree. But some work, some don't work, I think this is a bug.

@bcmills bcmills mentioned this issue Feb 4, 2022
Closed
@bcmills
Copy link
Contributor

bcmills commented Jun 15, 2022

Duplicate of #35270

@bcmills bcmills marked this as a duplicate of #35270 Jun 15, 2022
@bcmills bcmills closed this as not planned Won't fix, can't repro, duplicate, stale Jun 15, 2022
@bcmills bcmills mentioned this issue Feb 6, 2023
Closed
@golang golang locked and limited conversation to collaborators Jun 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
6 participants
@mdempsky @andybons @luojiego @bcmills @gopherbot @deven96