[Twisted-Python] untwisting twistd

Alex Clemesha clemesha at gmail.com
Mon Jun 22 15:36:03 MDT 2009


Hi Jared,
First off, I'd like to say that I'm basically in agreement with exactly what
you are saying, and that is: "I should be able to write a Python
script that acts like twistd - not *be* twistd".


Phil does have some really good points, such as:
"""
The critics are usually not thinking about the real requirements of deploying a
configurable demonizing application in a production environment.
"""


And lastly, I'm glad to see that response from Glyph, as the methodology
he describes is basically how I understand one would create a
"personalized twistd".


In fact, I just got an email from a co-worker that wanted to know how to
either side-step "twistd" or write a custom version of it.  Here is my
response to him (I'd love some critic of my response, so I can provide
a better answer):


============= Email to co-worker: ===============


Yes, there is a better way of doing things.  This better way of doing things
is to write a "twisted plugin" and then, after that is working, using can
wrap calls to "twistd" with python's "os.system" calls, or shell script calls,
or whatever else you want.


I must admit, this whole procedure is pretty confusing (it was for me
at least) at first,
but let me try to explain why you might want to write a "twisted plugin" and
_then_ (possibly) wrap it with a shell script or a simple python script.
The main reasons are the following:

1) You _do_ want to use "twistd", because it does lots of useful
things like daemonizing, handling logfiles and pidfiles, etc.
2) You also want to pass config code to the app you are starting up
(via "twistd") - optimally from the command line and a settings file.

Now, once the above is in place, you then can write some wrapper code
on top of the "twistd" calls for convenience for users.

Here is the "plugin" documentation:
http://twistedmatrix.com/projects/core/documentation/howto/plugin.html

But I've found that it is easier to go from an example, so try typing this:

twistd -n web --path="."

Now open up firefox to http://localhost:8080
This starts up a twisted web server, serving files from the local directory.
This is a twisted web plugin in action, and it is implemented with
these 2 files:

http://twistedmatrix.com/trac/browser/trunk/twisted/plugins/twisted_web.py
http://twistedmatrix.com/trac/browser/trunk/twisted/web/tap.py

============ end email to co-worker ==============



So basically I've found that the best thing to do is to extend
"twistd" via writing a plugin, and then you can write all kinds
of simple wrappers on top of it to provide a more user-friendly
and a your-app-specific command line tool.  Thoughts from Twisted gurus?


thanks,
Alex












On Mon, Jun 22, 2009 at 1:30 PM, Jared Gisin<jared.gisin at isilon.com> wrote:
> I am currently working on writing an application using the twisted
> framework. The problem that I have is that I do not want to use twistd. In
> fact, I find twistd to be inappropriate as it defaults pidfile and logfile
> to something specific to twisted, not my application, and it seem completely
> silly to have to pass in –pidfile and –logfile params when stating it up.
> Those parameters should be specified as part of the Application object
> itself, and should allow for CLI override. Further, as I want my daemon that
> I’m writing to look and act like a daemon (UNIX), I do not want to be
> invoking some general “twistd” command and passing a ton of options.
> Ideally, I should be able to write a Pythons script that acts like twistd,
> but can bake in default options and hide/expose other ServerOptions as I so
> see fit.
>
>
>
> For example, if I run,
>
>
>
> my_daemon
>
>
>
> It should fire up the daemon
>
>
>
> my_daemon –help
>
>
>
> should dump the help
>
>
>
> my_daemon –pidfile=/var/run/my_daemon.pid
>
> my_daemon stop
>
> my_daemon restart
>
>
>
> should all function accordingly. I want to avoid all of this “twistd –y”
> business, as the daemon, isn’t “twistd” it’s my code. I should be able to
> use the ApplicationRunner, UnixApplicationRunner, etc “runners”,  however,
> as they are currently written, they are twistd specific. For example, in
> 8.2, the def checkPid function bakes in, “            sys.exit("""\
>
> Another twistd server is running, PID %s\n
>
> This could either be a previously started instance of your application or a
>
> different application entirely. To start a new one, either run it in some
> other
>
> directory, or use the --pidfile and --logfile parameters to avoid clashes.
>
> """ %  pid)”
>
>
>
> Which is iditic as my application may not even expose a –pidfile or a
> –logfile and it’s definatley not called twistd. The platform specific
> application runners need to be more generalized so users can write their own
> twistd equivalent to include only what they want.
>
>
>
> Perhaps I’m missing some key point of twisted that already does this. If so,
> I’d love to be guided in the right direction. If not, and I’ve got a valid
> point here, I’d love to know how I can help to remedy this problem. I think
> it’s great that twistd provides application management classes, but they are
> unnecessarily intertwined with twistd which should be completely optional.
>
>
>
> -Jared
>
>
>
>
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>



-- 
Alex Clemesha
clemesha.org




More information about the Twisted-Python mailing list