Rails core - Feb 2010 - Having Rails 2.3pre or Rack 1.1 installed breaks Rails 2.x

Hi guys, can I call attention for this ticket? I think it''s pretty
severe.
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4031-having-rails-23pre-or-rack-11-installed-breaks-rails-2x

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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".

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325


On Mon, Feb 22, 2010 at 1:44 AM, Hongli Lai <hongli@phusion.nl> wrote:
> Hi guys, can I call attention for this ticket? I think it''s pretty
> severe.
>
>
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4031-having-rails-23pre-or-rack-11-installed-breaks-rails-2x
>
> --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
>
rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.

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.

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Feb 22, 12:08 pm, Hongli Lai <hon...@phusion.nl>
wrote:
> 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. :-(

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Responses inline.

On Mon, Feb 22, 2010 at 3:08 AM, Hongli Lai <hongli@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.
>
> --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
>
-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I believe this is something that needs fixing in RubyGems. I filed a
bug:
http://rubyforge.org/tracker/index.php?func=detail&aid=27867&group_id=126&atid=575

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.