Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Way for specifying personal dev tools #2190

MarcWeber opened this Issue · 8 comments

5 participants

Marc Weber Leslie Viljoen Musannif Zahir Christopher Krailo Xavier Shay
Marc Weber

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 ""
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 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.

Leslie Viljoen

Thanks for this, I'm trying it out.

Leslie Viljoen

One problem with this is the difficulty in updating the public Gemfile.lock

Marc Weber

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.

Musannif Zahir

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?

Marc Weber

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.

Leslie Viljoen

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.

Christopher Krailo

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.

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.

Xavier Shay

Moved to bundler-features.

Xavier Shay xaviershay closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.