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

[Antonin Hildebrand]

Rich, I agree. Just one note.

Github's user- prefix on gems should not be considered as a part of
gem's main include file name.

Reason:
When I fork someone's gem, say macruby-foo. I don't want to rename
lib/macruby-foo.rb to lib/woid-foo.rb. This would render merging back
more difficult.
Forking gem project shouldn't force you to rename or modify files
inside the project.

Include aliasing on load path is general thing and gem authors should
pick unique names enough (it depends on their ambitions).
Instead of macruby-foo, the name should be macruby-fancyfoonoonecaneventhinkof

Also gem authors should play nice and do not put junk into their /lib
directories. Ideally there should be only
fancyfoonoonecaneventhinkof.rb.

regards,
Antonin


On Tue, Oct 28, 2008 at 5:21 PM, Richard Kilmer <rich at infoether.com> wrote:
>
> 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
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>