gips uses two or three ways to call subprocesses, and the handling isn't consistent. Write a subprocess handler that does things in a unifed way almost like we have for error handling. Stuff we could do in the handler for consistency:
Choose a single standard library or third-party thing that does what we want, and use it everywhere.
Raise an exception with a predictible type and content on nonzero exit status, or even optionally wrap in a with error_handler if the caller wishes.
Consistent printing of the subprocess's invocation line on -v4 or -v5.
Options to handle the process's stdout and stderr in different ways (pipe to /dev/null, save to a file, show to the user).
Options to buffer and unbuffer the process's streams (I think this is helpful when monitoring a long-running process that's mostly logging to a file, which is buffered by default).
For the initial implementation, these basic features should be sufficient, plus a few conversions of existing code like we did for error handling. Then future iterations can convert all the subprocesses in gips, and improve the implementation as we see fit.
Regarding which lib to use, commands has a deprecation warning, and a claim about subprocess having better features; subprocess says you should use the backported version from python3:
gips uses two or three ways to call subprocesses, and the handling isn't consistent. Write a subprocess handler that does things in a unifed way almost like we have for error handling. Stuff we could do in the handler for consistency:
with error_handler
if the caller wishes.-v4
or-v5
./dev/null
, save to a file, show to the user).For the initial implementation, these basic features should be sufficient, plus a few conversions of existing code like we did for error handling. Then future iterations can convert all the subprocesses in gips, and improve the implementation as we see fit.