Open Bug 819547 Opened 10 years ago Updated 4 years ago
[mozprocess] rework mozprocess API
Motivation: * several folks have been confused by the mozprocess API as it stands * there's no reason that the mozprocess API can't be like the subprocess.Popen API: we're certainly able to add new methods if we want additional functionality * While it should be possible to do all of the "hard things" that mozprocess currently does, it should be easy to do the easy things What we should do about it: - document what we have and what we do -- list public API we provide; is there anything that's not going to work? -- compare to Popen -- hopefully this can be a guide to how to redesign - ProcessHandlerMixin should inherit from subprocess.Popen -- no reason for Process inner class: -https://github.com/mozilla/mozbase/blob/master/mozprocess/mozprocess/processhandler.py#L33 -- continue to expose Popen functionality, but the ability to -customize so that we don't lose any functionality - a single method to get stdout, stderr, returncode; wrap communicate - fix mozrunner to use new mozprocess API: should handle most of the stuff outside of mozilla-central -- http://mxr.mozilla.org/mozilla-central/search?string=mozprocess (and most of that is internal to mozbase)
Wish list item: ability to attempt Unicode conversion. I /think/ some platforms (like Windows) expose the encoding of a given stream. It would be swell if mozprocess could optionally use this "hint" to convert bytes to Unicode. Such an API would need to be designed with care - listed encodings are often wrong and we would want mozprocess to handle UnicodeDecodeError gracefully (possibly following what the caller requested). I'd also love one-line helper functions like subprocess.check_output and subprocess.check_call.
(In reply to Gregory Szorc [:gps] from comment #1) <snip/> > I'd also love one-line helper functions like subprocess.check_output and > subprocess.check_call. As would I. I'd also like this to be a bit better than existing subprocess.check_output/call as I always end up writing front-ends to these. As a "necessary but not sufficient" requirement, I would like to (at least in some use-cases) return stdout, stderr, returncode vs just the return code. I would also like a e.g. silent mode that runs the command without outputting stdout/stderr *UNLESS* there is a non-zero return code in which case these are output along with the return code and subprocess.CalledProcessError is raised. (These could actually be two different functions.)
Summary: rework mozprocess API → [mozprocess] rework mozprocess API
You need to log in before you can comment on or make changes to this bug.