[PATCH STABLE] build: include a dummy $PATH in the custom environment used by build.py

[Jun Wu]

Excerpts from Pierre-Yves David's message of 2016-10-29 02:18:56 +0200:
> My question is more "What is the meaning and effect of adding "." here? 
> I'm fine with trying to fix pypiwin32 but we have to be aware of the 
> actual consequence. A related quest is "What is happening is 'PATH' is 
> already in the envirement? are we overwriting it?

For Windows, PATH='.' is equivalent to PATH='' since Windows searches for
PWD by design.

For *nix, PATH='' is better. PATH='.' has undesired side-effects.

I checked the code, if PATH is already set, it will be dropped by our code
because we created a new "env" dict and pass it to "runhg" -> "runcmd" ->
"subprocess.Popen(..., env=env)" so the new process does not inherit the old
PATH.

We rely on "sys.executable" to be correct to find the correct Python.

I think having an empty value, or inherit it from os.environ are both
acceptable solutions. But it's pypiwin32 to blame anyway.

> > The problem is that pypiwin32 does os.environ['PATH'] += ... in a .pth file (loaded by site.py),
> > which fails if 'PATH' is not in os.environ.
> 
> /me shake fist at .pth…
> 
> Can you point us at the full line to help us to find an appropriate 
> solution ?
> 
> > The original pywin32 doesn't have this issue, but it can only be obtained by downloading
> > a Windows .exe installer from SourceForge, a site known to have previously injected
> > malware into .exe installers it hosts.
> 
> This seems sad? Are you sure there is no other download link? Maybe you 
> could ping the developer.
> 
> Cheers
>