Hi, I see there's a `macgem` command, and I've noticed it picks up the same env as `gem`. Is it going to screw things up if I install from both into the same place, or should I give macgem its own special place? Regards, Iain
Hi! By default, macgem installs gems in /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/Gems/1.9.2/gems You should not try to merge ruby gems and macruby gems (or make MacRuby install / use the ruby dir), because compiled extensions will not be compatible. Some gems that compiled a library for ruby will not work for MacRuby and vice versa :-) -- Thibault Martin-Lagardette On Sep 15, 2010, at 09:53, Iain Barnett wrote:
Hi,
I see there's a `macgem` command, and I've noticed it picks up the same env as `gem`. Is it going to screw things up if I install from both into the same place, or should I give macgem its own special place?
Regards, Iain _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 15 Sep 2010, at 18:48, Thibault Martin-Lagardette wrote:
By default, macgem installs gems in /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/Gems/1.9.2/gems
Thanks. I'd ran `macgem env` and got the same output as `gem env` and got a bit worried, but if you're sure it'll ignore that then I can put away the diazepams :) Regards, Iain
Well, is the output EXACTLY the same? It's not for me: MacRuby: - GEM PATHS: - /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/Gems/1.9.2 - /Users/naixn/.gem/macruby/1.9.2 Ruby: - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/naixn/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 Ruby 1.9: - GEM PATHS: - /usr/local/lib/ruby/gems/1.9.1 - /Users/naixn/.gem/ruby/1.9.1 If your GEM PATHS is exactly the same in both output, maybe there is a problem. Do you have a gemrc in your home directory that would hardcode the path for example? -- Thibault Martin-Lagardette On Sep 15, 2010, at 10:56, Iain Barnett wrote:
On 15 Sep 2010, at 18:48, Thibault Martin-Lagardette wrote:
By default, macgem installs gems in /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/Gems/1.9.2/gems
Thanks. I'd ran `macgem env` and got the same output as `gem env` and got a bit worried, but if you're sure it'll ignore that then I can put away the diazepams :)
Regards, Iain _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 15 Sep 2010, at 19:01, Thibault Martin-Lagardette wrote:
Well, is the output EXACTLY the same? It's not for me:
Yep, it's exactly the same because I've a .gemrc and some env vars set in my .profile too. I'll install via macgems by adding the --install-dir option. Thanks for letting me know they shouldn't mix. Regards, Iain
On 15 Sep 2010, at 22:37, Iain Barnett wrote:
I'll install via macgems by adding the --install-dir option. Thanks for letting me know they shouldn't mix.
I'm getting some problems while trying to install hotcocoa this way. I've posted all the commands I went through below with output, but it ends up that hotcocoa only works if it's where the MatzRuby gems sit. Does anyone know where I can look to see why this is?
Yep, it's exactly the same because I've a .gemrc and some env vars set in my .profile too.
I also realised I was mistaken before when saying macgem env and gem env return exactly the same output, macgem env returns an extra field RUBYGEMS PREFIX which is set to the current dir. Any idea what this is for? ------------ At this point I delete everything in the ~/.macgems dir to start clean. $ macgem install hotcocoa -r --install-dir ~/.macgems Successfully installed hotcocoa-0.5.1 1 gem installed $ hotcocoa testingHotCocoa Could not find RubyGem hotcocoa (>= 0) (Gem::LoadError) Just to check... $ ~/.macgems/bin/hotcocoa Could not find RubyGem hotcocoa (>= 0) (Gem::LoadError) $ macgem uninstall hotcocoa ERROR: While executing gem ... (Gem::InstallError) cannot uninstall, check `gem list -d hotcocoa` cannot uninstall, check `gem list -d hotcocoa` (Gem::InstallError) Again, I delete everything in ~/.macgems and decide to try installing in ~/.gems where I keep gems for Matz's Ruby. $ macgem install hotcocoa -r ERROR: While executing gem ... (Errno::EACCES) Permission denied - open() failed Permission denied - open() failed (Errno::EACCES) $ sudo macgem install hotcocoa -r Password: Successfully installed hotcocoa-0.5.1 1 gem installed I don't usually need sudo to install in the dir with MatzRuby gems, so I'm wondering why the error? $ hotcocoa testingHotCocoa No news is good news! It works (so far), but now I have to keep track of a mixture of gems :( $ macgem env /Volumes/RubyProjects RubyGems Environment: - RUBYGEMS VERSION: 1.3.6 - RUBY VERSION: 1.9.0 (2008-06-03 patchlevel 0) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Users/iainuser/.gems - RUBYGEMS PREFIX: /Volumes/RubyProjects - RUBY EXECUTABLE: /Library/Frameworks/MacRuby.framework/Versions/0.6/usr/bin/macruby - EXECUTABLE DIRECTORY: /Users/iainuser/.gems/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Users/iainuser/.gems - /Users/iainuser/.gems/gems - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "gemhome" => "/Users/iainuser/.gems" - "gem" => "--local --gen-rdoc --run-tests" - "rdoc" => "--inline-source --line-numbers" - "gempath" => ["/Users/iainuser/.gems", "/Users/iainuser/.gems/gems"] - :sources => ["http://gemcutter.org", "http://gems.rubyforge.org/", "http://gems.github.com"] - REMOTE SOURCES: - http://gemcutter.org - http://gems.rubyforge.org/ - http://gems.github.com Regards, Iain
On Sep 15, 2010, at 10:56 , Iain Barnett wrote:
On 15 Sep 2010, at 18:48, Thibault Martin-Lagardette wrote:
By default, macgem installs gems in /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/Gems/1.9.2/gems
Thanks. I'd ran `macgem env` and got the same output as `gem env` and got a bit worried, but if you're sure it'll ignore that then I can put away the diazepams :)
yeah. this is probably a problem. I'm guessing you have GEM_PATH set in your environment like I do. I've got: GEM_PATH=/Library/Ruby/Gems/1.8 and right now I can't even run `macgem env` because it is freakin' out on me and taking up 450+ MB of ram. I'm chasing that down as it is prolly a tangent. rubygems and/or macruby should probably be patched to include RUBY_ENGINE somewhere in the gem path. Eric... having a GEM_PATH like variable where I can specify it non-versioned would be great too. One variable to rule them all.
On 15 Sep 2010, at 22:43, Ryan Davis wrote:
rubygems and/or macruby should probably be patched to include RUBY_ENGINE somewhere in the gem path.
That's a really good idea. Either that or just accept that macruby is a separate thing altogether and have MAC_GEM_PATH etc etc. Proliferation of vars doesn't bother me, they only get set once. Regards, Iain
On Sep 15, 2010, at 15:30 , Iain Barnett wrote:
On 15 Sep 2010, at 22:43, Ryan Davis wrote:
rubygems and/or macruby should probably be patched to include RUBY_ENGINE somewhere in the gem path.
That's a really good idea. Either that or just accept that macruby is a separate thing altogether and have MAC_GEM_PATH etc etc. Proliferation of vars doesn't bother me, they only get set once.
yes, but then you have a proliferation of rubygem implementations... I'd prefer we work out something that works for everyone so that when you say 1.3.8 of rubygems it means the same across all ruby impls.
how about just working nicely with rvm? On 16/09/2010, at 1:58 PM, Ryan Davis wrote:
On Sep 15, 2010, at 15:30 , Iain Barnett wrote:
On 15 Sep 2010, at 22:43, Ryan Davis wrote:
rubygems and/or macruby should probably be patched to include RUBY_ENGINE somewhere in the gem path.
That's a really good idea. Either that or just accept that macruby is a separate thing altogether and have MAC_GEM_PATH etc etc. Proliferation of vars doesn't bother me, they only get set once.
yes, but then you have a proliferation of rubygem implementations... I'd prefer we work out something that works for everyone so that when you say 1.3.8 of rubygems it means the same across all ruby impls.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 2010-09-15, at 19:30 , Iain Barnett wrote:
On 15 Sep 2010, at 22:43, Ryan Davis wrote:
rubygems and/or macruby should probably be patched to include RUBY_ENGINE somewhere in the gem path.
That's a really good idea. Either that or just accept that macruby is a separate thing altogether and have MAC_GEM_PATH etc etc. Proliferation of vars doesn't bother me, they only get set once.
I'm partial to this. Env vars tend to be a problem. cf. RUBYOPT, RUBYLIB. Maybe having MAC- prefixed vars is a good idea.
Hi Ryan, On Sep 15, 2010, at 2:43 PM, Ryan Davis wrote:
On Sep 15, 2010, at 10:56 , Iain Barnett wrote:
On 15 Sep 2010, at 18:48, Thibault Martin-Lagardette wrote:
By default, macgem installs gems in /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/Gems/1.9.2/gems
Thanks. I'd ran `macgem env` and got the same output as `gem env` and got a bit worried, but if you're sure it'll ignore that then I can put away the diazepams :)
yeah. this is probably a problem. I'm guessing you have GEM_PATH set in your environment like I do. I've got:
GEM_PATH=/Library/Ruby/Gems/1.8
and right now I can't even run `macgem env` because it is freakin' out on me and taking up 450+ MB of ram. I'm chasing that down as it is prolly a tangent.
As we talked I suspect one of your gems is making MacRuby sick here, but it may be hard to find which one... If you don't want to bother with that, feel free to open a ticket and paste your gems list there, we will have a look :)
rubygems and/or macruby should probably be patched to include RUBY_ENGINE somewhere in the gem path.
Eric... having a GEM_PATH like variable where I can specify it non-versioned would be great too. One variable to rule them all.
I am not sure yet if there is a good solution for this problem, but it does not seem to be specific to MacRuby. For example, GEM_PATH=/Library/Ruby/Gems/1.8 may not work with Ruby 1.9's gem too (because of binary incompatibility in C extensions). In any case let me know if you find a good solution and if macruby has to be patched. Laurent
participants (6)
-
Caio Chassot
-
Iain Barnett
-
Laurent Sansonetti
-
Ryan Davis
-
Terry Moore
-
Thibault Martin-Lagardette