On 10 January 2018 at 18:30, Paul Moore <[email protected]> wrote: > On 10 January 2018 at 02:39, Nick Coghlan <[email protected]> wrote: >> For the coverage.py use case, an environment-based solution is also >> genuinely helpful, since you typically can't modify subprocess >> invocations just because the software is being tested. At the moment, >> there are approaches that rely on using either `sitecustomize` or >> `*.pth` files, but being able to write `PYTHONRUNFIRST="import >> coverage; coverage.process_startup()"` would be a fair bit clearer >> about what was actually going on. > > It's worth remembering that Windows doesn't have the equivalent of the > Unix "VAR=xxx prog arg arg" syntax for one-time setting of an > environment variable, so environment variable based solutions are > strictly less useful than command line arguments. That's one reason I > prefer -C over PYTHONRUNFIRST.
The proposal is to offer both, not an either/or, but the idea isn't that folks would need to set the environment variable directly - it's that coverage.py itself (or a test runner) would set it so that subprocesses were captured in addition to the directly executed module. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
