Added support for Gemfile.local #3022

merged 2 commits into from Jun 18, 2014


None yet

4 participants


This is a second attempt at PR #3020 .
This PR changes msfenv.rb so that the framework can use a custom Gemfile. Users can create a custom Gemfile.local file and then install it with bundle install --gemfile Gemfile.local

Users can create a Gemfile.local to include all groups in the framework's Gemfile along with custom groups.

msf_gemfile = File.join(File.dirname(__FILE__), 'Gemfile')
if File.readable?(msf_gemfile)

group :local do
  gem 'pry'
  gem 'pry-debugger'
  gem 'lab'

Changes to the Gemfile.local file should not change Gemfile or Gemfile.lock

See also:


You're computing ::File.join(gemfile_base, "Gemfile.local") twice, you should store it to a variable instead of computing twice (on 6 and 7).


Since the logic is now multiple statements and not all hidden behind a ||= (which will only run the right-hand expression if the left-hand expression is nil or undefined), you need to test if ENV['BUNDLE_GEMFILE'] is set before spending the time to do your new code.


  require 'pathname'

  msfenv_real_pathname =
  root = msfenv_real_pathname.parent.parent

  GEMFILE_EXTENSIONS.each do |extension|
    extension_pathname = root.join("Gemfile#{extension}")

    if extension_pathname.readable?
      ENV['BUNDLE_GEMFILE'] = extension_pathname.to_path

I prefer using Pathname when doing path manipulations because they're objects instead of calling functions from File on Strings.


@limhoff-r7 I had this typed up and ready to go before I saw your other comment in #3020. When I submitted this, I just now saw these comments. Github fail on my part.

Your solution looks much better. I will update the code in my forked branch (although, feel free to just commit to this PR if it is easier).

Do you think requiring pathname at this point will mess anything else in the framework up? I was trying to make the change as minimal as possible. Pathname is more eloquent.


'pathname' is part of the standard library; it's just not defined by default, so requiring it won't cause any issue.


Makes sense. Thanks. I will make the changes, and test on my side.


One more thought: Before merging this PR to master do you want me to update the code around line 190 in msfupdate to let msfupdate run the bundle install for the Gemfile.local file if it exists? Should that be left entirely to the user since Gemfile.local is intended to be custom, or does msfupdate support of Gemfile.local seem helpful?


Github usage tips:

If you click on the line number on a file's page it will give you an anchor link to that line. For example, I went to and clicked 190 to get, which I put into your comment since that's what you intended.

If you click and then hold shift and click a different line you can get a range. So, go to and click 187, then Shift-click 191 and get

Finally, these links are all impermanent because they're tied to whatever is current on master, so you can convert to a perma-link that uses the commit hash by typing 'y', which gets

The github keyboard shortcuts are accessible from any page by typing ? when you have no selection.


I do think handling Gemfile.local in msfupdate is an obvious extension to this PR and makes usage of Gemfile.local easier although I'm not sure about the user population that uses msfupdate and wants a Gemfile.local since I would consider Gemfile.local usage more advanced and those users might like using git command directly because they're switching between their own branches.


@limhoff-r7 Thank you for the Github tips. I did a quick search in the markdown documentation under the links section but didn't see anything, so I just made the post as it was. Thanks for updating the post and letting me know.

As for msfupdate - I think you are correct in saying that most everyone who would use a Gemfile.local will be using git and bundle to update the framework in place of msfupdate. I just wanted to make sure it was brought up for consideration now, instead of trying to deal with it in another change later. Thanks for your feedback.


This PR shouldn't depend on updating msfupdate -- in fact, any change to msfupdate needs to be super isolated.

Where are we at on this, in particular? Good to go, @limhoff-r7 ? If so, feel free to land. If not, let's revive this PR, because dangit I want a Gemfile.local too.


I'm concerned that anyone using a Gemfile.local will miss updates whenever the mainline Gemfile changes.


Maybe that's just a documentation problem. If this lands we need something (maybe on the wiki, maybe in comments around this code, maybe both) that clearly outlines how to set up the example Gemfile.local to include all the groups from the main one.


@jlee-r7, do you think that a link to a Gist in the source comments would do the trick? Would something like this work?

Edit: I forgot to add the Perma-link to the Gist for @limhoff-r7 and posterity.


Is there anything I can do from my side to help this PR along?

@todb-r7 todb-r7 added library external misc and removed external labels May 30, 2014
@jlee-r7 jlee-r7 merged commit 4ac8e23 into rapid7:master Jun 18, 2014

1 check passed

Details default The Travis CI build passed
@jlee-r7 jlee-r7 pushed a commit that referenced this pull request Jun 18, 2014
@egypt egypt Land #3022, support Gemfile.local 5beb43d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment