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

proposal: cmd/go: Reserve several simple package path prefix to the user, never use it in the standard library #34592

bronze1man opened this issue Sep 29, 2019 · 3 comments


Copy link

@bronze1man bronze1man commented Sep 29, 2019

From #34068 (comment)

Package paths that do not start with a domain name are in general reserved for the standard library. That rules out dotless names like app and make, especially in module mode.

That's a strange rule for me.And it is not compile error, so I do not notice that since now.
My private projects have used a lot of simple package path like GOPATH/src/make/run/main.go or GOPATH/src/make/tmp/main.go to simple build and run of those package with a private command line make run will build and run the package make/run. I need to set GOPATH first, if I want use go run before go.mod, So I write my own command line tool during go1.4 to not set the GOPATH before every call of go run.
Since I do not want to share the main package code with the world, why do I need the long domain name to type or write a script with another language every time I need to build/run my main package in my project?
A another reason to not use a domain name in package path is that the package path will go to the finally binary file. If I want the binary file have as less keywords as I want, i will not use a domain name in package path.

So I suggest golang leave several simple package path prefix to the user. And have a test to check that it never appear in the standard library. The main use case should be the exist

suggest for several simple package path prefix for the user:

  • GOPATH/src/a/
  • GOPATH/src/make/
  • GOPATH/src/config/


  • GOPATH/src/a/ for shorter package path in the private project, one letter should be the shortest one of them.
  • GOPATH/src/make/ for main package list in the private project, It is easy to list them and call them as they all exist in one directory. It is used heavily in my private project(100+ per project), another name should be ok for me. (I need rename all of them before I upgrade to the golang version that use it.)
  • GOPATH/src/config/ for packages that is used for project level config in golang code. Write config in the golang code is easy to deploy the finally binary into server or client.

I think GOPATH/src/vendor should also reserve to the user, there are several projects that can not compile because of this (#34068), but it has already used in go1.13

The GOPATH/src/internal do not need reserve to the user, as the private project is already internal.

@gopherbot gopherbot added this to the Proposal milestone Sep 29, 2019
@gopherbot gopherbot added the Proposal label Sep 29, 2019

This comment has been minimized.

Copy link

@dpinela dpinela commented Sep 29, 2019

I doubt the standard library is actually going to add a make or config package (and thus break your code) any time soon. If you nevertheless want to hedge against that, you could just switch to a short dotted name like or con.fig, which doesn't require any changes to the toolchain.


This comment has been minimized.

Copy link

@bcmills bcmills commented Sep 30, 2019

@bronze1man, note that in module mode, the module path does not need to appear in the file tree at all, and you can refer to paths within that module using the prefix ./.

So the benefit in terms of typing saved is already (mostly) achieved simply by switching to modules.


This comment has been minimized.

Copy link
Contributor Author

@bronze1man bronze1man commented Oct 1, 2019

Thanks for your reply.
Looks like I can just use a random prefix in the package path or rename my package when GOROOT use it if I want to type less in the GOPATH.
Reserve package path looks a bad idea for golang.

@bronze1man bronze1man closed this Oct 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.