Re: Bootstrapping rackup with multiple rack gems installed

[James Tucker <jftucker@gmail.com>]

On 1 Sep 2010, at 16:14, Joshua Peek wrote:

> This came up as an issue in Rails 2.3 along with the release of Rack
> 1.2. Rails 2.3 is locked to Rack 1.0 so if Rack 1.2 is activated
> before hand, Rails will fail to boot. Most people now have Rack 1.0
> and 1.2 both installed. In a prefect rubygems world everything would
> work fine. (This is why I don't use RG, but a ton of people are still
> using Rails 2.3 and RG)

It's not RubyGems fault if people don't use dependency manifests and/or call Kernel#gem. RubyGems activates dependencies in order to avoid cross-dependency failures at runtime - this "error" is protecting against potentially far far more horrible bugs. Dependency management is not a "perfect world". If you have a serious suggestion about how this could possibly be solved in RubyGems without removing features or failing critical use cases, please pass your thoughts on as if you can genuinely solve it, I'll get it committed to RubyGems immediately.

> Starting Rails with `script/server` works fine because Rails boots
> first. You can start Rails with `rackup` but you have to make sure you
> are using the matching rack version with `rackup _1.0.1_` which is
> kind of lame though. The major issue is with servers like unicorn and
> passenger which have their own bootstrapping scripts.

If they support multiple versions of rack, then they need to load the version they want as configured by the user.

> If you boot a Rails 2.3 app with `unicorn` and Rack 1.2 is installed,
> Unicorn attempts to require rack pulling in the latest version since
> it doesn't know any better then boots Rails causing the gem conflict.
> Similar deal with passenger.
> 
> Unicorn has a valid reason for requiring rack since it needs to load
> Rack::Builder before it evals the config.ru file. The use of the
> builder dsl in .ru files causes a serious fundamental problem with
> loading rack. The application can never specify which version of rack
> to use since it has to be chosen before its loaded.
> 
> Possible workarounds:
> 
> 1) Always bootstrap with the correct version of rackup with `rackup
> _1.0.0_`, `/path/to/rack/1.0.0/bin/rackup`, etc.
> 2) Unicorn and Passenger should allow you to specify which rack
> version to use.
> 3) Specify a load path or environment file on boot that setups the
> correct paths or activates the right version of rack. This could be
> done by requiring an environment that loads Bundler or similar tools.
> 4) Hacky version independent version of rackup. I hacked this up to
> demonstration how http://gist.github.com/560926 you can lazily
> evaluate the builder dsl after the application loads.
> 
> Are there anymore workarounds? Whats the suggested fix? I'd like to
> hear some opinions on the whole bootstapping matter.

I generally write independent boostrap code for applications whenever necessary, to me this is as important a practice as writing proper build scripts and ensuring that 'make' or 'rake' from the top level boostraps, builds, and runs tests or the application as much without fail as is possible. I know many developers find this diligent practice "boring", but it is very important. Bundler made this all a hell of a lot easier.

The idea from 4 could maybe be extended to pushing the whole Rackup and Rack::Builder DSL (which seldom changes, and is not that tied to Rack spec or the Rack application API) to another gem. That gem needn't depend on rack (in theory it could load other things), and could provide a DSL method to load a specific version of rack dynamically. This would mean that users could once again take the easy way out, avoid writing manifests or builds, and simply spec a rack version in the rackup DSL.

Something like this could work:

    rack '1.0.1' # calls Kernel#gem with 'rack', '1.0.1'
    map '/' do ...

In scenarios where RubyGems is not in use, the users would either have to load a plugin that alters the Kernel#gem call to something else (although I don't know of another package manager in ruby that actually manages dependencies properly at runtime), otherwise if it's using the filesystem namespace for versioning (as most alternatives do), one could just omit the call, and rely on a later call to "require 'rack'".