This project is archived and is in readonly mode.

#2684 ✓hold
Michael Schuerig

Modular Rails info

Reported by Michael Schuerig | May 20th, 2009 @ 08:51 PM | in 3.0.2

The attached patch (against the 2-3-stable branch) modularizes how the info displayed by /rails/info/properties and script/about is collected.

In addition to the built-in information, plugins can add rails/properties.rb files with property definitions. An application could do the same.

As a case in point where this functionality would be useful, consider a plugin like

that switches databases based on the currently checked out git branch. It's rather useful to be able to check that the intended database is really used.

Additionally, the patch adds JSON output to /rails/info/properties and YAML output to script/about.

Comments and changes to this ticket

  • Jeremy Kemper
  • Michael Schuerig
  • Michael Koziarski

    Michael Koziarski May 21st, 2009 @ 03:33 AM

    • Assigned user set to “Jeremy Kemper”

    Perhaps there should be some documentation on how to hook your stuff into this?

  • Michael Schuerig

    Michael Schuerig May 21st, 2009 @ 04:13 AM

    For a simple example see

    where I use it in a plugin to show the currently active database as one of the properties. (This is useful as the plugin switches databases according to git branch.)


    @@@ruby property name, value


    @@@ruby property name { ... }

    That's all there is to it, really. I'm careful not to litter the global environment, the properties files are instance_eval'ed each in a fresh (almost) BlankSlate object.

    More properties could be read from files in, say, lib/info/properties. But I haven't implemented that yet.

    If it is sensibly possible across deployment alternatives, I'd like to add a bit more of instrumentation, e.g. for changing parameters or clearing caches.

  • Michael Koziarski

    Michael Koziarski May 21st, 2009 @ 04:29 AM

    Looks good to me, but ideally this example style documentation would
    be built-in to rails so plugin authors have somewhere to look.

  • Michael Schuerig

    Michael Schuerig May 21st, 2009 @ 09:26 AM

    Oh, sorry, of course there is documentation missing. I didn't bother to adapt the tests, either. I only intended the patch as a proof of concept. Firstly, to see if and how well it works, second, to have a something concrete to talk about the idea.

    I'll add the obligatory details then, as soon as I get too it.

  • James Adam

    James Adam May 21st, 2009 @ 03:15 PM

    • Tag changed from railsinfoproperties, railties, scriptabout to plugin, plugins, railsinfoproperties, railties, scriptabout

    Is there any reason why you didn't use the existing about.yml data for your plugin properties?

    Years ago, when the engines plugin was, well, "more evil" than it is now, we hooked into the Info controller and added details from this file (name, version, etc).

    I'm not hugely invested in any particular approach, but rather than the implementation remains as simple as possible whilst still working.

  • James Adam

    James Adam May 21st, 2009 @ 03:34 PM

    Ah, I may have the wrong impression about what you were trying to achieve. I was thinking about just display information about a plugin, but on closer inspection it seems like you actually care about augmenting some set of application-specific information instead. Apologies for that.

    From a plugin perspective, I wonder if it might be simpler to provide plugins with an API, rather than a DSL, for manipulating this information? For example, in init.rb, they could do something like["Active Connection"] = ActiveRecord::Base.configurations[RAILS_ENV]['database']
    # or "Active Connection", ActiveRecord::Base.configurations[RAILS_ENV]['database']
    # or "Active Connection" do
    # etc...

    This seems slightly more elegant and code-ish to me than providing a DSL and another file for plugins to deal with.

  • Michael Schuerig

    Michael Schuerig May 21st, 2009 @ 03:54 PM

    James, as you noticed yourself, displaying static information was not my primary aim, although I see no reason why the information available from plugin#about (about.yml) should not be displayed.

    I was not trying to introduce a DSL, either. The property method was already there in the original code and that I'm using #instance_eval is only for the purpose of keeping the namespace clean.

    Regarding the API, I'm not opposed to it in general. For the single callback, I don't care whether it is Rails#property or #property.

    What I'd like to have is a mechanism that is simple to use and not tied to plugins. If an application programmer sees fit to expose a property, it should be easily possible, and it should happen in a well-defined place, e.g. lib/info/properties/xzy.rb.

    The latter is important, I think, to impose order on the architecture. As with configuration and initialization, there are (ought to be) things that can only be affected in specific places. If you want to find out about them, you know where to look.

    These properties files are intended as an interface definition. They are not meant to implement anything, only expose properties that are implemented elsewhere.

    Does that make sense?

  • Michael Schuerig

    Michael Schuerig May 21st, 2009 @ 04:49 PM

    I've attached a somewhat cleaned up version of the patch. It adds the feature that properties files at lib/info/properties/*.rb are loaded.

    The controller tests pass, the other unit tests still fail. I'm not sure if it's worthwhile to make them pass as I don't want to support the interface they're using anyway.

    I'd like to hear suggestions about what the interface should be.

    I'm still using Rails.configuration.loaded_plugins, instead of moving it to Rails.plugins. Right now, the usage as is, is more consistent with, e.g. Rails.configuration.middleware.

  • Michael Koziarski

    Michael Koziarski June 26th, 2009 @ 06:17 AM

    • Assigned user changed from “Jeremy Kemper” to “Yehuda Katz (wycats)”
    • Milestone cleared.

    Yehuda and Carl are currently refactoring the initializer. This should be something we do as part of that work.

    I'm guessing the implementation will be drastically different, but we should have the feature set available.

    Assigning to yehuda so it doesn't get lost.

  • Yehuda Katz (wycats)

    Yehuda Katz (wycats) June 26th, 2009 @ 08:25 PM

    • State changed from “new” to “verified”

    Absolutely. This should be added to the work we're doing now.

  • Yehuda Katz (wycats)

    Yehuda Katz (wycats) July 2nd, 2009 @ 07:47 PM

    • State changed from “verified” to “hold”

    I accidentally marked this verified ;)

    We'll get this in to the work we're doing now.

  • Jeremy Kemper

    Jeremy Kemper October 15th, 2010 @ 11:01 PM

    • Milestone set to 3.0.2
    • 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>