[update-checkout] Don't use env for portability.

[drodriguez]

env is not portable in systems that do not have env like, for example, Windows. However, passing the environment is supported by shell.run using the env parameter, which should be portable.

[jrose-apple]

It looks like this will replace the environment rather than adding to it, which is not what we want.

[drodriguez]

Funny thing. shell.call() and shell.capture() merge the environments, but shell.run() doesn’t. I was expecting all to do the same.

[jrose-apple]

Hm, maybe that's a bug in shell.run, then. You'd have to talk to @Rostepher about what he wants to do with that, probably.

[drodriguez]

Well, for the time being, instead of modifying shell.run() (even if it looks only being used from update_checkout.py), I modifying the function that invokes shell.run() with an environment to merge the current with the new value.

I can fix shell.run() if people prefer that.

[Rostepher]

Ultimately I'd planned to re-write the shell module in build_swift and have it mimic the subprocess module more closely. I think it's a lot more transparent if the caller needs to make a copy of the system environment and extend it at the call site than rely on the shell.call function to do that.

[drodriguez]

I have to say that it feels natural that the environment gets merged, since that's what happen in the shell itself, but it is true that that approach do not allow removing pieces from the environment, or starting with a clean environement, so I understand the decision. Good thing I decided to not modify run.

[drodriguez]

@moiseev: I will like to have this available for the future Windows CI. For the time being I’m cloning manually, but it would be great to use the official checkout script. Would you mind having a look at this? (hopefully you are not on vacation). Thanks! (If anyone else have any more feedback, that's also welcomed).

[moiseev]

@swift-ci Please smoke test