So with the last post — after I found out (while writing the post) that with the changes to Passenger 3 standalone — it (understandably) doesn’t support a debugger option — I needed a backup, like say, thin.
So, I refactored rewrote my script
This one will now run your choice of server (where your choice is passenger, thin, or mongrel, but it could be extended to anything. Since passenger doesn’t support –debug/–debugger — it will use one of the others.
I pulled the “–daemonize” option — because that doesn’t make a whole lot of sense for a devserver environment — and I haven’t used it yet since I’ve switched away from my Cocoa-based launcher. If you want another terminal for tailing the development log (passenger will pipe the development log to stdout for you), or running memcached, just open one.
One thing I’ve wanted to do for a while is get away from using “getoptlong” and over to something else for command-line option parsing. There’s where trollop comes in. I like trollop (and love the built-in –help, which I never write with getoptlong) — the only thing I don’t like very much is that because its “opt” method takes a block as the third parameter — so I can’t do something like opt(:setting,’description’,:default => @config[:setting]) — because that @config gets passed as part of a block and gets evaluated inside trollop’s library when it’s creating dynamic methods for the options. This would be fine if I had a set of hardcoded defaults that I wanted to override, but I want to read those from a config file as well as get overrides from the command line. That’s the reason for all the local variable assignments for the defaults. I’m sure there’s a better way of handling that, I’m just not sure what.
Update: 2011/01/07 The script has become its own gem