直接调用与Python子流程时，GOPATH的解释不同

Question

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.

Answer 1

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.