On Wed, Sep 8, 2010 at 5:26 PM, Marcus Rueckert <darix / opensu.se> wrote:
>
> because a ruby 1.9.3 describes a feature set which includes the stdlib.
> so when ever ruby -v returns 1.9.3 all the stdlib features should always
> be available. updating them to a newer version or so is not a problem as
> you can always say gem "foo", "=x.y", but the x.y from the release
> should always be available.
>
> otherwise you will get a lot of fun like:
> "yes i run ruby 1.9.3 on my system"
> "then you should have rdoc"
> "uhm I just see my coworker ran gem uninstall rdoc earlier, is that bad?"
>
> and the versioning part brings up another interesting question:
>
> how to address the "ruby 1.9.3 version" of the gem if you have a newer
> version of the gem installed? require "foo" would get me the latest
> version normally. 'gem "foo", "=1.9.3"'? that sounds awkward.
>

While this could be a problem, is not precisely any new one we had encountered.

This could be tackled with the similar approach Apple has taken for
the gems they include in their installation, amking them framework
part or "vendored"

You can always install something on top, but you can't remove the
vendored ones unless you explicitly tell it so (gem uninstall
--install-dir)

I think the same can be done for Ruby, use gem representations of
stdlib packages. After all, gem_prelude works perfectly for finding

Wasn't RubyGems inclusion in Ruby-Core provide builtin support for
gems in Ruby? I think we could take advantage of that.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupy