[Rubygems-developers] Question on GEM_PATH
thewoolleyman at gmail.com
Sun Dec 16 15:33:48 EST 2007
On Dec 16, 2007 3:16 AM, Eric Hodel <drbrain at segment7.net> 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
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.
More information about the Rubygems-developers