-
-
Notifications
You must be signed in to change notification settings - Fork 437
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
Twisted concurrency model #816
base: master
Are you sure you want to change the base?
Conversation
for opt_name in ['branch', 'include', 'omit', 'pylib', 'source', 'timid']: | ||
# As it happens, all of these options have no default, meaning | ||
# they will be None if they have not been specified. | ||
if getattr(options, opt_name) is not None: | ||
show_help( | ||
"Options affecting multiprocessing must only be specified " | ||
"in a configuration file.\n" | ||
"Options affecting multiprocessing and twisted must " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Will probably not be very useful reviewing much of this, but it'd be a bit nicer UX-wise if rather than saying "A or B" here you used .format
and inserted in options.concurrency
, i.e. the actual one of the two of those that the user really did use, instead of including ones they didn't)
0c14f1a
to
82169a6
Compare
Is this still valid? |
Adds
--concurrency=twisted
which causes coverage to be tracked across child processes created with Twisted'sreactor.spawnProcess
.I'm not entirely happy with the sitecustomize management code. Also it seems like this could probably easily be a
--concurrency=exec
feature instead, with a the sitecustomize being written and PYTHONPATH updated early. Then all processes forked & exec'd will get the logic. It's less clear when to do cleanup but it's probably still possible.Also this approach comes with the downside that it obscures any existing sitecustomize. I don't really know what people use sitecustomize for so I'm not sure how big of a deal this is.
Any other solution for fork&exec seems like a challenge because there is no general way to inject some code into a process you've just exec'd. exec is inherently about giving up control of what's running to some other program. There might be some platform-specific tricks but that doesn't seem like an appealing avenue.
While working on this, https://pypi.org/project/coverage_enable_subprocess/ was also pointed out to me and it seems to accomplish roughly the same thing. It uses the pth file approach instead but this means it requires a virtualenv (or for you to splat junk into your probably-OS-managed Python install which is not a great idea). It also collects coverage from all Python programs instead of all programs in a tree under the one you start but I don't know if that's much of a practical difference.