You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
@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.
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.
From #34068 (comment)
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 likeGOPATH/src/make/run/main.go
orGOPATH/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 packagemake/run
. I need to set GOPATH first, if I want usego run
beforego.mod
, So I write my own command line tool during go1.4 to not set the GOPATH before every call ofgo 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 existsuggest for several
simple
package path prefix for the user:reason:
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
.The text was updated successfully, but these errors were encountered: