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.

Sign up for GitHub

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

cmd/go: mod init and mod edit unable to import module paths missing a dot #29620

Closed
roblillack opened this issue Jan 8, 2019 · 4 comments
Closed

cmd/go: mod init and mod edit unable to import module paths missing a dot #29620

roblillack opened this issue Jan 8, 2019 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@roblillack
Copy link

roblillack commented Jan 8, 2019 •
edited

Overview and related issues

This issue seems to be related to #26510. But in this case, not the actual module I am working with is "dotless," but a dependency.

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

go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rob/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/rob/dev/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.4/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.4/libexec/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/19/2k3s854n17d44rsgblw41www0000gn/T/go-build831329113=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Trying to initialize Go Modules with go mod init in a go package that has a “dotless” package dependency (package name “projectx”) which is to be downloaded from a location that cannot be deducted from the package name (might be an internal git server, etc.) configured using glide.yaml:

package: github.com/roblillack/my-internal-go-tool

import:
  - package: projectx
    repo: git@github.com:roblillack/my-internal-go-library.git

(You can clone a the repo with this testcase from https://github.com/roblillack/my-internal-go-tool)

What did you expect to see?

I expected a go.mod being created like this:

module github.com/roblillack/my-internal-go-tool

require projectx v0.0.0-20190108172907-e2cf823506ac

replace projectx => github.com/roblillack/my-internal-go-library v0.0.0-20190108172907-e2cf823506ac

And this should have been the output of go run .:

$ go run .
go: downloading github.com/roblillack/my-internal-go-library v0.0.0-20190108172907-e2cf823506ac
Hello from Project X.
$

What did you see instead?

$ go mod init
go: creating new go.mod: module github.com/roblillack/my-internal-go-tool
go: copying requirements from glide.lock
go: converting glide.lock: stat projectx@e2cf823506ac75c09972462f36e747f437d1585a: unrecognized import path "projectx" (import path does not begin with hostname)
$

… and go.mod looks like this:

module github.com/roblillack/my-internal-go-tool

// go: no requirements found in glide.lock

This way, of course go run . does not work:

go run .
build github.com/roblillack/my-internal-go-tool: cannot find module for path projectx

Likewise, adding the dependency using go mod edit does not work, too:

$ go mod edit -require projectx@latest -replace projectx=github.com/roblillack/my-internal-go-library
go mod: -require=projectx@latest: invalid path: malformed module path "projectx": missing dot in first path element
$

When creating/editing the require & replace actions in go.mod manually, go run . will work as expected.
@agnivade
Copy link
Contributor

agnivade commented Jan 9, 2019

/cc @bcmills

@agnivade agnivade added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 9, 2019
@mvdan
Copy link
Member

mvdan commented Jan 9, 2019

Previous related issue: #26894

What I personally do is set up a ~/.netrc file, and then I can just use HTTPS for private repos - this includes the ones at work where we use Go modules. Not saying it's the best way, but it's certainly an alternative that works now.

@bcmills
Copy link
Contributor

bcmills commented Jan 9, 2019

The fact that we do not convert replacement paths from glide.yaml is #25556.

Dotless paths are in general reserved for the Go standard library. They do not work with go get in GOPATH mode, and they do not work with go get in module mode. (It's unlikely that we'll use projectx in particular, but I don't see a compelling reason to relax the general rule.)

For internal Git servers, my recommendation is to give the server a proper, resolvable two-level DNS name rather than relying on replace directives.

@bcmills bcmills closed this as completed Jan 9, 2019
@roblillack
Copy link
Author

roblillack commented Jan 9, 2019 •
edited

Thanks @bcmills. Regarding

Dotless paths are in general reserved for the Go standard library.

and

I don't see a compelling reason to relax the general rule.

can you please point me to a place where this (new to me) rule is defined? I cannot find it in any of these locations:

I do understand that using what the documentation calls “remote import paths” is an encouraged convention. If, for whatever reason, having non-resolvable or dotless names as import path prefixes is discouraged from now on, I'd love to see it officially documented somewhere.

For the record, an actual related issue seems to be #27503.

@golang golang locked and limited conversation to collaborators Jan 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@roblillack @agnivade @mvdan @bcmills @gopherbot