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

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

Closed
bronze1man opened this issue Sep 29, 2019 · 3 comments
Closed

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
Labels
FrozenDueToAge Proposal
Milestone
Proposal

Comments

@bronze1man
Copy link
Contributor

bronze1man commented Sep 29, 2019 •
edited

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 tool.xxx 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/

reason:

  • 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
@dpinela
Copy link
Contributor

dpinela commented Sep 29, 2019 •
edited

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 ma.ke or con.fig, which doesn't require any changes to the toolchain.

@bcmills
Copy link
Contributor

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.

@bronze1man
Copy link
Contributor Author

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.

@bcmills bcmills mentioned this issue Mar 3, 2020
Closed
@golang golang locked and limited conversation to collaborators Sep 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
4 participants
@bronze1man @dpinela @bcmills @gopherbot