Rackup gem for rack handlers

[ioquatix]

I would like to propose we move rackup, Rack::Server and the Rack::Handler::* to a separate gem.

• Rack should focus on the interface.
• Webrick is no longer a standard part of Ruby.
• It doesn't make sense that servers that depend on Rack the interface also get rackup the executable.
• We can improve rackup at a different release cadance from rack.
• rackup tests have been flaky.
• We should probably test a wider number of servers for compatibility.
• The interface for Rackup handlers is poorly specified and causing problems (e.g. sinatra trying to stop a handler).

We should leave handler registration in Rack, at least for the short term - and define a better interface (at least a standard for #stop) for servers to follow.

[jeremyevans]

I would like to propose we move rackup, Rack::Server and the Rack::Handler::* to a separate gem.

I think rackup is too commonly used, and removing it would break things. More people use rackup than you probably expect.

• Rack should focus on the interface.

While that is a focus, it isn't the sole focus. Otherwise, Rack would only ship Lint/SPEC. If we want to have a gem just focused on the interface, we should spin out rack-lint as a separate gem, and make rack depend on it (not in favor of that approach, though).

• Webrick is no longer a standard part of Ruby.

rackup supports more than webrick, though I think webrick is what the specs test as rackup ships the webrick handler, and other servers have their own handlers.

• It doesn't make sense that servers that depend on Rack the interface also get rackup the executable.

Servers that depend on Rack the interface don't need to require the rack gem at all. The beauty of the rack interface is that it just uses common ruby objects, instead of rack-specific objects.

• We can improve rackup at a different release cadance from rack.

While theoretically possible, the more likely scenario is rackup being sent out to pasture to die. How much has rack-session improved since being removed?

• rackup tests have been flaky.

The tests will likely be just as flaky if rackup is moved to a separate gem, it just makes the problem less visible.

• We should probably test a wider number of servers for compatibility.

The issue there is that other than webrick, the servers maintain their own handler. However, I'm not opposed to testing additional servers in CI.

• The interface for Rackup handlers is poorly specified and causing problems (e.g. sinatra trying to stop a handler).

This is something that would could specify.

We should leave handler registration in Rack, at least for the short term - and define a better interface (at least a standard for #stop) for servers to follow.

If handler registration is left in rack, it really doesn't make sense to move rackup out, IMO.

[ioquatix]

rackup supports more than webrick, though I think webrick is what the specs test as rackup ships the webrick handler, and other servers have their own handlers.

There are only two handlers - webrick and cgi (probably not practically useful).

Webrick is no longer a default gem. Should rack depend on webrick?

Servers that depend on Rack the interface don't need to require the rack gem at all. The beauty of the rack interface is that it just uses common ruby objects, instead of rack-specific objects.

Sure, but most major servers work that way, and probably 99% of all production traffic will pull in Rack.

If handler registration is left in rack, it really doesn't make sense to move rackup out, IMO.

I'd be fine with also removing server registration, but it would be incompatible with existing servers, so better to phase it out in steps - probably better just to use const_get(server_name) and/or autoload than the funky registration system we have.

[tenderlove]

Webrick is no longer a default gem. Should rack depend on webrick?

This worries me too. I don't really want to make Rack depend on the webrick gem, but since it's not in stdlib anymore I guess our dependencies are technically incorrect.

Should we ship with no handlers? If not, is it still ok to have bin/rackup?

I really like that folks who just want to mess around with writing a super basic webapp can install rack, define a very simple app in an ru file, then run rackup and see their app in action. The fact that we can't rely on Ruby to provide a webserver by default makes me question rackups value shipping with Rack though. I don't see any options besides adding webrick as a dependency or telling people they need to install an additional gem (the webrick gem or maybe webrick-rackup??). I don't have any problems adding webrick as a dependency for a rackup gem, but I do have a problem adding it as a dependency for the rack gem.

[jeremyevans]

Webrick is no longer a default gem. Should rack depend on webrick?

This worries me too. I don't really want to make Rack depend on the webrick gem, but since it's not in stdlib anymore I guess our dependencies are technically incorrect.

I don't think the dependencies are incorrect. rackup will use whatever is available. If puma is available, it is prefered, and rackup doesn't depend on puma. All that has changed since webrick is removed is that there may not be a default webserver available. We may want to change the error message that rackup uses if no handler is available to recommend the user install puma, falcon, or webrick (it currently just says Couldn't find handler for: puma, falcon, webrick).

Should we ship with no handlers? If not, is it still ok to have bin/rackup?

I really like that folks who just want to mess around with writing a super basic webapp can install rack, define a very simple app in an ru file, then run rackup and see their app in action. The fact that we can't rely on Ruby to provide a webserver by default makes me question rackups value shipping with Rack though. I don't see any options besides adding webrick as a dependency or telling people they need to install an additional gem (the webrick gem or maybe webrick-rackup??). I don't have any problems adding webrick as a dependency for a rackup gem, but I do have a problem adding it as a dependency for the rack gem.

I agree we shouldn't add a webserver as a dependency for rack. I'm not in favor of moving rackup out of rack, but if we do that, I don't think we should add webrick as a dependency in that case either. Rackup should be similar to ActiveRecord/Sequel, in that it works with a lot of different adapters/handlers, but it doesn't depend on any specific adapter/handler.

If we absolutely had to add a dependency, I recommend we depend on puma and not webrick. While webrick is pure ruby and puma is not, I think puma would make a better default.

[ioquatix]

Moving rackup out of rack would enable us to add a default like Puma which frankly makes a lot of sense to me. I'm not saying we should add puma, just that the logic is sound.

Regarding webrick, since we provide a handler for it, we in theory should include it. Alternatively we can try to get the Rack::Handler::Webrick merged upstream into webrick. Not sure if any of these options make sense, but it's how every other server works basically.

[simi]

Adding puma as dependency (or any other server) doesn't make sense to me as well. Moving rackup out of rack is good choice. Alternatively (since there is no guarantee any server is installed), maybe we can even deprecate rackup and recommend to use server (puma) directly (since puma executable can recognize config.ru as well by default).

For webrick it makes sense to merge handler upstream and potentially also contribute simple executable webrick to recognize config.ru and load it by default.