This project is archived and is in readonly mode.

#2609 ✓committed
Tim Connor

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

    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

    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

    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

    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.

    http://github.com/timocratic/rai...

  • Tim Connor

    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

    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

    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

    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

    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

    Tim Connor May 7th, 2009 @ 06:18 AM

    "any dependencies " sorry left out some words that might have made my point clearer.

  • Tim Connor

    Tim Connor May 7th, 2009 @ 06:19 AM

    Damn, sorry formatting stripped that last post

    "any (missing) dependencies (of already installed gems)"

  • David Dollar

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

    Make 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
  • Tim Connor
  • Tim Connor

    Tim Connor May 21st, 2009 @ 11:00 PM

    Good to go, thanks David.

  • David Dollar
  • Tammer Saleh
  • Repository

    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

    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>