On Dec 16, 2007 3:16 AM, Eric Hodel <[EMAIL PROTECTED]> wrote: > On Dec 15, 2007, at 23:05 PM, Chad Woolley wrote: > > When I use GEM_PATH to add an additional local repository to be used, > > what dirs must be in that repository? gems? specifications? docs? > > cache? others? > > The directory doesn't even need to exist. RubyGems will create it and > everything it needs inside it when you reference it, provided you have > permission to do so.
I meant when I was reading an already-existing gem out of a repo on GEM_PATH, with the 'gem' method. What dirs does this require the gem to be in? just 'gem' and 'specifications', or more? > > Also, a related question. If I have a source checkout of a gem > > locally, can I somehow put it on my GEM_PATH to be loaded, even if it > > doesn't follow the standard repository layout? The use case would be > > to perform updates on a dependency gem, and have those updates > > immediately usable by a separate local app, without having to actually > > do the step to build and install the gem to a local repository. > > I use two tricks for this. > > The frequently-used trick is to add the paths for the various > dependencies to the -I flag while working on the other dependent > project. RUBYLIB can also accomplish this. OK, that works, but it requires intimate knowledge of the dependency gem. It would be nice to have some method like 'gem' that parsed a spec and loaded the references for you. > > The hardly-used trick is hoe's install_gem task. hehe, that's what I use. It's simple, but I want to skip even that step. > > Adding a way to load gems w/o being in a gem has been brought up > before, and I rejected the feature. It's much simpler to use -I or > RUBYLIB than to add a bunch of code to RubyGems to accomplish the same > end. I can understand that, and it's not too hard to use -l if you know what you need. It's just harder if someone doesn't know exactly how to do this, but I could write my own logic to do it. The scenario I'm thinking of is if we package our company's common code as gems instead of plugins (piston/svn externals). plugins are easy to hack-in-place. If we used gems instead, the -l step or installing gems would be (perceived by some as) much harder than just using plugins. Anyway, Thanks for the response. -- Chad _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
