A second Gemfile and lock? I.e. Gemfile.local, Gemfile.lock.local?
3,494 views
Skip to first unread message
Danimal
Feb 20, 2012, 1:50:59 AM2/20/12
to ruby-bundler
Hi!
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"
idea.
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!
-Danimal
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"
idea.
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!
-Danimal
Alex Chaffee
Feb 20, 2012, 10:41:10 AM2/20/12
to ruby-b...@googlegroups.com
I think this is what you want:
bundle install --gemfile=local.gems
that will treat "local.gems" as if it were a Gemfile and lock them
inside "local.gems.lock".
You may also need to do "bundle exec --gemfile=local.gems rails s" (or
use an alias) to tie it together.
- A
P.S. I feel like reranting that "Gemfile" is a bizarre anachronism
since for the past 30 years filenames have had dot-extensions, and
rake and bundler and foreman should get with the program and stop with
the stupid make-inspired capitalized Foofile nonsense. It would make
conventions like the above ("foo.gems/foo.gems.lock") much more
intuitive.
> --
> You received this message because you are subscribed to the Google Groups "ruby-bundler" group.
> To post to this group, send email to ruby-b...@googlegroups.com.
> To unsubscribe from this group, send email to ruby-bundler...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ruby-bundler?hl=en.
>
--
Alex Chaffee - al...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch
Alex Chaffee
Feb 20, 2012, 10:45:22 AM2/20/12
to ruby-b...@googlegroups.com
On Mon, Feb 20, 2012 at 7:41 AM, Alex Chaffee <al...@stinky.com> wrote:
> I think this is what you want:
>
> bundle install --gemfile=local.gems
>
> that will treat "local.gems" as if it were a Gemfile and lock them
> inside "local.gems.lock".
>
> You may also need to do "bundle exec --gemfile=local.gems rails s" (or
> use an alias) to tie it together.
> I think this is what you want:
>
> bundle install --gemfile=local.gems
>
> that will treat "local.gems" as if it were a Gemfile and lock them
> inside "local.gems.lock".
>
> You may also need to do "bundle exec --gemfile=local.gems rails s" (or
> use an alias) to tie it together.
Looks like "bundle exec" doesn't have a --gemfile option, so try this instead:
BUNDLE_GEMFILE=local.gems bundle exec rails s
Ben Atkin
Feb 20, 2012, 11:25:37 AM2/20/12
to ruby-b...@googlegroups.com
Great idea, Alex! I think people got it backwards: instead of including local gems in the master Gemfile, the local Gemfile should include the gems from the master Gemfile. That way, the local Gemfile has a separate Gemfile.lock. I used eval which worked for my simple example.
When in local development mode, have BUNDLE_GEMFILE set to Gemfile.local. When making changes to Gemfile for collaboration, or checking that it works without your modifications, set BUNDLE_GEMFILE back to Gemfile (or to blank so it defaults).
If your .rvmrc isn't committed you can set the environment variable there. You could add this line below the "rvm use 1.9.3@gemset_name" part:
export BUNDLE_GEMFILE=Gemfile.local
Then you could copy Gemfile to Gemfile.local, add your gems there, and gitignore it. (I would have .rvmrc, Gemfile.local.lock, and Gemfile.lock in my .gitignore).
Danimal
Feb 20, 2012, 1:53:32 PM2/20/12
to ruby-bundler
Alex,
Thanks for the suggestion. This is very likely close to what I'm
looking for. However, it barfs on rake. I wonder if rake doesn't like
the BUNDLE_GEMFILE variable? I tried just taking our existing Gemfile
and changing it to Gemfile.dan then running your suggestion, just to
verify it works:
$ BUNDLE_GEMFILE=Gemfile.dan bundle install
Fetching source index for http://rubygems.org/
Installing rake (0.9.2.2)
ArgumentError: different prefix: "" and "/Users/drsharp/testcode/
vendor/bundle/bin"
An error occured while installing rake (0.9.2.2), and Bundler cannot
continue.
Make sure that `gem install rake -v '0.9.2.2'` succeeds before
bundling.
$ mv Gemfile.dan Gemfile
$ rm -rf vendor/bundle
$ bundle install
Fetching source index for http://rubygems.org/
Using rake (0.9.2.2)
Installing RubySunrise (0.2)
Installing multi_json (1.0.4)
Installing activesupport (3.1.3)
^C
However, even if this works, won't this just use the file specified by
BUNDLE_GEMFILE instead of the default "Gemfile"? It's still better
than nothing, but it means I'd need to keep a Gemfile.dan (or
"dan.gems" or whatever) and have it include the contents of Gemfile
plus whatever I want locally.
I still think the best solution would be to have a second gemfile spec
and a second gemfile.lock that can be gitignored and only includes the
extra gems I'd want locally.
BTW, I took a peek at your Wrong gem. Very very interesting! I think
we may dive into it on our latest project. Thanks!
-Danimal
On Feb 20, 8:45 am, Alex Chaffee <a...@stinky.com> wrote:
Thanks for the suggestion. This is very likely close to what I'm
looking for. However, it barfs on rake. I wonder if rake doesn't like
the BUNDLE_GEMFILE variable? I tried just taking our existing Gemfile
and changing it to Gemfile.dan then running your suggestion, just to
verify it works:
$ BUNDLE_GEMFILE=Gemfile.dan bundle install
Fetching source index for http://rubygems.org/
Installing rake (0.9.2.2)
ArgumentError: different prefix: "" and "/Users/drsharp/testcode/
vendor/bundle/bin"
An error occured while installing rake (0.9.2.2), and Bundler cannot
continue.
Make sure that `gem install rake -v '0.9.2.2'` succeeds before
bundling.
$ mv Gemfile.dan Gemfile
$ rm -rf vendor/bundle
$ bundle install
Fetching source index for http://rubygems.org/
Using rake (0.9.2.2)
Installing RubySunrise (0.2)
Installing multi_json (1.0.4)
Installing activesupport (3.1.3)
^C
However, even if this works, won't this just use the file specified by
BUNDLE_GEMFILE instead of the default "Gemfile"? It's still better
than nothing, but it means I'd need to keep a Gemfile.dan (or
"dan.gems" or whatever) and have it include the contents of Gemfile
plus whatever I want locally.
I still think the best solution would be to have a second gemfile spec
and a second gemfile.lock that can be gitignored and only includes the
extra gems I'd want locally.
BTW, I took a peek at your Wrong gem. Very very interesting! I think
we may dive into it on our latest project. Thanks!
-Danimal
On Feb 20, 8:45 am, Alex Chaffee <a...@stinky.com> wrote:
> On Mon, Feb 20, 2012 at 7:41 AM, Alex Chaffee <a...@stinky.com> wrote:
> > I think this is what you want:
>
> > bundle install --gemfile=local.gems
>
> > that will treat "local.gems" as if it were a Gemfile and lock them
> > inside "local.gems.lock".
>
> > You may also need to do "bundle exec --gemfile=local.gems rails s" (or
> > use an alias) to tie it together.
>
> Looks like "bundle exec" doesn't have a --gemfile option, so try this instead:
>
> BUNDLE_GEMFILE=local.gems bundle exec rails s
>
> --
> Alex Chaffee - a...@stinky.comhttp://alexchaffee.comhttp://twitter.com/alexch> > I think this is what you want:
>
> > bundle install --gemfile=local.gems
>
> > that will treat "local.gems" as if it were a Gemfile and lock them
> > inside "local.gems.lock".
>
> > You may also need to do "bundle exec --gemfile=local.gems rails s" (or
> > use an alias) to tie it together.
>
> Looks like "bundle exec" doesn't have a --gemfile option, so try this instead:
>
> BUNDLE_GEMFILE=local.gems bundle exec rails s
>
> --
Danimal
Feb 20, 2012, 2:12:04 PM2/20/12
to ruby-bundler
Alex,
My bad! I jumped the gun in posting. This appears to work... not sure
why it failed when I had BUNDLE_BIN_PATH in .bundle/config
But taking that out, it worked perfectly. I put a Gemfile.dan file,
which is our project Gemfile plus my local additions, in .bundle/
Gemfile.dan (since .bundle is already gitignored) and did the
following:
$ BUNDLE_GEMFILE=.bundle/Gemfile.dan bundle install
That correctly installed all the gems and created a .bundle/
Gemfile.dan.lock file
I can then launch my local server as:
$ BUNDLE_GEMFILE=.bundle/Gemfile.dan bundle exec rails s thin --
debugger
And that fires up with thin and ruby-debug19. And I haven't tainted
Gemfile or the git repo.
So this is 99% of what I was after and certainly good enough to
proceed. Thanks again, Alex!
(the 1% of "bummer" is simply that my Gemfile.dan won't auto-sync with
the project Gemfile. But that's a small price to pay for what I'm
after).
-Danimal
On Feb 20, 11:53 am, Danimal <fightonfightw...@gmail.com> wrote:
> Alex,
>
> Thanks for the suggestion. This is very likely close to what I'm
> looking for. However, it barfs on rake. I wonder if rake doesn't like
> the BUNDLE_GEMFILE variable? I tried just taking our existing Gemfile
> and changing it to Gemfile.dan then running your suggestion, just to
> verify it works:
>
> $ BUNDLE_GEMFILE=Gemfile.dan bundle install
> Fetching source index forhttp://rubygems.org/
My bad! I jumped the gun in posting. This appears to work... not sure
why it failed when I had BUNDLE_BIN_PATH in .bundle/config
But taking that out, it worked perfectly. I put a Gemfile.dan file,
which is our project Gemfile plus my local additions, in .bundle/
Gemfile.dan (since .bundle is already gitignored) and did the
following:
$ BUNDLE_GEMFILE=.bundle/Gemfile.dan bundle install
That correctly installed all the gems and created a .bundle/
Gemfile.dan.lock file
I can then launch my local server as:
$ BUNDLE_GEMFILE=.bundle/Gemfile.dan bundle exec rails s thin --
debugger
And that fires up with thin and ruby-debug19. And I haven't tainted
Gemfile or the git repo.
So this is 99% of what I was after and certainly good enough to
proceed. Thanks again, Alex!
(the 1% of "bummer" is simply that my Gemfile.dan won't auto-sync with
the project Gemfile. But that's a small price to pay for what I'm
after).
-Danimal
On Feb 20, 11:53 am, Danimal <fightonfightw...@gmail.com> wrote:
> Alex,
>
> Thanks for the suggestion. This is very likely close to what I'm
> looking for. However, it barfs on rake. I wonder if rake doesn't like
> the BUNDLE_GEMFILE variable? I tried just taking our existing Gemfile
> and changing it to Gemfile.dan then running your suggestion, just to
> verify it works:
>
> $ BUNDLE_GEMFILE=Gemfile.dan bundle install
> Installing rake (0.9.2.2)
>
> ArgumentError: different prefix: "" and "/Users/drsharp/testcode/
> vendor/bundle/bin"
> An error occured while installing rake (0.9.2.2), and Bundler cannot
> continue.
> Make sure that `gem install rake -v '0.9.2.2'` succeeds before
> bundling.
>
> $ mv Gemfile.dan Gemfile
> $ rm -rf vendor/bundle
> $ bundle install
> Fetching source index forhttp://rubygems.org/
>
> ArgumentError: different prefix: "" and "/Users/drsharp/testcode/
> vendor/bundle/bin"
> An error occured while installing rake (0.9.2.2), and Bundler cannot
> continue.
> Make sure that `gem install rake -v '0.9.2.2'` succeeds before
> bundling.
>
> $ mv Gemfile.dan Gemfile
> $ rm -rf vendor/bundle
> $ bundle install
Alex Chaffee
Feb 22, 2012, 12:36:19 AM2/22/12
to ruby-b...@googlegroups.com, ruby-b...@googlegroups.com
On Feb 20, 2012, at 8:25 AM, Ben Atkin <neb....@gmail.com> wrote:
> I used eval which worked for my simple example.
>
> https://github.com/benatkin/local-gemfile
Wouldn't 'load' work better than (or just as well as) eval?
load "#{File.dirname __FILE__}/Gemfile"
Otherwise I approve of your hack. Especially setting the environment var inside .rvmrc.
-A
Danimal
Feb 22, 2012, 1:14:43 AM2/22/12
to ruby-bundler
Ben, Alex,
Thank you both for your help. This is perfect!
Ben: you helped solve the last two remaining issues I had:
1) still being able to use "bundle exec" or "bundle install" put read
from the .local file if it's there
(your inclusion of the env variable in .rvmrc is genius!)
2) having the Gemfile.local always track and include any changes to
the main project Gemfile, so it doesn't need to be manually updated
when Gemfile changes. Perfect!
BTW, Alex: load didn't seem to work. It gives me this error:
Gemfile.local:2:in `load': cannot load such file -- source :rubygems
(LoadError)
Anyway, eval works, and I for one am happy. Problem solved!
Thanks, gents!
-Danimal
On Feb 21, 10:36 pm, Alex Chaffee <ale...@gmail.com> wrote:
Thank you both for your help. This is perfect!
Ben: you helped solve the last two remaining issues I had:
1) still being able to use "bundle exec" or "bundle install" put read
from the .local file if it's there
(your inclusion of the env variable in .rvmrc is genius!)
2) having the Gemfile.local always track and include any changes to
the main project Gemfile, so it doesn't need to be manually updated
when Gemfile changes. Perfect!
BTW, Alex: load didn't seem to work. It gives me this error:
Gemfile.local:2:in `load': cannot load such file -- source :rubygems
(LoadError)
Anyway, eval works, and I for one am happy. Problem solved!
Thanks, gents!
-Danimal
On Feb 21, 10:36 pm, Alex Chaffee <ale...@gmail.com> wrote:
Danimal
Feb 22, 2012, 1:23:37 AM2/22/12
to ruby-bundler
BTW, Ben:
Adding the export BUNDLE_GEMFILE=Gemfile.local to your .rvmrc does
mean that if you go to a different project and that doesn't have a
Gemfile.local, bundler will try to use it and give an error.
To fix, I simply added this line to other .rvmrc files for projects I
don't need the Gemfile.local file: (this is in place of the export
line):
unset BUNDLE_GEMFILE
I suppose you could just export it again but have it point to Gemfile,
but that seems redundant.
Anyway, all is well. Thanks again!
-Danimal
Adding the export BUNDLE_GEMFILE=Gemfile.local to your .rvmrc does
mean that if you go to a different project and that doesn't have a
Gemfile.local, bundler will try to use it and give an error.
To fix, I simply added this line to other .rvmrc files for projects I
don't need the Gemfile.local file: (this is in place of the export
line):
unset BUNDLE_GEMFILE
I suppose you could just export it again but have it point to Gemfile,
but that seems redundant.
Anyway, all is well. Thanks again!
-Danimal
Joshua Muheim
Nov 20, 2013, 2:52:30 AM11/20/13
to ruby-b...@googlegroups.com
Is there any way to do this without an .rvmrc file? We use .ruby-gemset and .ruby-version to specify our environment.
Dan Sharp
Nov 20, 2013, 10:14:33 PM11/20/13
to ruby-b...@googlegroups.com
Hi Joshua!
Actually, I have no idea if this is still possible with the new .ruby-gemset and .ruby-version that RVM (and rbenv) support. I stopped using this technique a while ago.
If you fiddle with it and find out if it works, I'd be curious to know.
Thanks,
-Danimal
--
You received this message because you are subscribed to a topic in the Google Groups "ruby-bundler" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ruby-bundler/5zVMtUSNSd0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ruby-bundler...@googlegroups.com.
Visit this group at http://groups.google.com/group/ruby-bundler.
For more options, visit https://groups.google.com/groups/opt_out.
Dan Sharp
Nov 21, 2013, 7:15:18 PM11/21/13
to ruby-b...@googlegroups.com
Joshua,
I just saw this article from Ruby Weekly: https://semaphoreapp.com/blog/2013/11/14/how-to-use-different-gemfiles-with-bundler.html
It's not quite what I was doing originally, but it is a good way to have different Gemfiles for different reasons.
-Danimal
Zubin Henner
Jan 15, 2014, 6:05:36 PM1/15/14
to ruby-b...@googlegroups.com
The suggestion to use BUNDLE_GEMFILE for maintaining two separate Gemfiles (one which loads the other) is a good one, but there is an inherent flaw:
Since the Gemfiles will generate (and use) separate lock files, there's no way to ensure consistent versions between the two lock files.
What is needed is a way for the extra Gemfile (eg local.gems) to also use the "parent" Gemfile.lock. Any ideas?
-Zubin
Reply all
Reply to author
Forward
0 new messages