> I think you may be underestimating how common the tool/"black box" use case may be.

I'm sure I am.  It's easy for me to consider things from the perspective of an advanced ruby-only user, but much harder for me to consider things from the perspective of someone not loading this into an existing project.

Here's an idea for a "best of both worlds" solution:

* Limit this gem's declared dependencies to just those that are _always_ needed.
* Provide a second gem (something like `qless-sharded-ui-runner`) that has a dependency on this plus the executable (and any dependencies that needs).

Those that want to roll this into their own app (as I do) can use the former; those that want to run it stand-alone can do the latter.

All that said: I realize that increases the effort to maintain this, and I don't actually thing it would provide enough ROI to put the effort into doing the split now.  I'm just bringing this up as something to consider if/when the needs of the "integrate in an existing ruby project" case vs the "run stand-alone" case continue to diverge.

> Why should they need to roll a Sinatra app just to use the admin ui? qless-web doesn't require that.

I don't think they should have to roll a sinatra app.  Removing the explicitly declared dependencies doesn't stop someone from using them...they'd just have to be instructed to install the manually to get that added behavior.  Then again, maybe I'm coming too much from the perspective of someone who is super comfortable installing and managing lots of gems, and for the sorts of user the stand-alone case is targeted at, that may add confusion and pain.

Regardless, I'm satisfied with how things are now, so I'll merge away.