Opened 5 years ago

Last modified 20 months 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:
Author: Launchpad Bug:

Description

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 http://twistedmatrix.com/trac/ticket/280.

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 follow-up: Changed 5 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 5 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 5 years ago by khorn

  • Cc khorn added

comment:4 Changed 4 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 4 years ago by exarkun

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 4 years ago by <automation>

  • Owner glyph deleted

comment:7 Changed 20 months ago by tom.prince

  • Cc tom.prince@… added
Note: See TracTickets for help on using tickets.