ctx.DetectProjectGOPATH: both C:\Work\src\github.com\F21\some_project are in the same GOPATH C:\Work\src\github.com\F21\some_project with Git Bash

[F21]

What version of Go (go version) and dep (git describe --tags) are you using?

Go 1.9-Beta1 and dep c79b048
Git is 2.13.1.windows.1

What dep command did you run?

I have a project with this structure

• cmd
  • some_executable
    • main.go
• some_package (imports the some_project package)
• something.go (package is some_project)

$ dep init -v

What did you expect to see?

There should be no error and init should work correctly.

What did you see instead?

ctx.DetectProjectGOPATH: both C:\Work\src\github.com\F21\some_project and C:\Work\src\github.com\F21\some_project are in the same GOPATH C:/Work/

[sdboyer]

@ibrasho i think we may have broken windows support :(

[F21]

Git repro demonstrating the issue here: https://github.com/F21/dep-gopath-err

[ibrasho]

This error makes no sense. 😕

What's the value of GOPATH in Git Bash and the command prompt (echo %GOPATH%)?

[F21]

@ibrasho In both Git Bash and CMD, the GOPATH are set to C:\Work. I confirmed this by echoing the respective GOPATH environment variable in each shell.

[ibrasho]

Copying from Slack:

@F21: I get the problem if I run it in Git bash in admin mode, but not in the cmd shell using cmder
in both shells, the GOPATH env var resolves to C:/work
seems to not work in git bash
whether git bash is being run as admin or not

[ibrasho]

ctx.DetectProjectGOPATH: both C:\Work\src\github.com\F21\some_project and C:\Work\src\github.com\F21\some_project are in the same GOPATH C:/Work/

This error message means the following values were set and detected:

Varible	Value
Project.AbsRoot	C:\Work\src\github.com\F21\some_project
Project.ResolvedAbsRoot	C:\Work\src\github.com\F21\some_project
Ctx.GOPATH	C:/Work/

This line in Ctx.DetectProjectGOPATH should have returned true on these values and returned the GOPATH with no error.

@F21 I would appreciate it if you have time to debug this further.

[F21]

@ibrasho

Just tried this on my dev machine with git bash:

$ echo $GOPATH
D:\10-workspace\go

$ dep init
ctx.DetectProjectGOPATH: both D:\10-workspace\go\src\github.com\some_company\some_project and D:\10-workspace\go\src\github.com\some_company\some_project are in the same GOPATH D:/10-Workspace/go

[ibrasho]

Could you try running this gist and report what it outputs?

[F21]

Running it in git bash:

$ go run main.go
absRoot: D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else
resolvedAbsRoot: D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else
absRoot == resolvedAbsRoot: false
GOPATHs: [D:\10-workspace\go]
trying to detect GOPATH for D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else
        D:\10-workspace\go: true
trying to detect GOPATH for D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else
        D:\10-workspace\go: true
detectProjectGOPATH: both D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else and D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else are in the same GOPATH D:\10-workspace\go

Running it in cmder/cmd

λ go run main.go
absRoot: D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else
resolvedAbsRoot: D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else
absRoot == resolvedAbsRoot: true
GOPATHs: [D:\10-workspace\go]
trying to detect GOPATH for D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else
        D:\10-workspace\go: true
GOPATH: D:\10-workspace\go

[ibrasho]

Could you update dep and try dep init in that directory?

[F21]

Updated dep to ec50ada

here's what I get:

$ dep init
ctx.DetectProjectGOPATH: both D:\10-workspace\go\src\github.com\F21\dep-gopath-err and D:\10-workspace\go\src\github.com\F21\dep-gopath-err are in the same GOPATH D:\10-workspace\go

$ cd cmd/something_else/

$ dep init
ctx.DetectProjectGOPATH: both D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else and D:\10-workspace\go\src\github.com\F21\dep-gopath-err\cmd\something_else are in the same GOPATH D:\10-workspace\go

[ibrasho]

I assume this is Git Bash? What about Cmder?

[F21]

Yes, it's only failing in git bash. Cmder/cmd works fine.

[ibrasho]

We are reaching somewhere at least. 😁

Do you have any idea why Git Bash handles paths differently?

[F21]

I quick guess is probably that backward slashes do not work in git bash.

For example, if I have D:/some/path, if I am in the D drive and type some\pa, pressing tab to autocomplete does not work.

[sdboyer]

Does #780 fix this?

[F21]

Built the latest master, but still seeing the same issue with git bash.

[ibrasho]

#780 only effects dep prune. This one is a bit complicated and I'm not able to determine the root cause yet.

It works fine on Cmder/cmd but it doesn't on Git Bash. The gist output on Git Bash doesn't make much sense. 😕

[dinazil]

For me it doesn't work in simple cmd.
And what's really weird is that it DOES work for a colleague of mine. With the same repo and the same dep version.

[davidovich]

If it helps, this is also happening to me on Windows. I can reproduce in a debugger by placing a lowercase drive letter in the working directory. For example, run dep init in a D:\go\src\myproject and setting the cwd to d:\go\src\myproject The following (in DetectProjectGOPATH() github.com\golang\dep\context.go)

	if p.AbsRoot == p.ResolvedAbsRoot {
		return pGOPATH, perr
	}

condition fails because of case difference.

Drive letters should be also treated insensitive on Windows, as some tooling can mangle paths from different sources (for example, having naive scripts using the cygwin mounts /d/... converting to d:/...)

[ibrasho]

#940 should help in solving this one.

[matjam]

I ended up just doing this

// If pGOPATH equals rGOPATH, then both are within the same GOPATH.
	if pGOPATH == rGOPATH {
		if runtime.GOOS == "windows" {
			return pGOPATH, nil
		}

		return "", errors.Errorf("both %s and %s are in the same GOPATH %s", p.AbsRoot, p.ResolvedAbsRoot, pGOPATH)
	}

it's kind of awful ...