On 21 May 2010, at 12:23, Rick DeNatale wrote: > On Fri, May 21, 2010 at 10:52 AM, Trans <transf...@gmail.com> wrote: >> Actually, I think it is better that way. With RubyGems I am not even >> sure why it bothers to divide gem install by ruby version, i.e. /usr/ >> lib/ruby/gems/1.8/ vs. /usr/lib/ruby/gems/1.9/. That kind of division >> made sense for setup.rb b/c installs would literally clobber each >> other there, but that is no longer the case with gems. So why bother? > > If there is a C extension in the gem, the Ruby extension API has some > incompatibilities between 1.8.x and 1.9.x
In fact, a C extension has to assurance to work even on the same version of the interpreter. You could have linked a different C runtime, you could have patched with REE, you could have different structs, etc, etc. We can't audit or manifest all of this detail (although it would be nice). There is some discussion on the rubyforge tracker on this topic already. It is absolutely critical for strict *correctness* (i.e. user reliability) that we not only version by a partial ruby version (1.8/1.9), but actually a full ruby version, including patch customisations, configuration details, and so on. Ideally each ruby install should have it's own unique identifier for the installation on the local system, and this value would be used to separate gems. An incomplete, poor example might be: ruby-1.8.7-p247-x86-mswin32-60, or ree+dtrace+mbari-1.8.7-p247-p12-x86-linux-gcc4.3.4-glibc2.10.1 I think it is important for a high level language with the design goals of ruby (human friendliness) that we don't deliberately implement solutions that may regularly lead to users having to dig into gdb in order to figure out what is going on. Rubyists care about ruby code, nothing lower level, and I think rubygems should continue to do what it can to make sure that this is the case, even if it may use more disk space. If you want to keep several gem sets in sync, well, you could very easily script up a new front end to the gem command to do this for you, and is something that any developer in the language should be able to do in absolutely minimal code, hell, you could just do it in sh(1). http://rubyforge.org/tracker/index.php?func=detail&aid=14943&group_id=126&atid=575 All food for thought... _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
