# Will engines be around in Rails 2.3? **URL:** \ **Category:** Engines\ **Created:** [February 19, 2009, 8:06pm UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798 "2009-02-19T20:06:04Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 19, 2009, 8:06pm UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/1 "2009-02-19T20:06:04Z")
I know they are adding a lot to the core of rails, but what about the rest? Will the Engines plugin live on to provide the missing pieces? ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 19, 2009, 10:58pm UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/2 "2009-02-19T22:58:36Z")
On 19 Feb 2009, at 19:05, Trevor Rowe wrote: > I know they are adding a lot to the core of rails, but what about > the rest? Will the Engines plugin live on to provide the missing > pieces? It’s my hope that we’ll fold almost all of the significant features of the engines plugin into Rails itself. Those features are migrations and public asset copying. Samuel W. pointed out an issue with the current migration strategy (see the Lighthouse for more info) that I’m keen to resolve in whatever strategy Rails adopts. My current thinking is that the schema\_migrations table should have an extra column - ‘source’ - that would solve this issue. David remains to be convinced, but I hope to show that it relatively simple. Public asset copying shouldn’t be very difficult to port. The slight hurdle is whether or not to bring the engine asset helper extensions across (i.e. adding the :plugin option to stylesheet\_link\_tag, etc), or whether or not assets should be copied into the main folder itself so the default helpers work. I’m tending towards the latter, as it will be easier to convince ‘core’. The only feature that I am not planning on ‘campaigning’ for is the code-mixing. This value this was originally intended to bring was to seamlessly layer plugins on top of each other, but I’m no longer convinced that this is a goal worth increasing the codebase of Rails for. There are other, simpler ways to override single methods in a Ruby class that I’d rather pursue. If for any reason migrations or assets don’t make it into core, I think we’ll have to fulfil them via an ‘engines’ plugin for 2.3, but I hope that won’t be necessary 🙂 Apologies for not being more transparent with this - I hope it makes sense. Let me know what you think, James ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 19, 2009, 11:21pm UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/3 "2009-02-19T23:21:29Z")
* * * Engine-Users mailing list removed\_email\_address@domain.invalid [http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org](http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org) ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 20, 2009, 11:28am UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/4 "2009-02-20T11:28:04Z")
On 19.02.2009, at 22:58, James A. wrote: > It’s my hope that we’ll fold almost all of the significant features > of the engines plugin into Rails itself. Those features are > migrations and public asset copying. > > Samuel W. pointed out an issue with the current migration > strategy (see the Lighthouse for more info) that I’m keen to resolve > in whatever strategy Rails adopts. My current thinking is that the > schema\_migrations table should have an extra column - ‘source’ - > that would solve this issue. David remains to be convinced, but I > hope to show that it relatively simple. Hmm, I can’t seem to find that Lighthouse ticket. What’d be wrong with just copying all the migrations from plugins to the main migration directory? With timestamped migrations that should just work or shouldn’t it? > Public asset copying shouldn’t be very difficult to port. The slight > hurdle is whether or not to bring the engine asset helper extensions > across (i.e. adding the :plugin option to stylesheet\_link\_tag, etc), > or whether or not assets should be copied into the main folder > itself so the default helpers work. I’m tending towards the latter, > as it will be easier to convince ‘core’. They should be copied IMO. Although I also prefer a more explicit approach here like just having a rake task that copies all the assets up to public. Would also be nice to have a task for syncing assets “back” to their respective plugin directories. When the logic is placed in some accessible place (like Rails::Plugin.copy\_assets) it would be trivial to hook that up to happen per request in dev mode, too. > The only feature that I am not planning on ‘campaigning’ for is the > code-mixing. This value this was originally intended to bring was to > seamlessly layer plugins on top of each other, but I’m no longer > convinced that this is a goal worth increasing the codebase of Rails > for. There are other, simpler ways to override single methods in a > Ruby class that I’d rather pursue. Could you expand on this a little bit? 🙂 The use case I have is that people want to extend “engine” stuff from their app/ directory. So when we ship a, e.g., UserHelper in a plugin and they try to overwrite/extend that in app/helpers/user\_helper the original helper won’t be loaded anymore. So they have to pick a different name or move it to a namespace. Another point I found missing is that Rails does not currently keep track of its plugins. Of course it’s trivial to add a custom PluginLoader that takes care of that. Maybe a future Engines plugin could rather provide a collection of “missing” Engine features that people can explicitely opt into. Like “ok, I want magic code mixing, but I’m happy with the migrations rake task” Anyway. Rails 2.3.0 still has a few bugs open regarding the Engines implementation. But I’m already totally happy with this stuff now in core. I really love that. 🙂 ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 20, 2009, 11:40am UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/5 "2009-02-20T11:40:56Z")
On 20/02/2009, at 10:32 PM, Antonio Tapiador del Dujo wrote: > > > I know they are adding a lot to the core of rails, but what about > > > in whatever strategy Rails adopts. My current thinking is that the > > > schema\_migrations table should have an extra column - ‘source’ - that > > > would solve this issue. David remains to be convinced, but I hope to > > > show that it relatively simple. BTW… I’ve already provided a simple patch to fix this issue, and it doesn’t require another column or anything, it just changes the order of the name and migration number. “1-myplugin”.to\_i == 1 \<== problem “myplugin-1”.to\_i == nil \<== ignored by standard rails. Kind regards, Samuel ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 20, 2009, 11:46am UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/6 "2009-02-20T11:46:14Z")
On 20/02/2009, at 11:27 PM, Sven F. wrote: > They should be copied IMO. Although I also prefer a more explicit > approach here like just having a rake task that copies all the > assets up to public. Would also be nice to have a task for syncing > assets “back” to their respective plugin directories. > > When the logic is placed in some accessible place (like > Rails::Plugin.copy\_assets) it would be trivial to hook that up to > happen per request in dev mode, too. This might not work completely when some plugins are gems which are likely read-only. Kind regards, Samuel ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 20, 2009, 10:33am UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/7 "2009-02-20T10:33:56Z")
Thank you James, it would be really impressive if all this functionality could be included in the core. Just a missing point, what about translations? Cheers. ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 20, 2009, 11:59am UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/8 "2009-02-20T11:59:48Z")
On 20 Feb 2009, at 10:39, Space Ship T. \ wrote: > > > > > it doesn’t require another column or anything, it just changes the > order of the name and migration number. > > “1-myplugin”.to\_i == 1 \<== problem > “myplugin-1”.to\_i == nil \<== ignored by standard rails. While this works now, it is a hack which relies on Rails behaviour that is not intentional. Adding a column is a more elegant and robust hack, and the more elegant the solution, the easier it will be to convince core to integrate it, and this become a hack no more. James ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 20, 2009, 11:51pm UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/9 "2009-02-20T23:51:02Z")
I’ve got several plugins in use across different applications I maintain that depend on Engines. (Thanks, James, I’m glad your work is now recognized in core.) Now that I’m migrating some of them to 2.3, I did find that I needed the migrations support and asset loading support to a certain degree. So I whipped up a plugin that handles these just two pieces of functionality. It’s on github, so fork away and hack on it as you wish: [GitHub - henrypoydar/engines-helper: A Rails 2.3+ plugin that provides database migrations and asset support for 'engine' type plugins](http://github.com/hpoydar/engines-helper) ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 20, 2009, 1:14pm UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/10 "2009-02-20T13:14:00Z")
On 20/02/2009, at 11:58 PM, James A. wrote: > While this works now, it is a hack which relies on Rails behaviour > that is not intentional. > > Adding a column is a more elegant and robust hack, and the more > elegant the solution, the easier it will be to convince core to > integrate it, and this become a hack no more. I can’t argue with that statement. Rails plugins & migrations generally seem pretty hacked up. Basically there are two characteristics of migrations: - They have some sort of order. - But, some migrations can be applied in parallel - i.e. they don’t depend on some other migration. (i.e. most add\_table migrations can be run in any order) Rails has introduced a lot of semantics that don’t actually appear to make much sense or even are that useful: Being able to migrate plugins backwards is almost completely useless - I’ve never used it. 50% of the code in migrations for me is a waste of time (it should just be generated automatically if required). In many cases migrating backwards is impossible anyway without data loss or corruption. Timestamped plugins is a complete mistake in my opinion. They overcomplicate the issue. Why not just allow plugins with the same order number. Generally, this suits the purpose required anyway i.e. 003\_add\_table\_a.rb 003\_add\_table\_b.rb Wasn’t the goal of timestamped migrations to allow multiple developers to create migrations that don’t clash? Is it the purpose of the “number” to be unique id, or provide order? In my mind, it makes far more sense for migrations to be ordered rather than indexed. In the above situation, we can apply “003” migrations in any sequence - “A” followed by “B” or “B” followed by “A”. In the case they were developed by separate developers, they can’t possibly rely on each other anyway… In the database, you’d have a migration table that listed the full name of the migration: Migrations: ^ name ^ | 003\_add\_table\_a | | 003\_add\_table\_b | The way to apply new migrations is just to list all migrations in sorted order, then only apply them if they are not already in the migrations db. Generally, I think for plugins, migrations can be simply copied across to the main migrations directory, and everything will work as expected with this kind of design. The current migrations code is completely over engineered and for 99% of users does not provide a significant benefit, and makes things that should be natural, more complex and non- intuitive. A lot of code could be reduced by simplifying migrations in this way. Kind regards, Samuel ---
**Author:** ![Trevor\_Rowe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d78d45/32.png) [@Trevor\_Rowe](https://www.ruby-forum.com/u/Trevor_Rowe)\ **Post date:** [February 21, 2009, 11:12am UTC](https://www.ruby-forum.com/t/will-engines-be-around-in-rails-2-3/160798/11 "2009-02-21T11:12:21Z")
On 20 Feb 2009, at 09:32, Antonio Tapiador del Dujo wrote: > Thank you James, it would be really impressive if all this > functionality could > be included in the core. > > Just a missing point, what about translations? Good point. I shouldn’t think this would be too hard. James