Navigation Menu

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

cmd/go: mod -init does not accept a module path without a dot #26510

Closed
radutopala opened this issue Jul 20, 2018 · 6 comments
Closed

cmd/go: mod -init does not accept a module path without a dot #26510

radutopala opened this issue Jul 20, 2018 · 6 comments
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@radutopala
Copy link

radutopala commented Jul 20, 2018

What version of Go are you using (go version)?

go version go1.11beta2 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/home/go"
GOPROXY=""
GORACE=""
GOROOT="/home/sdk/go1.11beta2"
GOTMPDIR=""
GOTOOLDIR="/home/sdk/go1.11beta2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/cv/94d8q7ws3wz1yfhgb570qnl00000gn/T/go-build042987197=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I'm outside of the GOPATH.

cd /www/application
go mod -init -module application

What did you expect to see?

go.mod created with

module application

require (
	golang.org/x/net v0.0.0-20171004034648-a04bdaca5b32
)

What did you see instead?

go1.11beta2 mod -init -module application                                                                                                                     
go mod: invalid -module: malformed module path "application": missing dot in first path element

We should be allowed to set a module name as "application" or whatever string, and not being restricted to "github.com/radutopala/application" or "domain.ext/package".

@oiooj oiooj added the modules label Jul 20, 2018
@mvdan
Copy link
Member

mvdan commented Jul 20, 2018

This seems like an almost exact duplicate of #24100. Although it seems like the fix in that issue did not involve go mod -init, so perhaps this piece was forgotten.

cc @rsc

@mvdan mvdan added this to the Go1.11 milestone Jul 20, 2018
@mvdan mvdan added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jul 20, 2018
@mvdan mvdan changed the title go.mod init issue on module naming cmd/go: mod -init does not accept a module path without a dot Jul 20, 2018
@mpx
Copy link
Contributor

mpx commented Aug 1, 2018

Ideally package import paths without a dot should work fine (it's not required by the spec). I was just unable to use a -replace command. Eg:

$ GO111MODULE=on go mod edit -replace foo=../foo
go mod: -replace=foo=../foo: invalid old path: malformed module path "foo": missing dot in first path element

Manually editing the go.mod to add the require/replace lines does work.

I think non-dot top level paths should continue to be properly supported by the tooling. Many people have been using top level non-dot directories in their private GOPATH repos over the years. Ideally anyone in this situation should be able to use modules for the improved dependency management. Some orgs may even support go get via GOPROXY.

@mpx
Copy link
Contributor

mpx commented Aug 1, 2018

@radutopala mod init works for me with a more recent compiler:
go version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000 linux/amd64

Looks like the initial issue has been solved.

Perhaps I should move the larger problem with tooling supporting import paths without dots to another issue?

@radutopala
Copy link
Author

@mpx I'll check soon, thx

@bcmills
Copy link
Contributor

bcmills commented Aug 3, 2018

Perhaps I should move the larger problem with tooling supporting import paths without dots to another issue?

Yes, please file that separately.

Just to be clear, it is unlikely that we will support module paths without dots: dotless import paths are in general reserved for the standard library. (Modules intentionally use URI paths to avoid collisions.)

@bcmills
Copy link
Contributor

bcmills commented Aug 3, 2018

Looks like the initial issue has been solved.

Thanks, closing out this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

6 participants