Ruby 2.0 (trunk ruby) is not Ruby 1.9 #1539

Merged
merged 1 commit into from Nov 16, 2011

Conversation

Projects
None yet
7 participants
Contributor

tenderlove commented Nov 16, 2011

Bundler treats trunk ruby as Ruby 1.9, when that is not true. This will make bundler return false for Ruby 2.0.

wycats added a commit that referenced this pull request Nov 16, 2011

Merge pull request #1539 from tenderlove/ruby20
Ruby 2.0 (trunk ruby) is not Ruby 1.9

@wycats wycats merged commit c6cd06b into bundler:master Nov 16, 2011

Owner

indirect commented Nov 16, 2011

Wot? Bros, this will break every existing Gemfile on ruby-head.

Contributor

tenderlove commented Nov 16, 2011

They were already broken as soon as ruby-head changed the version to ruby 2.0. It means that bundler incorrectly treats ruby 2.0 as ruby 1.9. :-/

Owner

indirect commented Nov 16, 2011

The way people use this in Gemfiles is like so:

if mri_19?
  gem "ruby-debug19"
else
  gem "ruby-debug"
end

So this change breaks all of those gemfiles on ruby-head. :(

Owner

indirect commented Nov 16, 2011

Maybe we should add mri_above_19? and alias mri_19? to it. What is the use-case that this patch is fixing?

Contributor

tenderlove commented Nov 16, 2011

ruby-debug19 doesn't work with ruby head anyway, so the example code you've shown is broken regardless.

Owner

indirect commented Nov 16, 2011

Heh, sorry Bad example. But back to my attempted original point: Does ruby-debug work with ruby head? Are there any other examples where ruby-head works with the 1.8-compatible gem but not the 1.9-compatible gem?

Contributor

tenderlove commented Nov 16, 2011

No, ruby-debug doesn't work with ruby-head. ruby-debug works by downloading the header files for the particular version it's running against. Since Ruby 2.0 hasn't been released yet, there is no tarball for ruby-debug to download. Basically, as soon as we change the version on ruby-trunk, ruby-debug will break. (This is because ruby-debug is doing things it shouldn't do, but that is beside the point)

If people say if mri_19?, it seems they would want Ruby 1.9, not Ruby 2.0 (which is current trunk ruby).

Maybe you should introduce an object that represents the ruby version that people can do comparisons against. Something like this:

if Bundler.ruby_version > "1.9"
  ...
else
  ...
end
Owner

indirect commented Nov 16, 2011

If that's all people want, they can already do if RUBY_VERSION > "1.9". The reason the platform :mri_19 code exists is so that people can explicitly flag gems that work on "1.9-ish" rubies, vs gems that work on "1.8-ish" rubies. That is the only use-case that I know of. It seems that ruby-head will in fact run the "1.9-ish" gems, and not run the "1.8-ish" gems. If that is true, I think this patch is bad, because it will keep Bundler from installing the "1.9-ish" gems on ruby-head.

Contributor

tenderlove commented Nov 17, 2011

Cool Story Bro. That's the C ABI version. ;-)

Contributor

jeremy commented Nov 17, 2011

Right... extensions are binary-compatible with 1.9! What does mri_19? really mean again?

Contributor

wycats commented Nov 17, 2011

I agree with Jeremy here.

Contributor

tenderlove commented Nov 17, 2011

I think Jeremy asked a question rather than stating an opinion. Does mri_19 mean ABI compatibility, or does it mean ruby version?

Contributor

wycats commented Nov 17, 2011

The reason for the flag is to deal with the fact that there are two commonly-used Ruby ABIs: 1.8 and 1.9. Its use-case is for native gems. Native gems using internal functionality that breaks even though the ABI is compatible is outside the scope of bundler, sadly.

Owner

indirect commented Nov 17, 2011

@wycats, given that, shouldn't this be reverted?

Contributor

tenderlove commented Nov 17, 2011

If this is actually indicating ABI, then shouldn't we provide a way to differentiate between Ruby 1.9.0 and 1.9.1 (since the ABI changed)?

Contributor

wycats commented Nov 18, 2011

No, because nobody uses 1.9.0.

rocky commented Nov 20, 2011

(This is because ruby-debug is doing things it shouldn't do, but that is beside the point)

@tenderlove : this is a cheap shot. There is and never was a way for ruby-debug in MRI 1.9 or 2.0 to do the things that were possible in MRI 1.8. So the options left such as:

  • providing nothing (the default option),
  • providing worse support (i.e. living within the confines of what can still be done),
  • patching the kernel
  • or "doing things it shouldn't do"

are all bad ones. And as you should know, the limited attempts to improve MRI YARV runtime for debugging haven't had much motion.

Contributor

tenderlove commented Nov 20, 2011

@rocky this isn't a cheap shot about anything, please don't take offense. ruby-debug exposes Ruby's internal C apis, which it shouldn't do. It shouldn't do this because it causes a headache for ruby-core developers. When ruby-debug breaks, we get bugs reported saying that ruby broke C apis, when the truth is that internal apis changed. ruby-core cannot be held accountable for internal APIs changing, that's why they're internal. I think we can agree that exposing internal API is something you "shouldn't do". Weighing the pros and cons of "shouldn't do" is up to you. :-)

Anyway, I don't particularly care what ruby-debug should or shouldn't do. The problem I'm dealing with is that I can't build it on trunk ruby, and (until recently rails/rails@a437986 ) it was required to be installed for development on rails core.

@tenderlove i think the point @rocky was making was that in order for ruby-debug to work effectively it has to access ruby's private api. This may cause breakages and so on when the private API is changed between ruby versions, but there's really no other option (afaik) if we want ruby to have a decent debugger.

If core implement a proper debugging API, then ruby-debug could hook into that and all would be well, but this hasn't happened yet.

rocky commented Nov 26, 2011

@banister - right. @tenderlove - So one could either criticize ruby-debug (which is in my opinion is a rather easy thing to do) or one could try to get support for debugging and run-time introspection better supported in MRI 1.9 and 2.0.

mrflip pushed a commit to mrflip/bundler that referenced this pull request Aug 13, 2012

Philip (flip) Kromer
Ruby 2.0+ should have platform definitions
Added `:ruby_20`, `:mri_20` and `:mingw_20`
Also made same fix to `mingw_19?` as #1539 -- 19 is not 20.

mrflip pushed a commit to mrflip/bundler that referenced this pull request Aug 13, 2012

Philip (flip) Kromer
Ruby 2.0+ platform definitions (+w/s fix)
Added `:ruby_20`, `:mri_20` and `:mingw_20`
Also made same fix to `mingw_19?` as #1539 -- 19 is not 20.

mrflip pushed a commit to mrflip/bundler that referenced this pull request Aug 13, 2012

Philip (flip) Kromer
Ruby 2.0+ platform definitions (+w/s fix)
Added :ruby_20, :mri_20 and :mingw_20, and made the same fix to mingw_19? as #1539 did -- 19 is not 20.

mrflip commented Aug 14, 2012

Here's something that appears in a lot of gemfiles:

group :test do
  gem 'rcov',       :platform => [:ruby_18]
  gem 'simplecov',  :platform => [:ruby_19]
end

Currently, on ruby 2.0 neither gem will install, since ruby_19 means ">= 1.9.0, < 2.0.0". There's no good way to say "please install simplecov when I'm not on 1.8". In #2056 @indirect makes clear that these are not intended for platform fencing, and I think his point is good. However you feel about the semantics of ruby_19, the facts are these: there are a lot of gems out there that have snippets like the one above, and they will all break.

Either:

  • clarify that ruby_19 means "the ruby 1.9+ api" -- that is, >= 1.9.0 -- and revert this change. Make clear that if an ABI update happens, this will receive an upper bound.

or:

  • affirm that ruby_19 means ruby version >= 1.9.0 < 2.0.0.
  • add ruby_20 meaning >= 2.0.0 < 2.1.0 OR add ruby_19_plus meaning >= 1.9.0.
Owner

indirect commented Aug 16, 2012

Oof. I think this means ruby_19 is broken, and needs fixing badly. :( Your example with rcov/simplecov (and the other very common one, of ruby-debug vs. debugger), is exactly why the distinction should be between 1.8 and 1.9+.

indirect added a commit that referenced this pull request Aug 16, 2012

Revert "Ruby 2.0 (trunk ruby) is not Ruby 1.9"
As discussed in #1539 and #2056, Bundler uses platforms to distinguish Ruby ABI versions. That means the known (and ATM supported) use cases for the ruby_19 platform include Ruby 2.0.

This reverts commit dcfb640.

indirect added a commit that referenced this pull request Aug 30, 2012

Revert "Ruby 2.0 (trunk ruby) is not Ruby 1.9"
As discussed in #1539 and #2056, Bundler uses platforms to distinguish Ruby ABI versions. That means the known (and ATM supported) use cases for the ruby_19 platform include Ruby 2.0.

This reverts commit dcfb640.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment