[Python-Dev] Issue 13524: subprocess on Windows

[Nick Coghlan]

On Sun, Dec 4, 2011 at 8:59 PM, Tim Golden <mail at timgolden.me.uk> wrote:
> So... what's our take on this? As I see it we could:
>
> 1) Do nothing: it's the caller's responsibility to understand the
>   complications of the chosen Operating System.
>
> 2) Add a doc warning (ironically, considering the recent to-and-fro
>   on doc warnings in this very module).
>
> 3) Add a check into the subprocess.Popen code which would raise some
>   exception if the environment block is empty (or doesn't contain
>   SystemRoot) on the grounds that this probably wasn't what the user
>   thought they were doing.
>
> 4) Automatically add an entry for SystemRoot to the env block if it's
>   not present already.
>
>
> It's tempting to opt for (1) and if we were exposing an API called
> CreateProcess which mimicked the underlying Windows API I would be
> inclined to go that way. But we're abstracting a little bit away
> from that and I think that that layer of abstraction carries its
> own responsibilities.
>
> Option (3) seems to give the best balance. It *is* a cornercase, but at
> the same time it's easy to misunderstand that the env block you're
> passing in *replaces* rather than *augments* that of the current
> process.

There's actually two questions to be answered:
1. What should we do in 3.2 and 2.7?
2. Should we do anything more in 3.3?

Raising an exception is not really an appropriate response for any of
them - running without SystemRoot actually works fine in most cases,
so raising an exception could break currently working code. As the
blog post noted, it's only some specific modules that don't work if
SystemRoot is not set. Should we really be inserting workarounds in
subprocess for buggy platform code that doesn't fall back to a
sensible default if a particular environment variable isn't set?

So, I don't think this is really a subprocess problem at all. It's a
platform bug on Windows that means the 'random' module may fail if
SystemRoot is not set in the environment. So, I think the right
approach is to:

1. Unset 'SystemRoot' in a windows shell
2. Run the test suite and observe the scale of the breakage
3. Then either:
- figure out a workaround that allows us to set an appropriate default
value for SystemRoot if needed (depending on the scope of the problem,
either do this at interpreter startup, or only in affected modules)
- if no feasible workaround is found, detect the failures related to
this problem and report a more meaningful error message

Either way, add explicit tests to the test suite to ensure that
affected modules behave as expected when SystemRoot is not set.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia