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

[Antonin Hildebrand]

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.

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!

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.

I still believe, we can get best of both worlds with gems.
Antonin