puma and pumactl are seemingly unnecessary duplicatespumactl difficult without also being dependent upon puma.rbAll available options in the config file should also be made available to puma and pumactl under the same naming scheme.
pumactl should also be replaced by a wrapper around puma that adds the daemon management options on top of the existing feature set.
Ditching pumactl altogether in favor of puma combined with a kill tool like zap for managing stops and restarts.
https://github.com/puma/puma/issues/2242 https://github.com/puma/puma/issues/2243 https://github.com/puma/puma/issues/2244
They share similar options but under different names
This I definitely would be happy to look at individual cases and fix. I agree that the options should be as similar as possible.
pumactl should also be replaced by a wrapper around puma that adds the daemon management options on top of the existing feature set.
This I am not so sure. Pumactl has always been the "remote control" of Puma, and bin/puma has always been the "binary". I don't think they are unnecessary duplicates.
Don't recall anyone asking for it, but given that MRI Puma requires compiling and also nio4r, Puma::ControlCLI could even be released as a gem...
@nateberkopec should we close this issue? I think the individual cases you asked for can be new issues. It is not clear to me what needs to be done to close this issue (as stated, there is reasoning behind having two tools (puma and pumactl).
what needs to be done to close this issue
Someone can take a look at puma vs pumactl options and decide if any of them need to be changed so as to align with the other tool.
I'll mark as contrib-wanted.
Most helpful comment
Don't recall anyone asking for it, but given that MRI Puma requires compiling and also nio4r,
Puma::ControlCLIcould even be released as a gem...