x/vgo: support module path without dot

[flibustenet]

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

go version go1.10 linux/amd64 vgo:2018-02-20.1

What did you do?

Trying to work with local packages with my own apps and libs.
Because they are locals i didn't put a package path with dot
My app is under ./app my lib is under ./mylib
The package of mylib is just mylib

$cat ./app/go.mod

module "testvgo"

require "mylib" v0.1.0

replace "mylib" v0.1.0 => "../mylib"

vgo doesn't find ../mylib

$ vgo list -m
MODULE        VERSION
testvgo       -
mylib         v0.1.0
 => ../mylib

$vgo build
vgo: import "testvgo" ->
	import "mylib" [/usr/local/go/src/mylib]: open /usr/local/go/src/mylib: no such file or directory

Now if i change mylib by libs.me\mylib it works

module "testvgo"

require "libs.me/mylib" v0.1.0

replace "libs.me/mylib" v0.1.0 => "../mylib"

What did you expect to see?

I expect it could work with a simple package path without dot

However it's not a problem for me if a dot is mandatory when it's best practice, I just want to be sure I didn't missed something.

[flibustenet]

Asking in the ML the answer is quitte evident.

Vgo implements a package manager which is suppose to download dependencies
from some remote host.
It determines where to fetch the code by looking at the import path of the
dependency.
Hence All dependencies which are managed with the new vgo mechanism musst
follow this import path convention.
Other dependencies are either the std lib, I guess this is a special case

I let open this issue to maybe put it in the FAQ.

[4ad]

I disagree with the assertions does in that ML thread. vgo should support pure local development just like the go tool does. And mylib could also well be an internal server, even if it doesn't contain a dot. This is a bug.

[tv42]

Using dotless import paths for your own projects is just as bad of an idea as using the .dev top-level DNS domain for development was. If the stdlib ever adds a package named mylib, things break. Use proper namespaces, even if your names aren't visible to anyone outside your organization.

[flibustenet]

I'm agree but dotless import path is in many places in the official documentation for a starting project... Also mentioned as a practice at Google !
https://golang.org/doc/install#testing
https://blog.golang.org/organizing-go-code

Without GOPATH it can be more tempting also.

[tv42]

@flibustenet Those links very much encourage the github.com/golang/example style. I'm willing to concede that dotless imports seem to be unfortunately used, but please let's not encourage them.

(Side note, Google internal usage is probably irrelevant, as as far as we on the outside know they don't use the go build system anyway.)

[rsc]

The go build system already assumes in some places the dotless prefixes mark the standard library, so @tv42 is right that using it places you on thin ice. At the same time, I don't think this specific failure is too hard to fix, so we can look into fixing it.

[rsc]

If it's too hard to fix, though, we'll just mark it working as intended.

[gopherbot]

Change https://golang.org/cl/107661 mentions this issue: cmd/go/internal/vgo: allow dotless module paths if replaced