>> How tight is the relationship between ruby and rubygems? >> >> > > It's a ruby program that installs itself as the package manager for the > ruby instance that invoked it. This version of rubygems requires ruby > >= 1.8.0. > > rubygems will be a part of the ruby codebase starting ruby 1.9. > >
Given that rubygems will make it into Ruby 1.9. I'm beginning to think that we should fold it into the Ruby package in Ruby 1.8, even though it's a different project right now. It'll be difficult to separate the rubygems functionality later, once merged sources for Ruby 1.9 are released. Merging our packages now will make things much easier with the next release of the package. More thoughts on the topic of versioning rubygems. We'll have to version it as well - this is because: Rubygems installs on a specific Ruby major.minor.teeny. And it can serve as a repository to only that particular Ruby installation. Ruby can be incompatible across versions. ie., it's expected to be incompatible across different minor versions. So when Ruby major.minor + x.teeny comes along, there will have to co-exist two Ruby versions unless the user explicitly uninstalls a previous version. When the user installs rubygems for Ruby major.minor+1.teeny, the second "instance" of rubygems cannot reuse any gems that the user might have installed in the gem repository(bound to Ruby major.minor.teeny), if they contained an executable. This is because such gems, when installed, are hardcoded with the location of the Ruby interpretor that the gem command is connected to.(Consequently, we run into this irrespective of whether the gem executable can actually execute on the new Ruby version). This problem will be solved by versioning the repository directories. -ps -- Prashant Srinivasan F/OSS Enthusiast Sun Microsystems, Inc. http://blogs.sun.com/prashant GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A
