User engine problems with 1.1.4 + Test driven development?!

The following two posts (at the bottom) were posted to engine-
[email protected] and suggests further issues with 1.1.4

I’m forwarding it here for two reasons:

  1. Just a heads-up that 1.1.4 breaks engines that are customised.
    login/user_engine are probably almost as widely deployed as Typo, and
    if you’ve done any controller-level customisation, 1.1.4 appears to
    break it. The second message points out what Tim found to fix it as a
    work-around, and when I get time I’ll see if I can track down the
    issue and submit a patch via the usual channels.

  2. We all love test-driven development, but it would seem that the
    core team are not getting the opportunity to drink as much of the
    Koolaid as some of the rest of us. Don’t blame them - their workload
    elsewhere is ridiculously high, and the quality of the tests they’re
    doing to make sure rails itself stable is superb. However, as more
    and more engines/plugins/apps get distributed, is is worth testing
    how a rails release will work with them in the real world?

In other words, would it be worth assembling a test suite of the most
used apps and engines to test each Rails release with before
releasing? Typo was a problem last time around, and now we’re seeing
other issues pop-up - this is a problem that is going to get worse
unless it gets managed as the number of apps, plugins and other code
relying on rails increases by the day.

This way, when a rails release is about to be rolled up we can throw
a couple of thousand tests that aren’t internal to the framework at
it, so we can see if engines, or typo, or any other public-released
app, or some of the more popular plugins break on the build, and then
the core developers can use that knowledge to fix things before we
break them for ourselves? Or at least tell us “this is going to break
your app if you’re using these plugins”. Maybe even get the app/
plugin/engine developers notified automatically so they can start
patching before release?

Of course, nobody can test whether the app you’ve written yourself is
going to break with a new rails release other than you, but if we
make sure that the most popular code if working OK, we’re going to
dramatically reduce the amount of time DHH & co. have to spend
patching releases, IMHO.

Just an idea, and it seems more like what we should be doing instead
of shouting “freeze gems everybody” - it feels more Rails-y to be
making use of all that test code flying around out there.

Anybody? Or am I missing something?

If people think it’s a good idea, but don’t want to put resource into
it themselves, I’m sure I can work something up in the next week or so.

Begin forwarded message:

Will post again once I have more details.


Posted via http://www.ruby-forum.com/.


engine-users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-
engines.org

Begin forwarded message:

Hi,

The engines plugin has a test suite for checking its behaviour against
various Rails versions - details of this were recently posted to the
engine-users list. At the moment I’m unable to replicate the issues
described in the forwarded emails in the engines plugin tests; please
do contribute if you can augment the test application to produce
repeatable failing tests against Rails 1.1.4.

In general, I find the current release mechanisms are completely
appropriate. It’s just plain sensible development practice to minimise
the dependencies that your production-deployed application has,
including the version of Rails that your shared host has installed.
Freezing everything where possible will give you a stable environment
for your app to run in. It’s just a really good idea.

If folks want to help testing plugins against new versions of Rails
then that’s excellent, but it’s unlikely that Rails would ever (or
should ever) be patched to accomodate the implementation of a specific
plugin (especially one that gets freaky-naughty with some quite deep
parts of the framework like the engines plugin does). That’s the cart
leading the horse, and would ultimately stifle innovation. Which would
be teh suckz. Rails leads, plugins follow. C’est la vie.

Finally, there are some tentative plans afoot to make the
dissemination of plugin compatibility with particular versions of
Rails much easier. More on that as things progress behind the scenes.

In short:

  • YES, please do help us debug popular plugin code. Really, please do.
  • NO, don’t expect Rails to ever be patched to make it play nicer with
    an existing application/plugin at any point. Tie your application to a
    specific version of Rails until you can test it successfully against
    the newer one.
  • james

James,

I just tried upgrading to rails 1.1.4 and I’m also getting what
appears to be an engine failure. (I was hoping the previous report
was spurious.)

I use the ActiveRbac engine and a couple of the pages are not
working/displaying correctly now. One gives a Rails Application error
and the other renders the page but with a very plain/simple look and
feel.

Not sure what info to provide to help.

Greg

On 6/30/06, James A. [email protected] wrote:

appropriate. It’s just plain sensible development practice to minimise
leading the horse, and would ultimately stifle innovation. Which would
an existing application/plugin at any point. Tie your application to a

elsewhere is ridiculously high, and the quality of the tests they’re

Of course, nobody can test whether the app you’ve written yourself is

engine-users mailing list
Reply-To: [email protected]
controllers no longer seem to be ‘mixing in’ properly. Since I was
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-

  • J *
    ~

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Greg F.
The Norcross Group
Forensics for the 21st Century

On 30 Jun 2006, at 23:06, Greg F. wrote:

I just tried upgrading to rails 1.1.4 and I’m also getting what
appears to be an engine failure. (I was hoping the previous report
was spurious.)

I use the ActiveRbac engine and a couple of the pages are not
working/displaying correctly now. One gives a Rails Application error
and the other renders the page but with a very plain/simple look and
feel.

Not sure what info to provide to help.

OK, I suspect I’m going to be running into this over the weekend with
a load of engines-heavy apps I’m running here (it’s 23:35 local here,
and I’m not starting this right now), but I don’t run ActiveRBAC
anywhere. So, to make sure this is the same error as I am undoubtedly
about to run screaming into:

  • Clear log/development.log
  • Reproduce the error, move around the app, observe your results
  • Compress log/development.log and send it to me off-list
  • If you can, send me a copy of your app - everything under
    RAILS_ROOT, if poss. If not, it shouldn’t be urgent for me to re-
    produce.

I’ll see if I can work out what is going on here and identify whether
this is a patch needed for engines, or a patch needed for rails, and
send tasty code goodness to the relevant gods/demons/pizza-addicts. :slight_smile:


Paul R.

On 30 Jun 2006, at 23:06, Greg F. wrote:

Not sure what info to provide to help.

OK, I suspect I’m going to be running into this over the weekend with
a load of engines-heavy apps I’m running here (it’s 23:35 local here,
and I’m not starting this right now), but I don’t run ActiveRBAC
anywhere. So, to make sure this is the same error as I am undoubtedly
about to run screaming into:

  • Clear log/development.log
  • Reproduce the error, move around the app, observe your results
  • Compress log/development.log and send it to me off-list
  • If you can, send me a copy of your app - everything under
    RAILS_ROOT, if poss. If not, it shouldn’t be urgent for me to re-
    produce.

I’ll see if I can work out what is going on here and identify whether
this is a patch needed for engines, or a patch needed for rails, and
send tasty code goodness to the relevant gods/demons/pizza-addicts. :slight_smile:


Paul

(cross posted from the engines users list)

I’ve managed to replicate this error now (the reason why I couldn’t
replicate them in normal tests is because of the specific way that
controllers are loaded in a running application). A ticket has been
filed on the Rails Engines Collaboa site:
http://dev.rails-engines.org/tickets/180

I’ve committed a fix to the release branch - if you are having
problems, can you please try using this version, and provide feedback
as comments on the Ticket:

cd vendor/plugins
rm -fr engines
svn co http://svn.rails-engines.org/engines/branches/rb_1.1 engines

Cheers,

James

Your failure seems to come from ActiveRBAC, rather than the engines
plugin. Which version of that are you using? The problem seems to be
that it hasn’t correctly loaded the active_rbac/exceptions.rb file…

  • james

Test failed. Results on the trouble ticket.

On 7/1/06, James A. [email protected] wrote:

as comments on the Ticket:

On 30 Jun 2006, at 23:06, Greg F. wrote:

feel.

  • Reproduce the error, move around the app, observe your results
    Paul

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Greg F.
The Norcross Group
Forensics for the 21st Century

James,

I’m running 0.3.1 I believe. The CHANGELOG is date May 3, 06.

Restoring engines to my previous version allows my app to at least
start/run.

mongrel_rails start

** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment …
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no
restart).
** Rails signals registered. HUP => reload (without restart). It
might not work well.
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.

Thanks
Greg

On 7/2/06, James A. [email protected] wrote:

(cross posted from the engines users list)

  • Compress log/development.log and send it to me off-list

Rails mailing list
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Greg F.
The Norcross Group
Forensics for the 21st Century

Upgraded to ActiveRbac engine 0.3.2 and the latest svn trunk of engines.

Everything seems to work under Rails 1.0.4 now.

Greg

On 7/2/06, Greg F. [email protected] wrote:

** Loading any Rails specific GemPlugins

Your failure seems to come from ActiveRBAC, rather than the engines

cd vendor/plugins

James,
Not sure what info to provide to help.


Greg F.
The Norcross Group
Forensics for the 21st Century


Greg F.
The Norcross Group
Forensics for the 21st Century

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs