-
-
Notifications
You must be signed in to change notification settings - Fork 433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI --context not used when multiprocessing is enabled(for child processes) #1079
Comments
I only see a fix for this, coverage set's an environment variable and when |
@nedbat would you think adding the CLI parsed options as an env variable(json encoded?), which would then be used for when calling |
Or perhaps, why don't we use |
Hi, sorry I haven't responded yet. In general, the command-line options are not passed to the subprocesses. I'm wondering why --context should get special treatment? Is there a reason you have to specify context on the command line? Another option is to use an environment variable to set the context, and then use variable expansion in the configuration file to set the context. |
Describe the bug
When running coverage and passing
--context=foo
, only the main process uses thatfoo
static context.Any sub-processes, which do get coverage because we're setting
COVERAGE_PROCESS_START
, will not use thatfoo
context, instead, they report anempty
context.To Reproduce
How can we reproduce the problem? Please be specific. Don't just link to a failing CI job. Answer the questions below:
It's independent of the python version used.
coverage debug sys
is helpful.5.3
pip freeze
is helpful.A lot, and I don't think they're related to this issue, but I can add that to the issue if strictly necessary.
https://github.com/s0undt3ch/salt/tree/features/coverage-contexts
Expected behavior
I would expect that the context passed through
--context
, to be "inherited" but any subprocess which has coverage enabled.The text was updated successfully, but these errors were encountered: