Both approaches are somewhat equivalent since they set GEM_HOME. I like setting GEM_HOME to something like %TEMP%\gems because I can periodically just delete it, and get back to the same state that other devs have. You can't do that if you set GEM_HOME to ruby-1.8.6 and use .gitignore. I dont feel strongly about this, but is there a benefit to the latter approach?
________________________________ From: [email protected] [[email protected]] On Behalf Of Jim Deville [[email protected]] Sent: Thursday, August 06, 2009 12:13 AM To: [email protected] Subject: Re: [Ironruby-core] Dev.bat and GEM_PATH We could set it to ruby-1.8.6 and use .gitignore to ignore the path. JD …there is no try http://blog.jredville.com From: [email protected] [mailto:[email protected]] On Behalf Of Shri Borde Sent: Thursday, August 06, 2009 12:08 AM To: [email protected] Subject: Re: [Ironruby-core] Dev.bat and GEM_PATH In a non-dev environment (when you install the release zips), Merlin\External.LCA_RESTRICTED\Languages\Ruby\redist-libs becomes the Lib folder, and then "igem install" should install gems there. At that point, we do not need to keep that folder clean. However, in the GIT repo, the redist-libs folder should only contain the files that we want to go in the release zips, and not arbitrary gems that a dev needs to install for running tests. This dual-purpose is why dev.bat makes GEM_PATH point to Merlin\External.LCA_RESTRICTED\Languages\Ruby\ruby-1.8.6p287\lib\ruby\gems\1.8. GEM_HOME could be set to Merlin\External.LCA_RESTRICTED\Languages\Ruby\ruby-1.8.6p287\lib\ruby\gems\1.8, and then "igem install" will install new gems there, next to the other gems that are checked in. The only downside to this is that if you install a gem that you do not want to check in, it will keep showing up in "git gui". I instead set GEM_HOME to %TEMP%\gem from my private dev.bat in Merlin\Users\%USERNAME%\dev.bat. If I need to check in a new gem (which is infrequent), I temporarily set GEM_HOME to point to Merlin\External.LCA_RESTRICTED\Languages\Ruby\ruby-1.8.6p287\lib\ruby\gems\1.8 and do "igem install". Does that make sense? Would it make sense to set GEM_HOME to %TEMP%\gems for everyone in the common dev.bat? ________________________________ From: [email protected] [[email protected]] On Behalf Of Jimmy Schementi [[email protected]] Sent: Wednesday, August 05, 2009 10:13 PM To: [email protected] Subject: Re: [Ironruby-core] Dev.bat and GEM_PATH Sorry, my answer was partly wrong: “igem install” will still install into redist_libs/ironruby/gems. Gems will be loadable from IronRuby if they are in both locations, so it shouldn’t stop stuff from working. If you don’t like this behavior, and want all your IronRuby gems in one place, the either unset GEM_PATH or set GEM_HOME to be the same as GEM_PATH, depending on where you want gems to be installed and loaded from. I think setting GEM_PATH to point at ruby-1.8.6p287 only helps people who have a Microsoft TFS enlistment to the IronRuby sources, as there is a full MRI installation at Merlin\External.LCA_RESTRICTED\Languages\Ruby\ruby-1.8.6p287. If that’s the case, then we should fix this. Anyone else have insight into why we have two copies of the libraries checked in, and gems are split up between them? From: [email protected] [mailto:[email protected]] On Behalf Of Ryan Riley Sent: Wednesday, August 05, 2009 9:51 PM To: [email protected] Subject: Re: [Ironruby-core] Dev.bat and GEM_PATH Install gems using the gem command? igem seems to install into the ..\redist_libs\ironruby folder. At least, I think that's where they are going. Just trying to make sure I understand what's happening. Thanks! R2 On Wed, Aug 5, 2009 at 11:44 PM, Jimmy Schementi <[email protected]<mailto:[email protected]>> wrote: It uses ruby-1.8.6p287 so we can install gems, and even check them in, but not compromise the integrity of anything under redist_libs: it’s the cleanroom copy of the Ruby libraries. If you diff them your only see these changes: certain words filtered out that Microsoft does not allow in source code, bugs in the standard libs (using + instead of ^ with hashes) and certain library files removed that IronRuby won’t support (eg. Tk).
_______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
