Re: [MacRuby-devel] PBI - macirb as a console, debugger, etc.
Hi guys, It seems I'm alone in opinion on packaging console as a gem right now :-/ In my opinion MacRuby should be Ruby1.9 with original stdlib shape. Nothing more. The only difference should be ObjC runtime + changes forced by this environment. Other useful library additions should be preinstalled macgems, including HotCocoa as a gem. Rich, I'm also promoting including them. I'm just talking about including them in different place of MacRuby release, not in stdlib. Jordan said:
It's very MacRuby-specific, what we're talking about here, and not really a generic gem. Sounds to me, that you are promoting that MacRuby specific things shouldn't be gems. Gems is a generic system for ruby libraries. No mater how specific they are to specific technologies. Copying bunch of things into stdlib is a dirty old-fashioned way Matz was doing with ruby when no rubygems ever existed :-)
Rich said:
The fewer hoops a newbie has to jump through, the better chance that s/he won't get Tired For a newbie the difference is just in two lines on top of the (generated) file:
instead of: require 'console' there will be: require 'rubygems' require 'console' If she knows nothing about gems, then she probably knows nothing about stdlib location. So she takes it as a magic. --- Laurent, I have a proposal for you: I will create console project as a gem published on github (maybe this weekend). And you may freely take what you find useful and include it in MacRuby releases. I want to show that 'gemization' of a ruby library is a piece of cake with github. Anybody then can take it, innovate and republish. And switching is just a mater of running macgem command. regards, Antonin On Tue, Oct 28, 2008 at 5:43 AM, Rich Morin <rdm@cfcl.com> wrote:
FWIW, I'd like to see the console (and any other generally-useful tools) included in the MacRuby release. The fewer hoops a newbie has to jump through, the better chance that s/he won't get Tired of the Whole Thing and bail out.
In the meanwhile, I've taken an initial swipe at creating a HowTo for getting and using Antonin's Console project:
https://www.macruby.org/trac/wiki/MacRubyConsoleHowTo
After typing "2 + 2" into the irb session, I kinda ran out of steam, but I will try to get back to it RSN. In the meanwhile, feel free to contribute and/or correct...
-r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Just my $0.02. In 1.9, and thus MacRuby, RubyGems is enabled differently than in 1.8 and so you don't even have to do: require 'rubygems' All gems' lib paths are pushed on the LOAD_PATH at init time and versioning is still enabled through some magic constant_missing/ method_missing stuff in gems itself. If you ARE going to ship a gem with MacRuby though, don't do it from github because the name of the gem is prefaced with the user's account. 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'. Anyway, the benefit I see with gems is they can be incrementally updated between OS updates. This could be a GOOD THING. If we had several of our macruby libraries as gems then we could provide updates to them often...then when the OS updates the latest gem could be included there. That could be interesting from an incremental update perspective. If control of the libraries and tying them to OS updates is valued, however, then gems may not a good idea. Best, Rich K. On Oct 28, 2008, at 8:41 AM, Antonin Hildebrand wrote:
Hi guys, It seems I'm alone in opinion on packaging console as a gem right now :-/
In my opinion MacRuby should be Ruby1.9 with original stdlib shape. Nothing more. The only difference should be ObjC runtime + changes forced by this environment. Other useful library additions should be preinstalled macgems, including HotCocoa as a gem.
Rich, I'm also promoting including them. I'm just talking about including them in different place of MacRuby release, not in stdlib.
Jordan said:
It's very MacRuby-specific, what we're talking about here, and not really a generic gem. Sounds to me, that you are promoting that MacRuby specific things shouldn't be gems. Gems is a generic system for ruby libraries. No mater how specific they are to specific technologies. Copying bunch of things into stdlib is a dirty old-fashioned way Matz was doing with ruby when no rubygems ever existed :-)
Rich said:
The fewer hoops a newbie has to jump through, the better chance that s/he won't get Tired For a newbie the difference is just in two lines on top of the (generated) file:
instead of: require 'console'
there will be: require 'rubygems' require 'console'
If she knows nothing about gems, then she probably knows nothing about stdlib location. So she takes it as a magic.
---
Laurent, I have a proposal for you: I will create console project as a gem published on github (maybe this weekend). And you may freely take what you find useful and include it in MacRuby releases.
I want to show that 'gemization' of a ruby library is a piece of cake with github. Anybody then can take it, innovate and republish. And switching is just a mater of running macgem command.
regards, Antonin
On Tue, Oct 28, 2008 at 5:43 AM, Rich Morin <rdm@cfcl.com> wrote:
FWIW, I'd like to see the console (and any other generally-useful tools) included in the MacRuby release. The fewer hoops a newbie has to jump through, the better chance that s/he won't get Tired of the Whole Thing and bail out.
In the meanwhile, I've taken an initial swipe at creating a HowTo for getting and using Antonin's Console project:
https://www.macruby.org/trac/wiki/MacRubyConsoleHowTo
After typing "2 + 2" into the irb session, I kinda ran out of steam, but I will try to get back to it RSN. In the meanwhile, feel free to contribute and/or correct...
-r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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
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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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@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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (2)
-
Antonin Hildebrand
-
Richard Kilmer