I'm sure this overlooks a number of edge cases, but hopefully this pull request can start a discussion on what else I need to consider in this patch.
Our problem was that we're specifying Puma config options in a config file. guard-pumaalways provides a command-line flags to the puma executable, which will in turn try to apply both sets of options. This would mean the app running on the default port of 4000 in addition to the one we've specified in config/puma.rb or an "Address already in use - bind(2) for "0.0.0.0" port XXXX" if we tried to specify the port as an option to guard-puma.
This change makes the assumption that if you're using a config file then you're responsible for setting all options within that file.
I'm sure this overlooks a number of edge cases, but hopefully this pull request can start a discussion on what else I need to consider in this patch.
Our problem was that we're specifying Puma config options in a config file.
guard-puma
always provides a command-line flags to thepuma
executable, which will in turn try to apply both sets of options. This would mean the app running on the default port of 4000 in addition to the one we've specified inconfig/puma.rb
or an "Address already in use - bind(2) for "0.0.0.0" port XXXX" if we tried to specify the port as an option toguard-puma
.This change makes the assumption that if you're using a config file then you're responsible for setting all options within that file.