Add the ability to add a secondary Gemfile (that can be global to the system for example)

[carllerche]

• the information in the secondary gemfile are lower priority
• Do not include the secondary gemfile in a lock
• the secondary Gemfile should not effect the resolve of the main Gemfile. It is a superset on top of it.
• Add the ability to specify this secondary gemfile with an ENV variable, .bundle/config, or flag.

[qmx]

That solves my concern with OS-specific-gems, like autotest-growl

[dolzenko]

+1 Meanwhile, what's the best workaround to the issue? My .irbrc requires http://github.com/oggy/looksee from gem, by accident I discovered that the following lets me break out of the Bundler jail (at least in development mode):

Gem.refresh
Gem.activate('looksee')

so probably I can just detect bundler running and use this hack to require needed gem?

[indirect]

I just put wirble.rb into ~/.irb/wirble.rb, and I require it from there in my .irbrc file.

[dolzenko]

Right, but you can't just vendor a gem into your ~/.irb folder if it has native extensions (like the looksee gem does). Well maybe you can but this is going to be a mess, since you'd have to support compilation, different Ruby versions etc.

[indirect]

Bundler is (obviously, I hope) not going to support putting things into your ~/.irb folder. You could do it as a workaround, though, even if the gem has native extensions. Just copy the files from the installed gem's folder.

[dolzenko]

That doesn't scale when you have multiple extension incompatible Ruby versions (think rvm with 1.8 and 1.9) :)

[indirect]

If you're using rvm, I don't understand how this is a problem at all. You can just bundle the gem straight out of your rvm system gems. Just add it to the Gemfile, and it will use the one you already have installed automatically, and running bundle install will install it to your rvm system gems.

[dolzenko]

That is a problem because you will be adding developer specific gem to the project wide Gemfile, which is

1. repetitive
2. Gemfile may even not be owned by you

that's basically why I believe this feature request was submitted.

[indirect]

I completely agree, and that is why we have committed to adding this feature to bundler. You asked about workarounds, however, and that's what I have been talking about this entire time.

[rickmark]

I'd suggest Gemfile.local for the file...

It can be hacked together with some require 'Gemfile.lock' if File.exists?... until the implementation is ready

[Dykam]

I would like this feature, and the way penwellr suggested seems good. Then you can just ignore it in the vcs ignore settings.

[tomkurt]

Easy solution is just to require with full paths require "/usr/local/lib/ruby/gems/1.8/gems/wirble-0.1.3/lib/wirble"

if the gem does relative requires like lookse use Dir.chdir("path') do ...;end

Dir.chdir("/usr/local/lib/ruby/gems/1.8/gems/looksee-0.2.1/lib") do require "looksee/shortcuts" end

[dolzenko]

I just needed to include "ruby-debug" gem and since it depends on a couple of another gems that approach won't work. (what I had to do is to manually add all the required load paths with $LOAD_PATH.unshift but that's really awkward)

[pwnall]

Would like to add my use case to the thread: I'd like this feature so that my Rails deployment software can add the application server gem (thin / unicorn) to bundler's list of gems without messing with the Gemfile.

Right now, heroku asks developers to include "gem 'unicorn'" in their gem files. Ideally, the application's source code shouldn't be modified to reflect implementation details in the deployment environment.

[maxim]

+1, can't use irb-enhancing gems without polluting everyone's Gemfile, or creating mess with ugly workarounds.

[ticktricktrack]

+1, We're developing on OSX and Windows. We can either load additional Gemfiles OR put Gemfile.lock in our git repo. Both together would be nice.

[mynameisrufus]

I thought this would work:

https://gist.github.com/724422

But no because we need to commit the Gemfile.lock

I don't like the idea of changing the gems that the app 'actually' needs but for testing its seems like win!

[jtoy]

any progress updates on this?

[indirect]

No, not really. It's an extremely hard problem, and everyone who works on Bundler has dayjobs now. :\

[skojin]

my workaround https://gist.github.com/794915 add this method to .irbrc, allow include gems from rvm @global gemset, you should have bundler installed in this gemset

[rkh]

any updates on this?

@skojin that link is broken.

[skojin]

@rkh link works, copy/paste instead of click (should ends with 15)

[raggi]

module Bundler
  # Activate a gem from outside the Gemfile. Could be considered harmful.
  # Might be useful for .irbrc and friends. It's a slow activation, but
  # after activation, files from the activated gems will be available for
  # normal require.
  def self.activate_outside(*gems)
    # Bundler doesn't cripple this:
    Gem.source_index.refresh!
    # Or this:
    Gem.activate(*gems)
  ensure
    # Re-enable the bundler lockdown via bundlers #initialize hack
    Gem.send(:class_variable_set, :@@source_index, nil)
  end
end

[indirect]

Unfortunately, Gem.source_index is deprecated now, and is going to be removed. :(

[raggi]

I might recommend applying bundlers hacks to Gem.source_index singleton.

That would enable me to simply instance a new Gem::SourceIndex and even cache it, rather than the hack-back included above.

[raggi]

@indirect sure, i'll fix it when that goes and cripple_rubygems is updated.

[mschulkind]

If you just want to be able to require gems from the global gemset, here's an alternative that's working for me. Just stick this in your .irbrc :

# Add all gems in the global gemset to the $LOAD_PATH so they can be used even
# in places like 'rails console'.
if defined?(::Bundler)
  global_gemset = ENV['GEM_PATH'].split(':').grep(/ruby.*@global/).first
  if global_gemset
    all_global_gem_paths = Dir.glob("#{global_gemset}/gems/*")
    all_global_gem_paths.each do |p|
      gem_path = "#{p}/lib"
      $LOAD_PATH << gem_path
    end
  end
end

[phocke]

I tried all the solutions you proposed, but I still can't get over this issue

https://github.com/janlelis/irbtools/issues/12#issuecomment-1527391

any idea?

[kidpollo]

+1

[imajes]

+1 (for saving etc)

[salzig]

+1

[indirect]

Don't remove any gems from Gemfile.lock. That will stop bundler from working entirely.

[jpfuentes2]

+1

[ssoroka]

+1

[delynn]

+1

[justinwiley]

+1

[ghost]

+1

[thomsbg]

+1

[shaileshjain]

+1

[phocke]

Seems like an update:

https://gist.github.com/2063855

[datwright]

+1

[ConradIrwin]

I've posted a workaround for this issue when using Pry at https://github.com/ConradIrwin/pry-debundle (it uses hacks similar to the one posted by @raggi above, but updated for rubygems 1.8 — should be easy to adapt to irbtools if you want).

The basic approach is to keep everything locked down until the user is actually interactively working on their program; at which point the locks are removed and we allow them to include any gems they have installed. (that's the plan, the implementation might be buggy)

I could envisage this being less of a hack if there was a Bundler.relax! method which could be called by plugins, or the user themselves, when they want to enter interactive mode.

[wallace]

+1

[skalnik]

Yes, this would be super useful! :+1:

[reuben-sutton]

+1

[cdlm]

+1

[zaius]

Here's my method of requiring from outside the Gemfile. Feedback welcome. https://gist.github.com/2643079

[danielribeiro]

+1

[gerrywastaken]

+1

https://github.com/gerrywastaken/Gemfile.local

I ended up creating a Gemfile.local which loads the regular Gemfile, however for some strange reason I can't get the gemfile config to be written to or read from the .bundle/config file, so it's still only a partial resolution.

[danielbayerlein]

:+1: