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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Nov 1 11:56:29 EDT 2016



On 11/01/2016 04:39 PM, Jun Wu wrote:
> 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.

It seem slike we should at least inherit a value if one exists. This 
patch does not seems ready for inclusion. I'm dropping it from patchwork 
and we'll revisit post release.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list