Since fetches involve multiple subprocess calls, any of which can be
slow, the per-subprocess caffeination strategy does not seem suitable --
the Mac might sleep as soon as the wake lock is dropped, before it
starts a new one. This instead implements a context manager to allow
caffeinating a scope.
To allow flag control, caffeinate.scope takes an argument that decides
whether or not it should actually do anything useful; it looks silly,
but the alternative is to interfere with flag parsing more or to require
users to write separate codepaths to decide whether to enter the context
manager scope or not; the "use the context manager in a mode where it
does not do anything" prevents this.
Bug: 462507017
Change-Id: Icc5bb9cadda30b5a120f112b10bf96ffd3b6550f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/7183647
Reviewed-by: Gavin Mak <gavinmak@google.com>
Commit-Queue: Adam Norberg <norberg@google.com>
I'm looking at caffeinating more long-running depot_tools commands on
Mac, which use a variety of `subprocess` APIs; one implementation
strategy I'm considering is to wrap more of them, including
`subprocess.run`, but the most obvious name to wrap `subprocess.run`
into is already taken! I think it makes the most sense to name the
`caffeinate` function(s) after the `subprocess` call it wraps.
The callers to other parts of `subprocess` use more of the features
exposed by those APIs. For consistency, I am plumbing through more of
`subprocess.call`'s identifiable behaviors here, too:
* command-to-invoke parameter is named "args"
* as explicitly checked in cpython's subprocess.py's `_posix_spawn`:
77cb39e0c7/Lib/subprocess.py (L1816)
also allow `str`, `bytes`, and `os.PathLike` for the type of `args`,
converting the non-list-like types into a single-element list
* use kwargs packing and unpacking to forward other parameters into
`subprocess.call`
kwargs packing does not provide perfect emulation as implemented:
77cb39e0c7/Lib/subprocess.py (L386)
`timeout` could be provided as a positional parameter. However, Python
documents all subprocess.call parameters as keyword only:
https://docs.python.org/3.12/library/subprocess.html#older-high-level-api
...specifically because they don't want to bother distinguishing
between parameters "local" to a higher-level `subprocess` helper and
those that get forwarded (via `**kwargs`) to the underlying `Popen`,
so I think it is reasonable to follow their lead on that.
Bug: 462507017
Change-Id: Ia520ced7f8188c23c38826d22ccf20a3c52ddfc5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/7181621
Reviewed-by: Junji Watanabe <jwata@google.com>
Commit-Queue: Adam Norberg <norberg@google.com>
