Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

An extensible API for plugin management

#1436

As discussed in ticket #1284 Add Hg (Mercurial) support to script/plugin, an API for managing plugins would add some benefits to users of alternative version control systems, as it would allow gems and plugins to add-in support for such a system.

My initial idea for the design would be something akin to:

  • PluginManager
    • GitPluginManager
    • HTTPPluginManager
    • BazaarPluginManager
    • SubversionPluginManager
    • ...

A plugin manager should at least respond to #install, taking a single Plugin instance as argument, as well as an options hash.

It can also define #update and #remove, which may come in handy when installing plugins using Git submodules or Subversion externals.

I'll begin working on this as soon as I find the time for it -- my biggest concern is how to test all this, but I guess I'll get some clues from the implementation of the Generators API, which is my main source of inspiration.

Any thoughts or ideas would be greatly appreciated.

Reported by Daniel Schierbeck · November 22nd, 2008 @ 05:22 PM

State: stale
Milestone: 3.x
Assigned to: Jeremy Kemper Jeremy Kemper
Importance: none

Activity

  1. Daniel Schierbeck
    Daniel Schierbeck
    • Assigned user set to Jeremy Kemper

    As per this comment by David.

    November 22nd, 2008 @ 05:23 PM

  2. Daniel Schierbeck
    Daniel Schierbeck

    I've pushed the first bits of code to a GitHub branch. It currently supports installing through Git checkout and Git submodule.

    November 22nd, 2008 @ 07:05 PM

  3. Chad Woolley
    Chad Woolley

    This sounds like a great idea. Just yesterday I was getting annoyed about how hard plugin dependencies are to manage compared to gems. Dependency hell....

    Please provide some mechanism to specify versions or branches of plugins - either a Git revision number, or a branch.

    The hook approach for #update and #remove sounds great as well. Ideally, this facility would be completely decoupled from the rest of Rails (especially the config/initialization/environment), so it could be done as part of app startup from config/preinitializer.rb. That way, your piston/braid/giternal config could be leveraged to automatically bring the plugin up to the version you want.

    November 22nd, 2008 @ 08:53 PM

  4. Bounga
    Bounga

    Chad: That's what we thought about, all SCM plugins should be loaded automatically and system-wide without having to tweak the config files.

    November 24th, 2008 @ 09:20 AM

  5. Bounga
    Bounga

    Chad: and yes, revision, branch and all these things will be handle by the manager.

    November 24th, 2008 @ 09:22 AM

  6. Pratik
    Pratik

    NOTE : Update Rails::TemplateRunner to make use of script/plugin features. Git submodules for an example

    December 5th, 2008 @ 11:17 PM

  7. Ryan Bigg
    Ryan Bigg

    Is this still valid?

    April 10th, 2010 @ 08:34 AM

  8. Jeremy Kemper
    Jeremy Kemper
    • Milestone changed from 2.x to 3.x

    May 4th, 2010 @ 06:48 PM

  9. Ryan Bigg
    Ryan Bigg
    • State changed from new to stale
    • Importance changed from to

    No updates since my ping in April, closing.

    October 11th, 2010 @ 04:50 AM

  10. Ryan Bigg
    Ryan Bigg

    Just a little update too: I would say this is handled fairly enough by Bundler now by using the git comment in Gemfile. If you want to use a specific version of a plugin, it's best practice if it was a gem.

    October 11th, 2010 @ 04:51 AM