[MacRuby-devel] PBI - macirb as a console, debugger, etc.

Richard Kilmer rich at infoether.com
Tue Oct 28 09:21:10 PDT 2008

On Oct 28, 2008, at 10:08 AM, Antonin Hildebrand wrote:

> Hi Richard,
>> In 1.9, and thus MacRuby, RubyGems is enabled differently than in  
>> 1.8 and so
> thanks for pointing this out,
> so for a newbie, it is transparent if library sits in stdlib or is
> preinstalled as a macgem
>> So if I had a gem named foo, the gem would be:
>> rich_kilmer-foo
>> Or whatever.  On RubyForge the gems can be named naturally...like  
>> 'console'.
> Yes, I think that is not a problem, because in code you still does:
> require 'foo' (http://gems.github.com/)
> Why not having macruby user on github owned by Laurent(Apple)?
> Preinstalled gems will be those macruby-* and Laurent will have full
> control over them.

I think that a macruby user on github could work...see below...

> In code you will do
> require 'foo'
> If you want upgrade gem to latest version, you do:
> $sudo macgem update macruby-foo
> If you want to install alternative gem:
> $sudo macgem install woid-foo
> If you want to use alternative gem:
> $sudo macgem uninstall macruby-foo
> - or -
> in code:
> gem 'woid-foo'
> require 'foo'
> ---
> I've used RubyForge some time ago, and it was quite a pain to setup
> gem project there (even i've used hoe and newgem helpers).
> And that is why I think most people don't like the gem idea, they
> somehow feel maintaining gem server will be pain-in-the-ass.
> Not necessarily with github!

You don't maintain a gem server on RubyForge, RubyForge maintains the
gem server.  You release gems.  You are saying that maintaining the
YAML file and uploading releases makes it prohibitive to use RubyForge?

My main concern with GitHub as a central distribution point for these  
should Apple decide to do this, is its a commercial entity whereas  
is owned by the Ruby Central non-profit.

> I agree with the argument of tying library versions to OS updates. But
> this can be solved also with gem scenario.
> macruby user on github has full control when he updates the gems. It
> can be only with new OS releases.
> Backward compatibility with different MacRuby installations should be
> gem's responsibility (!important).
> Example: gem macruby-foo
> 1) MacRuby 0.4 ships with foo 0.1.0
> 2) MacRuby 0.5 ships with foo 0.2.0, gem is available on github on the
> day of MacRuby 0.5 release, foo 0.2.0 is backward compatible with
> MacRuby 0.4 (for example keeps also old code path)
> 3) someone does significant update to foo, Laurent decides to release
> foo 0.3.0 on github independently (it can be just cherrypicking
> someone's changes from alternative (github) forks)
> 4) MacRuby 0.6 ships with foo 0.4.0, foo 0.4.0 is not compatible with
> MacRuby 0.4, if someone tries to require it in MacRuby 0.4, she gets
> clear error messsage "foo 0.4.0 requires MacRuby 0.5 or higher, please
> update your macruby installation or downgrade foo gem"
> 5) ...
> Anytime, folks are free to replace macruby-foo, with anyones-foo. And
> going back and forth with ease of macgem command.

Actually this is not really the case.  When you install the gem:


The gem name is macruby-foo, not foo.  Even though in your example
you said:

require 'foo'

ANYONE can create a foo.rb in their lib of their gem and you would get
that instead, and you don't control load order so you don't know what
foo.rb you will get.  Normally, you would want to name the required file
the same as the gem name:

require 'macruby-foo'

Thus there would be no name collision.  If another person were to  
a gem that contained macruby-foo.rb in it it MAY be loaded before the
standard one, but there is no guarantee of that.

On the flip side, its easy to release gems that contain std library
replacement files since they precede the std library in the LOAD_PATH.
So we could have these files in the std library but someone could come
along and release gems that provide incremental updates.  The lame thing
is then when Apple updates the std lib versions the Gem versions will
still supersede it.  Perhaps just keeping with the std lib is enough...



> I still believe, we can get best of both worlds with gems.
> Antonin
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

More information about the MacRuby-devel mailing list