Forum: Rails Engines development Desert & Rails Engines

A0599814ceddc2e283792f4e47c57f5e?d=identicon&s=25 Brian Takita (Guest)
on 2008-06-23 08:39
(Received via mailing list)
Hello, Recently I made a blog post about the Desert framework.
http://pivots.pivotallabs.com/users/brian/blog/art...

In the comments, I learned that Desert is very similar to Rails
Engines. Both projects have independently evolved along a similar path
for the past 1 1/2 years.

Anyways, one difference is the multi-file loading on const_missing,
require, and load. Desert keeps a separate load path from Ruby. This
load path includes all Rails app & plugin directories.
When requiring a file, Desert will load all matches. If there was at
least one match, then the require is finished. If there was not a
match from the Desert load path, then Desert will delegate to Ruby's
standard require method implementation, which loads the first file
match.

This allows models to be included in the multi-file loading sequence.
Have you thought of such an approach? Do you think this would improve
Rails Engines? If yes, I'd be happy with submitting a patch.

Anyways, I think its possible that we may want to deprecate Desert in
favor of Rails Engines. I'm wondering if there are fundamental
differences between these two libraries, or if these projects are
trying to solve the same problems with the same approaches.

Thanks,
Brian
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 James Adam (Guest)
on 2008-06-23 18:57
(Received via mailing list)
Hi Brian,

Thanks for getting in touch - it's intruiging that we've not crossed
paths before :)

It certainly seems like we share a lot of common goals. Keeping a
separate load path for the multi-file-loading (code-mixing in engines
parlance) sounds like a pretty good solution. I'd definitely be
interested in a patch to that effect.

The one feature you highlight in your blog post that stand out to me
as something engines has avoided is plugin dependencies. I think I'd
probably continue to steer clear of that (particularly with the
continuing trend towards gemified plugins), unless a really
compelling, genuine example can be presented. Is this something you
have used in anger?

What do you think?

James
A0599814ceddc2e283792f4e47c57f5e?d=identicon&s=25 Brian Takita (Guest)
on 2008-06-25 09:35
(Received via mailing list)
On Mon, Jun 23, 2008 at 9:56 AM, James Adam <james.adam@gmail.com>
wrote:
> Hi Brian,
>
> Thanks for getting in touch - it's intruiging that we've not crossed
> paths before :)
Yes it is. I've havn't been on a project using Rails Engines for quite a
while.
> compelling, genuine example can be presented. Is this something you
> have used in anger?
No anger here. Plugin dependencies has been a part of Desert for a
quite a while now (> 1 year).
The plugin dependencies feature have been working very well in the
case of Socialitis (Pivotal's social network platform). We have a
sizable number of plugins (~ 10) that have dependencies on each other.
These plugins also have dependencies on third party plugins.
The nice thing about plugin dependencies is it also defines the proper
load path order. In Desert, when require_plugin is called, it simply
loads the parent plugin before the child plugin finishes loading.

At this time, I'm not sure if we are ready to take the plunge toward
gemified plugins, but its certainly worth checking out. I think we
opted not to use gems because we make heavy use of svn externals and
piston to be up to date.
>
> What do you think?
>
> James
Thanks,
Brian
This topic is locked and can not be replied to.