Ruby 2.0 (trunk ruby) is not Ruby 1.9

[tenderlove]

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

[indirect]

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

[tenderlove]

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. :-/

[indirect]

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. :(

[indirect]

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

[tenderlove]

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

[indirect]

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?

[tenderlove]

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

[indirect]

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.

[jeremy]

https://github.com/ruby/ruby/blob/trunk/include/ruby/version.h#L32-35

[tenderlove]

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

[jeremy]

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

[wycats]

I agree with Jeremy here.

[tenderlove]

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

[wycats]

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.

[indirect]

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

[tenderlove]

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)?

[wycats]

No, because nobody uses 1.9.0.

[rocky]

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

[tenderlove]

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

[banister]

@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]

@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]

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.

[indirect]

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