Google Groups

A second Gemfile and lock? I.e. Gemfile.local, Gemfile.lock.local?

Danimal Feb 19, 2012 10:50 PM
Posted in group: ruby-bundler

I apologize if this has been asked before. I did some searching but
didn't really see any ideas on this.

My conundrum: what do you do when you have a team of devs and some
(but not all) of the devs want to use some extra gems, or custom gems?

I know the common answer I've seen is to create a group in the Gemfile
and list those extra/custom gems. But (a) you then have to run bundler
an explicitly exclude that group, and more importantly, (b) those gems
are now in Gemfile and Gemfile.lock and thus part of the committed
source code, which may not be desirable.

What Id love is if there could be an additional Gemfile.local (and
corresponding Gemfile.lock.local) where devs could keep whatever gems
there they want, but that aren't part of the project. They could even
be ignored by the SCM, much like database.yml, for example.

Case in point: what if everyone else just does "rails s" to launch
their local rails stack, but I really want to do "rails s thin". I
don't want to force others to use thin, nor do I want to "taint" the
Gemfile with the thin gem. What I really want is to be able to have
that only for me, and not in the project. Thus the "Gemfile.local"

Is there some other way to do this? Thoughts? Ideas?

I feel like an older version of Bundler let this work... i.e. if I had
a gemset via RVM that included thin, it was in the load path, even if
Bundler didn't build it or know about it cause it wasn't in the
Gemfile. But now, it seems that Bundler cleans the path and _only_
uses gems from the Gemfile.

I welcome any thoughts on this. Thanks!