Issue #6124 has been updated by Vit Ondruch.


Yes, the availability of gems in stdlib loadpath is wrong, since everything what is in loadpath is loaded prior gems. RubyGems loading mechanism is just fallback.

Regarding the backward compatibly, it comes into play only when you use the --disable-gems flag and the flag itself is not backward compatible, so I see no point to talk about backward compatibility at all.

BTW I am not sure what you are referring by real gems, since these are definitely not real gems. Even the spec files are not real spec files, just some mockup. They don't contain the #require_paths (yes, it is not needed since the gems are already in the load path), I doubt you cannot refer them in Gemfile and vendor them using "bundle package", etc.
----------------------------------------
Bug #6124: What is the purpose of "fake" gems in Ruby
https://bugs.ruby-lang.org/issues/6124

Author: Vit Ondruch
Status: Open
Priority: Normal
Assignee: Eric Hodel
Category: 
Target version: 
ruby -v: ruby 1.9.3p0 (2011-10-30) [x86_64-linux]


As I tried to point out in #6123, the "fake" gems which are distributed with Ruby breaks user's expectations. The following example should fail:

$ ruby --disable-gems -e "puts require('bigdecimal')"
true

However, it is not failing. Could you please enlighten me what is the purpose of fake gem then? Even if you install updated BigDecimal from rubygems.org, the bundled version will won unless you use "gem 'bidgecimal'" somewhere in the code. This makes no sense.

Don't take me wrong, I am big fan of gemified stdlib #5481, however this is not the way how it should be done.


-- 
http://bugs.ruby-lang.org/