Opened 12 years ago

Last modified 9 years ago

#3997 enhancement new

Replace getProcess* helpers with a single, better, API.

Reported by: spiv Owned by:
Priority: normal Milestone:
Component: core Keywords:
Cc: khorn, Tom Prince Branch:


I think the subprocess module has the right idea: give you a single good way to start a function, and declare whether you want to capture/discard/ignore the various stdio streams etc, and then return an object with useful attributes.

So I propose that instead of getProcessValue, getProcessOutput, getProcessOutputAndValue (did I miss any?) we have a single method, that takes args like:

  foo(stdout=fileLikeObject, ...)

and returns a Deferred that yields an object with a .exitValue attribute, and perhaps others (for finding out if a signal terminated it, maybe?). Returning an object certainly seems like a much better API than e.g. the tuples from getProcessOutputAndValue. Obviously this new function would need a better name than foo.

Probably any new API here should try to address the problems with the existing APIs described by exarkun in a comment at

Quite possibly the proposal in this vague sketch could be improved even further. Please feel free to criticise, suggest improvements, suggest more precise details for the signature, etc. I figured it was better to capture a rough idea than forget it entirely.

Change History (7)

comment:1 Changed 12 years ago by Screwtape

A single, perfect, simple and powerful API that did everything with processes would be nice, but a difficult goal to attain.

A shorter-term stepping-stone might be to supply a few IProcessProtocol implementations that can be used with .spawnProcess() to handle common scenarios, including:

  • adapting an ordinary Protocol to talk to a subprocess (hooked up to stdin/stdout, stderr and exit codes ignored)
  • taking a string and writing it to the child's stdin; provides a Deferred that will be callback'd with the process's output if it exited cleanly, and errback'd if the process is killed by a signal.

I guess browsing the docs of the subprocess stdlib module and various uses of .spawnProcess in the Twisted codebase (and any other Twisted-based code you have handy) would be a good way of finding use-cases.

comment:2 in reply to:  1 Changed 12 years ago by Glyph

Replying to Screwtape:

  • adapting an ordinary Protocol to talk to a subprocess (hooked up to stdin/stdout, stderr and exit codes ignored)

I want to do this all the time. connectProcess, maybe? Let's make that a separate ticket. (I am sympathetic to the goals of this ticket, but it is only distantly related; getProcess* are more about simple scripts that do one thing with a subprocess that fires a Deferred; connectProcess is more about an explicit mapping between IProcessProtocol and IProtocol (which should look much more different than they currently do).

comment:3 Changed 12 years ago by khorn

Cc: khorn added

comment:4 Changed 11 years ago by Glyph

OK, connectProcess would be a silly idea; it should be a process endpoint. This particular ticket may be too broad to be resolved usefully though, I'm thinking of closing it as invalid and just opening a new one for IProtocolIProcessProtocol adapter.

comment:5 Changed 11 years ago by Jean-Paul Calderone

It would probably be a good idea to look at all of the "spawnProcess sucks" tickets and figure out a plan that addresses more than just one of them.

comment:6 Changed 11 years ago by <automation>

Owner: Glyph deleted

comment:7 Changed 9 years ago by Tom Prince

Cc: Tom Prince added
Note: See TracTickets for help on using tickets.