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
gems,
should Apple decide to do this, is its a commercial entity whereas
RubyForge
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:
macruby-foo
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
release
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...
Best,
Rich
I still believe, we can get best of both worlds with gems.
Antonin
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
