Conflicts between gem versions in geminstaller.yml and listed gem dependencies in the gems themeselves
Reported by Brian Takita | December 10th, 2008 @ 08:40 AM
I think this has to do with geminstaller.yml invoking the gem method and requiring the gem in one shot. What should happen is geminstaller should invoke the gem method for all gems first, then do the requires.
can't activate activesupport (= 2.1.0, runtime), already
activated activesupport-2.2.2
/usr/local/lib/site_ruby/1.8/rubygems.rb:147:in activate':
can't activate activesupport (= 2.1.0, runtime), already activated
activesupport-2.2.2 (Gem::Exception)
from /usr/local/lib/site_ruby/1.8/rubygems.rb:163:in `activate'
from /usr/local/lib/site_ruby/1.8/rubygems.rb:162:in `each'
from /usr/local/lib/site_ruby/1.8/rubygems.rb:162:in `activate'
from /usr/local/lib/site_ruby/1.8/rubygems.rb:49:in `gem'
from /usr/lib/ruby/gems/1.8/gems/geminstaller-0.4.5/lib/geminstaller/autogem.rb:36:in `invoke_require_gem_command'
from /usr/lib/ruby/gems/1.8/gems/geminstaller-0.4.5/lib/geminstaller/autogem.rb:19:in `process_gem'
from /usr/lib/ruby/gems/1.8/gems/geminstaller-0.4.5/lib/geminstaller/autogem.rb:9:in `autogem'
from /usr/lib/ruby/gems/1.8/gems/geminstaller-0.4.5/lib/geminstaller/autogem.rb:8:in `each'
from /usr/lib/ruby/gems/1.8/gems/geminstaller-0.4.5/lib/geminstaller/autogem.rb:8:in `autogem'
from /usr/lib/ruby/gems/1.8/gems/geminstaller-0.4.5/lib/geminstaller/application.rb:45:in `autogem'
from /usr/lib/ruby/gems/1.8/gems/geminstaller-0.4.5/lib/geminstaller.rb:33:in `autogem'
from /home/pivotal/workspace/cookstr/vendor/plugins/pivotal_core_bundle/lib/geminstaller/geminstaller_boot.rb:42
from ./script/../config/../config/preinitializer.rb:1:in `require'
from ./script/../config/../config/preinitializer.rb:1
from ./script/../config/boot.rb:29:in `load'
from ./script/../config/boot.rb:29:in `preinitialize'
from ./script/../config/boot.rb:10:in `boot!'
from ./script/../config/boot.rb:109
from script/server:2:in `require'
from script/server:2
Comments and changes to this ticket
-
Brian Takita December 10th, 2008 @ 09:14 AM
Never mind, thats what geminstaller does.
It looks like Gem.activate causes an error if the gem is activated again with a different version. This is true even when the versions are >= different versions.
-
Chad Woolley December 10th, 2008 @ 09:55 AM
- State changed from “new” to “invalid”
Yes, you can only activate exactly one version of a given gem at a time. You can't activate two different versions.
-
Brian Takita December 10th, 2008 @ 10:55 AM
However, I would expect the following to work:
rails >= 1.5 rails >= 2.0
-
Chad Woolley December 10th, 2008 @ 11:06 AM
Yes, but if another gem behaves badly and specifies explicit dependencies when it should not, you can still get these problems.
See these tickets for an example:
http://thewoolleyweb.lighthousea...
http://sod.lighthouseapp.com/pro...
Furthermore, there are actually valid situations where you might be in a catch-22 situation. I discussed this with Yehuda Katz, who has similar issues on Merb. RubyGems really needs a way to say - hey, I really need to override this gems dependency specification - trust me, it's ok... Unfortuately, someone needs to write that patch ;)
-
Jeff Whitmire January 23rd, 2009 @ 12:10 PM
I'm running into this situation yet again because I've got multiple projects using geminstaller, but I need to be able to run different versions of the gems on each project for the moment. Is there any way to to prevent the newest version of the gem from being autoloaded? It's really a pain to have to uninstall the latest versions of the gems in order to work on the project that requires the older version.
I can get around this in merb now with the new bundling system, but I can't find a way to do it in rails. do I have to vendor all my gems to make this work?
-
Chad Woolley January 23rd, 2009 @ 12:17 PM
@Jeff,
Is this for a top level gem (listed in geminstaller.yml) or a dependency of one of the top level gems (not listed in geminstaller.yml)?
If your problem is for a top level gem explicitly listed in geminstaller.yml, you can simply specify the version using '=' instead of '>=' (or the default version of >= 0 if you don't specify a version at all).
If your problem is for a dependent gem (not listed in geminstaller.yml), please provide more info on the exact situation. It is probably an issue with dependencies/versions in one of the gems' specs (which can still be worked around, but depends on the situation).
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
GemInstaller
http://geminstaller.rubyforge.org
Brian Takita
Chad Woolley