[Rubygems-developers] Question on GEM_PATH

Chad Woolley 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
> 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


More information about the Rubygems-developers mailing list