This project is archived and is in readonly mode.
rake crashes on frozen gem with unfrozen dependencies of wrong version
Reported by Tim Connor | May 5th, 2009 @ 07:50 PM | in 2.x
There is still a "already activated version x.y" problem in the gem loading. If you have a frozen gem with unfrozen dependencies (for instance if the dependency has native extensions so can't be frozen) you can have a nightmare upgrade problem, where you cannot rake gems:install, because rake is broken by a gem loading problem.
If you bump up your frozen gem to a newer version that requires a newer dependency, everybody else on the team will have rake broken by that dependency mismatch, since you will have had to specify the dependency in your config.gems, otherwise nobody will have installed it, since the parent is frozen. And now the config.gems loading code will kill rake.
Comments and changes to this ticket
-
Tim Connor May 5th, 2009 @ 08:36 PM
It's not just frozen gems. If you have gruff installed, for instance, it will require rmagick. If you specify a newer version of rmagick (for whatever reason) in your config.gems then rake will die.
-
Tim Connor May 5th, 2009 @ 08:50 PM
The generalized problem is having a gem both as a dependency and specified on it's own will crash rake gems out, if you have an older version of the gem installed than specified on the config.gems line
-
Tim Connor May 5th, 2009 @ 08:53 PM
Whereas having an outdated dependency installed without specifying it in config.gems will not kill rake outright, but will crash rake gems at the point in it's listing where it hits the dependency.
-
Tim Connor May 6th, 2009 @ 07:05 PM
This at least fixes the worst of the problem - the fact that you can't even run rake gems to check on what is wrong, or rake gems:install to fix it. Rake can still be broken in other ways, by config.gems, but that is to be expected with complex dependencies. It's just a hassle when it can't be fixes by the tasks designed to do so.
-
Tim Connor May 6th, 2009 @ 09:07 PM
- Tag changed from “2-3-stable, dependencies, gems” to “2-3-stable, dependencies, gems, patch”
adding patch as preferred according to contrib guide
-
Matt Jones May 7th, 2009 @ 01:26 AM
- Assigned user set to “Matt Jones”
Can you offer more detail on the "crashing out" part? The error you're seeing ('already activated version x.y') shouldn't be coming from the load call, but from add_load_paths.
Note that some of this is not exactly fixable - the current behavior is to activate the frozen version if no requirement prohibits it. The only way around that might be to config.gem the correct version before the other gem that depends on it (in your example, put config.gem for rmagick's higher version before config.gem 'gruff').
-
Tim Connor May 7th, 2009 @ 05:59 AM
The problem isn't just with the load_paths, it's with the require from the dependency when the parent gets loaded.
"rake aborted! can't activate , already activated ..."
Here is a slightly simpler one (doesn't involve building rmagick) Start a new rails project. Add config.gem "mechanize" and install the latest version (0.9.2). Uninstall any version of nokogiri >= 1.2.1. Install nokogiri 1.2.0. Now rake will crash even when trying to run rake gems or rake gems:install.
Now freeze rails and apply my patch and rake gems works, which allows you to install/update any needed gem dependencies.
-
Tim Connor May 7th, 2009 @ 06:07 AM
As I later figured out, and commented about, it's not just a problem with frozen gems, but any dependencies when you have an older version of the gem. And it's easily fixed (at least as far as letting the rake gems tasks run, so that it can fix itself) by not trying to load the gems for the rake gems tasks.
-
Tim Connor May 7th, 2009 @ 06:17 AM
Yes this is a contrived example, but it definitely comes up in real situations, and frequently if you have enough complicated gem dependencies.
My tiny patch doesn't fix that rake gems:install won't pick up and install any dependencies, but it at least makes it work without crashing if you also have them specified separately (as may be the case with something like gruff and rmagick). This eases maintenance in that you can at least just manually list all of your gems and their dependencies and then rake gems:install will always work as expected.
-
Tim Connor May 7th, 2009 @ 06:18 AM
"any dependencies " sorry left out some words that might have made my point clearer.
-
Tim Connor May 7th, 2009 @ 06:19 AM
Damn, sorry formatting stripped that last post
"any (missing) dependencies (of already installed gems)"
-
David Dollar May 21st, 2009 @ 09:38 PM
Tim:
Your patch looks like it should work, but it is based on your app and not the Rails codebase.
Check out a version of the Rails codebase
git clone git://github.com/rails/rails.gitMake your changes, and follow the instructions in the contrib guide for creating a patch.
Even better would be to include two patches, one against master and the other against 2-3-stable.
If you need any help with this, feel free to shoot me an email at ddollar@gmail.com or find me as ddollar in #rails-contrib on Freenode.
-
-
Tim Connor May 21st, 2009 @ 10:59 PM
- no changes were found...
-
-
-
-
Repository June 6th, 2009 @ 07:05 AM
- State changed from “new” to “committed”
(from [6a3f8ae4075042f122d493208f18ecfb797b38ae]) Work around a gem dependency edge case that prevents Rails from booting..
If you have a frozen gem with unfrozen dependencies (for instance if the
dependency has native extensions so can't be frozen) you can have a
nightmare upgrade problem, where you cannot rake gems:install, because
rake is broken by a gem loading problem.If you bump up your frozen gem to a newer version that requires a newer
dependency, everybody else on the team will have rake broken by that
dependency mismatch, since you will have had to specify the dependency
in your config.gems, otherwise nobody will have installed it, since the
parent is frozen. And now the config.gems loading code will kill rake.[#2609 state:committed]
Signed-off-by: Jeremy Kemper jeremy@bitsweat.net
http://github.com/rails/rails/commit/6a3f8ae4075042f122d493208f18ec... -
Repository June 6th, 2009 @ 07:06 AM
(from [84a755b27e615da4a51b6e4c042491b6d807bcf8]) Work around a gem dependency edge case that prevents Rails from booting..
If you have a frozen gem with unfrozen dependencies (for instance if the
dependency has native extensions so can't be frozen) you can have a
nightmare upgrade problem, where you cannot rake gems:install, because
rake is broken by a gem loading problem.If you bump up your frozen gem to a newer version that requires a newer
dependency, everybody else on the team will have rake broken by that
dependency mismatch, since you will have had to specify the dependency
in your config.gems, otherwise nobody will have installed it, since the
parent is frozen. And now the config.gems loading code will kill rake.[#2609 state:committed]
Signed-off-by: Jeremy Kemper jeremy@bitsweat.net
http://github.com/rails/rails/commit/84a755b27e615da4a51b6e4c042491...
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
People watching this ticket
Matt Jones
Attachments
Tags
Referenced by
-
2266
rake gems broken for vendored gems which are unbuilt extensions
Actually, this is just a subset. rake is still way to eas...
-
2609
rake crashes on frozen gem with unfrozen dependencies of wrong version
[#2609 state:committed]
-
2609
rake crashes on frozen gem with unfrozen dependencies of wrong version
[#2609 state:committed]