PATCH: Improved rackup's ability to handle handler-specific options
Reported by Graham Batty | March 26th, 2009 @ 08:00 AM | in 1.x
Kind of related to my previous patch, I'm proposing the attached change as a means to allow rackup (and framework handlers like rails' script/server) to take handler-specific command line arguments.
This requires a little bit of zaniness in the optparse part of rackup, but this could be removed with a couple of changes to existing convention (in further patches, if necessary).
Namely, if it was required that a handler-name were specified as the first command line argument without a -opt (ie. rackup Mongrel rather than rackup -s Mongrel), and if it were not then subject to the ruby options (like -r -I etc), it could be a lot simpler. I question whether, with the acceptance of my other patch, this would be a problem anymore since it seems like the main use of those args was to -r in a gem for a handler.
Patch attached and also available on my github branch at: http://github.com/stormbrew/rack...
Comments and changes to this ticket
-
Graham Batty March 26th, 2009 @ 08:18 AM
To clarify a bit, this makes it so that as an example, mongrel takes 3 options that previously couldn't be specified. If you use -s Mongrel, you can now also do the following: "rackup -s Mongrel -R 50" to limit the max number of processors before mongrel starts rejecting requests to 50.
This will also be useful for things like swiftiply, which can take extra configuration arguments to authenticate the server against the swiftiply daemon.
-
Ryan Tomayko March 26th, 2009 @ 11:07 AM
Interesting concept, Graham. I wonder if it wouldn't be simpler to add some kind generic "handler option" argument. e.g.,
rackup -s mongrel -o processors=50 -o throttle=0 -o timeout=60 config.ruThe idea would be that you wouldn't actually confirm that the handler supported the options - you'd just throw whatever was provided into the options hash.
-
Graham Batty March 26th, 2009 @ 05:24 PM
That would also work, though one advantage of how I've done it is it shows up nicely in the --help.
But it wouldn't be too hard to make it so there's still an interface to pull a list from the handler to show in --help.
It would certainly avoid the need to do hacky things with optparse, and would make it so handlers and other runners using this convention wouldn't have to rely on optparse.
I'll code up an alternative that does it that way later today.
-
josh August 3rd, 2009 @ 04:12 PM
- Milestone set to “1.1”
-
josh August 3rd, 2009 @ 04:20 PM
- Assigned user set to “Ryan Tomayko”
-
josh December 11th, 2009 @ 03:11 AM
- Milestone changed from “1.1” to “1.x”
-
josh December 11th, 2009 @ 03:11 AM
- State changed from “new” to “open”
-
raggi October 3rd, 2010 @ 07:10 PM
- Milestone order changed from “0” to “0”
This patch needs updating against the 1.2+ series (with Rack::Server), also we have specs for Rack::Server now i think?
-
Graham Batty December 2nd, 2010 @ 03:32 AM
Oops, kinda left this one on the backburner for a long time. Updated patch to use -O/--option while still allowing the handler to provide a list of options for display. This time I made it so the handler includes Host and Port in its option list, but Rack::Server ignores them (the idea being that another client may choose to be more generic).
Patches attached, also available at http://www.github.com/stormbrew/rack/tree/handler-options-2 (which also includes another fix to the fastcgi handler that I'm submitting as a separate issue)
There is a single spec for Rack::Server, to test whether Server will avoid doing ARGV parsing if an option map is passed in. Given Server's dependence on run-time state (ARGV in particular), properly specing it (including these changes) would require a fairly substantial refactoring (or questionable practice like temporarily overriding ARGV for the duration of the spec). I think that's probably a whole project unto itself.
-
Graham Batty December 2nd, 2010 @ 03:34 AM
Um, I can't seem to attach a patch to this issue at the moment. So the specific commit is at:
https://github.com/stormbrew/rack/commit/e6a07b69698d7fd23f221c92e5... -
Graham Batty December 2nd, 2010 @ 03:47 AM
- no changes were found...
-
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Graham Batty
josh
raggi
Ryan Tomayko