You can clone with
HTTPS or Subversion.
I know that bundler is meant to provide always the same environment and that my suggestion is going to break that property in some way. But I think its worth it.
The topic branch "https://github.com/MarcWeber/bundler/blob/marc/USER_GEMFILES/.topmsg"
makes bundler read USER_GEMFILES which you can set to ~/.gemfile or ./Gemfile.user.
Those contents will loaded after the project Gemfile. A different lockfile is being used so that you don't commit the your personal .lock file by accident.
This way you can add personal tools such as https://github.com/ivalkeen/guard-ctags-bundler to a custom file and make bundler use it conditionally. bundle exec bash seems to always support everything which got installed into the GEM_HOME path though.
I know that there are arguments for and against it which is why I'm creating an issue and not a pull request. I want to listen to other ways / opinions on this topic.
Thanks for this, I'm trying it out.
One problem with this is the difficulty in updating the public Gemfile.lock
No, its not. Unset the public var, and update the Gemfile.lock and everything should be back to normal, thus you can update the public Gemfile.lock. Bundler is broken cause it doesn't support transient dependencies. I don't have time to fix that right now :( That's much more important to me personally.
Hey fellas, just wondering where we are with this issue. If the approach by @MarcWeber isn't acceptable, what's the preferred way of adding USER_GEMFILES?
I don't do much ruby at the moment. I think a tool would be required doing both: check transitive dependencies and what bundler does. I haven't found it. What you do with this I don't care much at the moment. I'd like to merge bundler und gem - but don't have the time to do so. That would be the perfect solution for me.
I used some hacks for a while but in the end the best "solution" I've found is to put my personal gems in the main Gemfile and just require => false them so that they are installed (for everyone) but not loaded. Then I 'require' those gems in my own version of application.rb. This is the approach suggested by the bundler team and seems to cause the least annoyance.
Trying to understand this better...
Wouldn't this affect the project's Gemfile.lock? For example, if your project has a dependency like gem 'foo' that itself has a dependency like gem 'baz', '~> 1.0.0'... but then you put a dependency in your personal Gemfile like gem 'bar' that itself has a dependency like gem 'baz', '1.0.1'... other people on your team would resolve baz to version 1.5.0 while you'll resolve it to 1.0.1 and then write it into the project's lock file.
gem 'baz', '~> 1.0.0'
gem 'baz', '1.0.1'
Dependency conflicts also seem like they'd be more painful under your branch (at least as it currently is written)... I don't think I saw anything that would point out when conflicting gems were defined in the user's Gemfile versus the project's Gemfile.
Moved to bundler-features.