-1

I recently found a fix for Python getpass not working on Windows: Python not working in the command line of git bash

Or at least that was the last thing I remember about changing my python configurations. (This is for Python 3.6.1 on Windows 10)

Now I also use Python to other tasks which simply has subprocess calls to type several commands on terminal:

go build ./folder/
mv ./src/ ./bin/

I get the error: go: GOPATH entry is relative; must be absolute: "/c/Users/OP/work". But I don't get it if I type go build ./src/folder myself. I have GOPATH set to C:\work in Environment Variables. I have tried with a ;.

Is there a way to reverse the alias python every time? Or what is happening exactly when setting an alias for python to winpty?

I'm thinking that when I call go build directly, it is called by either my user profile or system. And when python's subprocess calls it, it calls the opposite. Therefore, I have two GOPATH variables even though I have only 1 set in environment variable.

Side Note: another recent change on GOPATH was changing it from C:/go because it couldn't be the same as GOROOT. That error popped up randomly for some reason. It worked with that setting for a while and I don't remember changing anything before except adding another import package on top of the many other ones already being used.

Update: with type python I get the result: python is aliased to 'winpty python.exe'. Therefore I tried to undo that with unalias python. The new result I get is: python is hashed (/c/Users/OP/AppData/Local/Programs/Python/Python36/python).

This fixed the go build command within Python's subprocess. However, that alias was a fix for another Python issue with using getpass package.

Cit5
  • 400
  • 5
  • 19
  • What does `go env GOPATH` show from within your python process? `go build ./src/folder` looks odd too, what exactly are you doing? – JimB Nov 22 '17 at 19:18
  • `go: GOPATH entry is relative; must be absolute path: "/c/Users/CitizenCinco/work".` What is wrong with `./src/folder`? It is the source files folder that contain my code. I want to build it and move it to the binary folder. – Cit5 Nov 22 '17 at 19:24
  • I've never run this from windows, but `/c/Users/` might be a clue. Are you trying to run this from within cygwin or something? `go build ./src/folder` is odd because you packages are referenced by import path, not by a relative path; i.e. `go install my/package/name`, or without an argument where the `go` tool determines the name from the current directory. – JimB Nov 22 '17 at 19:30
  • yeah I am using Git Bash MINGW. I wanted to pass the path folder to `go build` because I would be able to call in from the parent directory where I manage all my other programs/tasks/etc. and still maintain Golang's suggested folder structure. Isn't being relative a bad thing here according to this error I'm getting? – Cit5 Nov 22 '17 at 19:52
  • 1
    It doesn't matter where you are relative to the source. If you're not in the package directory, call `go build` or `go install` (or `go get`) with the full package identifier. It's also possible that the `go` tool doesn't work correctly under MINGW, as that's not a target which is tested or supported. – JimB Nov 22 '17 at 19:56
  • yeah its strange. if I call it directly, it works fine. When I call `unalias python`, I can run my python task normally. So I guess I will just have to alias and unalias which defeats the purpose of creating the python task in the first place. I will have to investigate another solution for python's getpass import usage with Git Bash I guess. – Cit5 Nov 22 '17 at 20:04

2 Answers2

0

On top of my unalias python fix, I also discovered something interesting: when I change the environment variables for GOPATH from C:\work; to C:\go, all go commands still spit the error go: GOPATH entry is relative; must be absolute: "". I got this same error (but different path) from updating Windows 10 Fall Creators update. Maybe it is related.

Simply closing MINGW and reopening it fixed the issue. So perhaps it was saying a copy of my environment variables and using that as a reference instead of the actual system properties.

I know this is not a popular question, but someone could benefit from my hours of investigating and debugging.

Cit5
  • 400
  • 5
  • 19
-1

Under Windows you must use a Windows style GOPATH like eg d:\code and probably you should use cmd shell and nothing else. Unfortunately cygwin paths (and probably others too) do no longer work especially for go get reaching out to git.

Stick to Windows paths and Windows shell.

Volker
  • 40,468
  • 7
  • 81
  • 87