Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Way for specifying personal dev tools #2190

Closed
MarcWeber opened this Issue Nov 28, 2012 · 8 comments

Comments

Projects
None yet
5 participants

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.

lesliev commented Dec 13, 2012

Thanks for this, I'm trying it out.

lesliev commented Dec 17, 2012

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.

mzahir commented Jun 30, 2013

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.

lesliev commented Jun 30, 2013

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.

Member

ckrailo commented Jul 3, 2013

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.

Contributor

xaviershay commented Aug 20, 2013

Moved to bundler-features.

@xaviershay xaviershay closed this Aug 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment