Closed mjc closed 8 years ago
Looks like I forgot to add tests, and I also need to dig around in puma internals some to figure out why sending two restarts close together results in it stepping all over itself.
Cool, yeah add tests and once they pass I'll take a look. I took a stab at controlling puma
via pumactl
a while back but never got it to work. Thanks for putting some effort towards it!
@mjc any movement on the tests?
Closing this for now, please reopen with passing tests and I'll be happy to merge.
This is a rewrite of
Guard::PumaRunner
utilizing (mostly) the same code that pumactl uses to manage puma directly, instead of usingNet::HTTP
.One immediate benefit of this is the ability to control
puma
with signals or unix sockets if available.Currently the code is a bit ugly. It could be much more elegant if
Puma::ControlCLI
were a little less smelly (for example, run should return meaningful values and take a command instead of using@options[:command]
.) I intend to submit patches to Puma to reduce said smell.The options are now using the same options that puma uses internally, while still respecting
:host
and:port
. Additinally one can specify additional arguments to thepuma
command viapuma_args
in either string or array form.Array form looks something like this:
:puma_args => ["- t","16:32","--help","config.ru"]
where each of the arguments that would be separated by spaces are separate items in the array.The use of puma_args is discouraged, though, as
puma_arg_list
should correctly build the command line arguments for every option that puma can currently use.For the full list of options, peruse
@options
in lib/puma/cli.rb1.pumactl
normally spawnspuma
inside itself when you issue start, if it's not currently running. While this is possible inside guard, I'm unsure how to do it gracefully, so I've overridden the start mechanism.There may be some other improvements/additions that I neglected to mention.
Sponsored-by: CentroNet Marketing http://www.centronetmarketing.com