Having Rails 2.3pre or Rack 1.1 installed breaks Rails 2.x
Hongli Lai
severe.
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4031-having-rails-23pre-or-rack-11-installed-breaks-rails-2x
Yehuda Katz
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Hongli Lai
> Hongli,
>
> This is a classic problem of the sort Bundler was created to solve. The only
> possible solutions are to either ensure that these versions of the gems do
> not coexist in a system gems repo or to use a tool like bundler to
> pre-resolve the list of needed dependencies.
>
> Simply changing the 2.3 dependency to >= 1.0.0 is a problem because Rails
> could potentially break if a new (incompatible) version of Rack is released.
> The entire purpose of the ~> dependency is to say "I know for sure I work on
> Rack 1.0.x, but not some future version".
Yeah but having all the system gems become unusable is not a good
thing. It's good that Bundler prevents problems but I'd rather see
these sorts of problems not occurring in the first place so that
Bundler is not needed so often.
As for Rack breakage, wouldn't that be easily solved with some version
numbering discipline? If Rack decides to break an interface then it
should bump its major version to 2.
Hongli Lai
> As for Rack breakage, wouldn't that be easily solved with some version
> numbering discipline? If Rack decides to break an interface then it
> should bump its major version to 2.
Now that I think about it, this wouldn't solve the web-server-requires-
rack-too-but-a-different-version problem. :-(
Yehuda Katz
On Mon, Feb 22, 2010 at 3:08 AM, Hongli Lai <hon...@phusion.nl> wrote:
>
> On Feb 22, 11:25 am, Yehuda Katz <wyc...@gmail.com> wrote:
> > Hongli,
> >
> > This is a classic problem of the sort Bundler was created to solve. The only
> > possible solutions are to either ensure that these versions of the gems do
> > not coexist in a system gems repo or to use a tool like bundler to
> > pre-resolve the list of needed dependencies.
> >
> > Simply changing the 2.3 dependency to >= 1.0.0 is a problem because Rails
> > could potentially break if a new (incompatible) version of Rack is released.
> > The entire purpose of the ~> dependency is to say "I know for sure I work on
> > Rack 1.0.x, but not some future version".
>
> Yeah but having all the system gems become unusable is not a good
> thing. It's good that Bundler prevents problems but I'd rather see
> these sorts of problems not occurring in the first place so that
> Bundler is not needed so often.
It's not clear how to avoid these problems. They arise when combining
gems that set reasonable dependencies. In this case, thin and
passenger both are certifying that they work with rack >= 1.0, but
Rails is only certifying that it works with rack ~> 1.0. Both of these
are perfectly valid assertions. In combination, however, requiring
thin first activates a dependency that Rails cannot handle. The only
solution is to examine all of the dependencies *at once* and discover
that a version (1.0.x) of the Rack satisfies all dependencies. This is
what bundler does.
>
> As for Rack breakage, wouldn't that be easily solved with some version
> numbering discipline? If Rack decides to break an interface then it
> should bump its major version to 2.
That's essentially what happens now. At present, Rack hasn't broken
things in teeny versions but it has in tiny. As a result, Rails 2.3 is
limiting itself to 1.0.x, while Rails 3.0 is limiting itself to 1.1.x.
Passenger and thin, on the other hand, are willing to handle 1.x. If
Rack bumped its version to 2.0 instead, the same problem could arise
(Rails 2.3 could depend on 1.x, but Rails 3.0 could depend on 2.x,
while Passenger and Thin wanted to support 1.x-2.x).
In essence, this is a fundamental problem when combining dependencies
with overlapping ranges. The only proper way to solve this is to
examine all dependencies at once and resolve them to find working
ranges. Requiring them linearly (the way without bundler) results in
these sorts of problems.
Hongli Lai
bug: http://rubyforge.org/tracker/index.php?func=detail&aid=27867&group_id=126&atid=575