-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: document that module names without dots are reserved #32819
Comments
The title contains "modules", but I assume this would apply to the |
Small detail I forgot - it's a dot in the first path element. |
Another small detail. It's not correct to say "all import paths without dots are reserved by the standard library", because there are a few counter-examples. Use Both I'm also a bit surprised that the two commands above give different package paths. I think that's counter-intuitive, but maybe there's a good reason for it. |
Import paths without dots are reserved for the standard library and toolchain.
|
Thanks, I like that wording. It's clear in my mind now. I'll have a look at sending a CL before the freeze is over :) |
I'd like to work on this this cycle. Any thoughts on where such a piece of documentation could go? I'm thinking either |
https://golang.org/ref/mod would be best. Ideally |
A separate but still related issue: tinygo is a different implementation of Go, and it adds its own standard library packages, much like However,
I think, to allow modules to play nicer with alternative Go implementations, we should allow it to ignore reserved package paths that it doesn't know about. |
@mvdan, |
Hm, doesn't that contradict what we said earlier in the thread?
|
Ah, yeah. I see what you mean. They are reserved for the Go standard library — not for adjacent projects. (Edited my reply above.) |
Hi all! Author of TinyGo here. You might want to read my previous comment on the issue: #43079 (comment) I am well aware of this issue and I like to change it, but it will be a major breaking change so I'd like to provide a soft transition path. The proposal in #34055 would be a big help to allow that to happen, and luckily it appears to lean towards being accepted. These reserved paths made sense when I started the project but especially now with Go modules it's becoming a compatibility issue (something which I've wanted to avoid). EDIT: although I should add that it's still important that if you put |
An upcoming change in |
Change https://golang.org/cl/359594 mentions this issue: |
I wonder if I ran into this today as I assumed |
I don't think we should bother setting |
Yeah, that's fair. I was a bit on the fence about that, and I guess I can implement the "reserved" logic myself if I want to. |
Intuitively, most Go developers publish Go code under import paths like
foo.com/bar
, notfoo/bar
. Often, this is just to make them reachable on the internet.However, some have avoided the
.tld
entirely when working with local-only GOPATHS and modules. And this mostly works, as long as you're careful to not clash with an existing standard library package.For example, I recall a recent issue in this tracker (which I can't find now!) where their GOPATH build broke when upgrading the Go version, as the root path element was
plugin
, which had been added to the standard library since.An instance of this discussion happened last September, as pointed out by @bcmills. Quoting @rsc:
However, this separation isn't well documented anywhere. Even if we consider it as a warning or recommendation more than a strict rule, I think we should still mention it somewhere.
I also think we should encourage the use of
.tld
even if the module is for local use only, because of potential breakages with future Go builds. Perhaps a suggestion can be made, like.local
.Another advantage of strongly encouraging the use of
.tld
is that it's much easier to tell if a package is from the standard library or not. Without the separation, one would have to keep a list of all standard library package paths, which easily gets out of date. Or rungo list std
, which adds work.Note that this doesn't need to change how
cmd/go
behaves; it's fine if a module name without a dot happens to build today.The text was updated successfully, but these errors were encountered: