On 10 January 2018 at 18:30, Paul Moore <p.f.mo...@gmail.com> wrote: > On 10 January 2018 at 02:39, Nick Coghlan <ncogh...@gmail.com> 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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
