-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Add the ability to add a secondary Gemfile (that can be global to the system for example) #183
Comments
That solves my concern with OS-specific-gems, like autotest-growl |
+1
so probably I can just detect bundler running and use this hack to require needed gem? |
I just put wirble.rb into |
Right, but you can't just vendor a gem into your |
Bundler is (obviously, I hope) not going to support putting things into your |
That doesn't scale when you have multiple extension incompatible Ruby versions (think |
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 |
That is a problem because you will be adding developer specific gem to the project wide
that's basically why I believe this feature request was submitted. |
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. |
I'd suggest It can be hacked together with some |
I would like this feature, and the way penwellr suggested seems good. Then you can just ignore it in the vcs ignore settings. |
Easy solution is just to require with full paths 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 |
I just needed to include "ruby-debug" gem and since it depends on a couple of another gems that approach won't work. |
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. |
+1, can't use irb-enhancing gems without polluting everyone's Gemfile, or creating mess with ugly workarounds. |
+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. |
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! |
any progress updates on this? |
No, not really. It's an extremely hard problem, and everyone who works on Bundler has dayjobs now. :\ |
my workaround https://gist.github.com/794915 |
any updates on this? @skojin that link is broken. |
@rkh link works, copy/paste instead of click (should ends with 15) |
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 |
Unfortunately, |
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. |
@indirect sure, i'll fix it when that goes and cripple_rubygems is updated. |
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 |
I tried all the solutions you proposed, but I still can't get over this issue janlelis/irbtools#12 (comment) any idea? |
+1 |
+1 (for saving etc) |
I understand that's because bundler would overwrite Gemfile.lock with dependencies defined in secondary Gemfile |
@simi I understand that issue. Who would want that in a production environment? Besides, the idea is the global Gemfile is to be secondary to the app's Gemfile, thus making sure that if any conflicts between them arise, the primary one always wins. See then next two comments to understand what I was thinking about. |
+1 I run a command(which is result of a gem install from Gemfile), now to run this command I obviously need to point to to a Gemfile having that gem, right? But my this command tries to execute bundle pointing out to different Gemfile So need a way to tell bundler that now point out to this new Gemfile, and do your job |
+1 . This would be useful |
gems_requires 'path to other Gemfile from this one' |
+1. |
@brandondrew you can achieve this behaviour by installing your gems manually (or by creating own meta development gem with only dev. dependencies and no code) and little tricks in $HOME/.irbrc. The problem with secondary Gemfile is written here #183 (comment). |
@simi What if we documented some of these unsupported methods on a wiki page, caveat emptor? "Using gems in a development environment that are not in the gemfile" perhaps. Searching thru outdated gists is no fun. If Bundler team thinks this is a horrible idea, I trust their judgment. This ticket can just be closed out if there is no intention of working on it. Personally, I'm less concerned about this being officially supported by Bundler and more concerned with just getting things done. |
+1 I've read this whole thread, including #183 (comment), and I don't think that's actually a relevant point. Bundler already allows different sets of gems to be used in development environments than are used in production. That is exactly what groups are most commonly used for -- almost every Gemfile I've ever seen had at least a test group, and usually a development group, too. So, the new thing that Gemfile.local would allow is not "differences between development and production gem environments", but rather "differences between individual development environments," which I think most people would agree is far less scary. As somebody who works in a fairly heterogenous environment (both in terms of OS and preferred tooling), this feature would be very useful to me. |
+1 |
To better understand this proposal, how is bundler going to ensure dependencies are equal? Wouldn't a local Gemfile add more constraints that could end up in a different set of versions? |
You're totally right. I just ran into this problem as I tried to include a Gemfile.local via instance_eval within Gemfile. |
It could resolve dependencies as usual and only after that check if the local dependencies are met (plus any new ones). If they are not able to resolve properly considering the restrictions of the non local gems, there could be a warning or even an error. The local file wouldn't change the resolved versions of the gems. It's like a lower priority and it becomes your responsibility to fix it or drop it. |
I'd like to +1 this with another use case. Not all Rails apps have only one production deployment, or if they have multiple, those are totally identical. I maintain a CMS app that has 50+ production deployments, each for a different client, and thus each has its own "theme" views and assets. A few of these clients also have some additional custom functionality added to the CMS and site via a plugin in vendor/plugins. Some of those plugins need certain gems. I need to be able to install those gems for those specific sites and have them work. If the Gemfile could include secondary Gemfiles from those plugins that would solve a big problem for me. |
@centipedefarmer the ruby code to make this possible isn't actually very hard or complicated. that said, we don't want to make this an officially supported part of Bundler because it just explodes the ways that gemfiles and gems can go horribly wrong. Since Bundler is a small team of volunteers, and we don't have time to provide support for those complicated situations, it's up to people who need it to do it themselves. |
For anyone that ends up coming across this thread here what I've done, that seems to work but does still have one flaw:
The flaw in this is that since there are two Gemfile lock files, there isn't a way to ensure consistent versions between the two so something to be aware of. You can at least check for inconsistencies by not adding any additional gems to the Gemfile.local and comparing the two lock files, so it's not a dealbreaker for me. |
Thanks for reporting back! I'm glad you've found something that works for your needs. 👍 |
function bundle() {
bundle="$(type -P bundle)"
if [ -r "$BUNDLE_GEMFILE" ] && [ -r Gemfile ] &&
[ "$BUNDLE_GEMFILE" != Gemfile ] &&
[[ "$1" =~ ^(|install|update)$ ]]; then
BUNDLE_GEMFILE=Gemfile "$bundle" "$@"
cp Gemfile.lock "${BUNDLE_GEMFILE}.lock"
fi
"$bundle" "$@"
} |
@rlue Thanks for that. I created a slight modification to support using a custom gemfile in some projects on the same machine but not others. This just means using the value from function bundle() {
bundle="$(type -P bundle)"
gemfile=$BUNDLE_GEMFILE
if [ -z "$gemfile" ]; then
gemfile=`bundle config gemfile --parseable | sed -e 's/^gemfile=//'`
fi
if [ -r "$gemfile" ] && [ -r Gemfile ] &&
[ "$gemfile" != Gemfile ] &&
[[ "$1" =~ ^(|install|update)$ ]]; then
BUNDLE_GEMFILE=Gemfile "$bundle" "$@"
cp Gemfile.lock "${gemfile}.lock"
fi
"$bundle" "$@"
} And for ZSH: function bundle() {
gemfile=$BUNDLE_GEMFILE
if [ -z "$gemfile" ]; then
gemfile=$(command bundle config gemfile --parseable | sed -e 's/^gemfile=//')
fi
if [ -r "$gemfile" ] && [ -r Gemfile ] &&
[ "$gemfile" != Gemfile ] &&
[[ "$1" =~ ^(install|update)$ ]]; then
BUNDLE_GEMFILE=Gemfile command bundle "$@"
cp Gemfile.lock "${gemfile}.lock"
fi
command bundle "$@"
} |
@bmulholland I tried this, but faced a strange bug: When
successfully updates When it's set in (In fact, per issue #3081, you're not even supposed to be able to set |
@rlue That's odd - it's working for me. Bundler 1.16.1. Make sure your BUNDLE_GEMFILE environment variable is NOT set, since that will necessarily override the setting in |
Check and double-check. Wish I had the time to dig deeper.
Not according to this issue. |
I'm using this aliases in my
working good..
|
The text was updated successfully, but these errors were encountered: