This project is archived and is in readonly mode.

#2728 ✓invalid
Nathaniel Bibler

[PATCH] Rails rake ignoring bundled frozen gem tasks

Reported by Nathaniel Bibler | May 27th, 2009 @ 02:53 PM | in 3.x

A long while back, Rails added the ability for plugin authors to include Rake tasks in their plugins by including a tasks directory. Any *.rake files included in that directory would be automatically loaded by Rails via tasks/rails in Rakefile.

Frozen gems should be able to take advantage of the same feature. It is a trivial update to the core (+1 LOC), slightly broadening a feature that already exists. This "problem" was mentioned 3 years ago in this ticket, but at the time was marked as a duplicate against a ticket which didn't address the issue.

Currently - since this is not included in Rails by default - it appears to "break" several popular plugin/gems, specifically Tobi's Delayed Job and Thoughtbot's Paperclip, by not having the pre-bundled tasks readily available once frozen.

Attached is the +1 LOC patch to enable frozen gem tasks.

Comments and changes to this ticket

  • Nathaniel Bibler

    Nathaniel Bibler May 27th, 2009 @ 03:24 PM

    • Title changed from “[Patch] Rails rake ignoring bundled frozen gem tasks” to “[PATCH] Rails rake ignoring bundled frozen gem tasks”

    Added custom Rake task loading test to Railties specifically for this patch. Patch file updated.

  • Nathaniel Bibler

    Nathaniel Bibler May 27th, 2009 @ 03:33 PM

    Tests were added at the request of Manfred Stienstra (manfred-s) in #rails-contrib.

    A custom task_test.rb file was added since the tests require loading rake and friends. I didn't want to dirty any of the existing non-rake-specific test files in railties.

    At some point, the task_test.rb should probably be extended to ensure that both vendor/plugins/**/tasks/**/*.rake and lib/tasks/*.rake are being properly loaded. But that didn't seem appropriate for this specific patch.

  • Matt Jones

    Matt Jones May 31st, 2009 @ 03:26 AM

    This is still under discussion on ticket #59 - the issue is more complicated than just a line of code. For instance, your patch means that gems in vendor/gems behave differently than gems in the system repository.

  • Nathaniel Bibler

    Nathaniel Bibler May 31st, 2009 @ 03:38 AM

    Hey Matt. You are correct, Tyler Hunt and I were talking about that a few days ago when I had him read through it.

    I actually created something that could work for installed - but not frozen - gems. However, it required loading the Rails environment for every Rake task, which certainly isn't a good thing to do (it uses Rails.configuration to pull the dependent gems and then reading the gem specs for the locally-installed directory and scanning for a tasks subdirectory).

    Honestly, I don't see it as a down side to only support frozen gems. Doing so does not take away current functionality, but rather enhances it. Certainly it's not a 100% solution, but on a effort-to-reward ratio, I think it significantly outweighs any solutions I could come up with for supporting it all.

  • Matt Jones

    Matt Jones May 31st, 2009 @ 03:53 AM

    As previously noted, the issue is that this behavior is new. Gems that don't expect to have their rake tasks dropped into the app's namespace may have picked names for their tasks that break other things ('test', for instance...)

    The near-term workaround is probably to do a require on the tasks from the gem - check out Ryan Bates's comment on #59 for more detail.

  • Jeremy Kemper

    Jeremy Kemper May 4th, 2010 @ 06:48 PM

    • Milestone changed from 2.x to 3.x
  • Rohit Arondekar

    Rohit Arondekar October 9th, 2010 @ 04:14 AM

    • State changed from “new” to “invalid”
    • Importance changed from “” to “”

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=""></a>