Shouldn't "rails plugin new" create an Engine by default?

[Rodrigo Rosenfeld Rosas]

I've been creating several engines for Rails lately and I found that
having an engine class inherited from Rails::Engine is required if you
intend to bundle some Sprockets assets.

So, shouldn't the template for "rails plugin new" change so that "rails
plugin new some-example" would create something like:

lib/some-example.rb:

module SomeExample
class Engine < Rails::Engine
end
end

instead of an empty SomeExample module?

Maybe the "plugin new" could add some option like '--skip-engine' or
disable it automatically if "--skip-sprockets" is used.

Make sense?

Kind regards,
Rodrigo.

[Luís Ferreira]

It creates the lib/some-example/engine.rb file which is just as you described and then requires it in lib/some-example.rb. Shouldn't that be enough?

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
>

Cumprimentos,
Luís Ferreira

[Rodrigo Rosenfeld Rosas]

What version are you talking about? That doesn't happen on latest stable
3.2.5 here.

If that is already implemented in master, then great, I hope it to be
backported to 3.2.6 when it gets released...

Thanks,
Rodrigo.

[Luís Ferreira]

Yes. Just do "rails new plugin some_example --mountable".

You should also take a look at --full. ;)

On Jun 5, 2012, at 2:55 PM, Rodrigo Rosenfeld Rosas wrote:

> What version are you talking about? That doesn't happen on latest stable 3.2.5 here.
>
> If that is already implemented in master, then great, I hope it to be backported to 3.2.6 when it gets released...
>
> Thanks,
> Rodrigo.
>

> Em 05-06-2012 10:22, Luís Ferreira escreveu:
>> It creates the lib/some-example/engine.rb file which is just as you described and then requires it in lib/some-example.rb. Shouldn't that be enough?
>> On Jun 5, 2012, at 2:10 PM, Rodrigo Rosenfeld Rosas wrote:
>>
>>> I've been creating several engines for Rails lately and I found that having an engine class inherited from Rails::Engine is required if you intend to bundle some Sprockets assets.
>>>
>>> So, shouldn't the template for "rails plugin new" change so that "rails plugin new some-example" would create something like:
>>>
>>> lib/some-example.rb:
>>>
>>> module SomeExample
>>> class Engine< Rails::Engine
>>> end
>>> end
>>>
>>> instead of an empty SomeExample module?
>>>
>>> Maybe the "plugin new" could add some option like '--skip-engine' or disable it automatically if "--skip-sprockets" is used.
>>>
>>> Make sense?
>>>
>>> Kind regards,
>>> Rodrigo.
>>>
>

[Rodrigo Rosenfeld Rosas]

But my engines usually don't have any routes and even those who have are
not mountable ones.

I'm just asking for an engine to be created even for non-mountable
engines. I mean, as the default behavior of "rails plugin new plugin-name".

The "--full" will add integration tests which I also don't usually
include in my gems.

Usually I want to bundle some JS libraries as Rails gems for easier
reuse among my projects.

Basically, I'd like "rails plugin new plugin-name" to be equivalent of
"rails plugin new plugin-name --full -T".

Does it make sense?

Cheers,
Rodrigo.

Em 05-06-2012 13:17, Lu�s Ferreira escreveu:
> Yes. Just do "rails new plugin some_example --mountable".
>
> You should also take a look at --full. ;)
> On Jun 5, 2012, at 2:55 PM, Rodrigo Rosenfeld Rosas wrote:
>
>> What version are you talking about? That doesn't happen on latest stable 3.2.5 here.
>>
>> If that is already implemented in master, then great, I hope it to be backported to 3.2.6 when it gets released...
>>
>> Thanks,
>> Rodrigo.
>>

>> Em 05-06-2012 10:22, Lu�s Ferreira escreveu:
>>> It creates the lib/some-example/engine.rb file which is just as you described and then requires it in lib/some-example.rb. Shouldn't that be enough?
>>> On Jun 5, 2012, at 2:10 PM, Rodrigo Rosenfeld Rosas wrote:
>>>
>>>> I've been creating several engines for Rails lately and I found that having an engine class inherited from Rails::Engine is required if you intend to bundle some Sprockets assets.
>>>>
>>>> So, shouldn't the template for "rails plugin new" change so that "rails plugin new some-example" would create something like:
>>>>
>>>> lib/some-example.rb:
>>>>
>>>> module SomeExample
>>>> class Engine< Rails::Engine
>>>> end
>>>> end
>>>>
>>>> instead of an empty SomeExample module?
>>>>
>>>> Maybe the "plugin new" could add some option like '--skip-engine' or disable it automatically if "--skip-sprockets" is used.
>>>>
>>>> Make sense?
>>>>
>>>> Kind regards,
>>>> Rodrigo.
>>>>

>> Cumprimentos, Lu�s Ferreira

[Luiz Felipe Garcia Pereira]

It's a "rails plugin new" not "rails engine new".

It doesn't create a default Engine because not all plugins are engines.

If it's an engine and not just a plugin/railtie you would normally want the "--full" option.

If not, just create it. It's only 4 lines of code.

On Tue, Jun 5, 2012 at 1:25 PM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:

But my engines usually don't have any routes and even those who have are not mountable ones.

I'm just asking for an engine to be created even for non-mountable engines. I mean, as the default behavior of "rails plugin new plugin-name".

The "--full" will add integration tests which I also don't usually include in my gems.

Usually I want to bundle some JS libraries as Rails gems for easier reuse among my projects.

Basically, I'd like "rails plugin new plugin-name" to be equivalent of "rails plugin new plugin-name --full -T".

Does it make sense?

Cheers,
Rodrigo.

Em 05-06-2012 13:17, Luís Ferreira escreveu:

Yes. Just do "rails new plugin some_example --mountable".

You should also take a look at --full. ;)
On Jun 5, 2012, at 2:55 PM, Rodrigo Rosenfeld Rosas wrote:

What version are you talking about? That doesn't happen on latest stable 3.2.5 here.

If that is already implemented in master, then great, I hope it to be backported to 3.2.6 when it gets released...

Thanks,
Rodrigo.

Em 05-06-2012 10:22, Luís Ferreira escreveu:

It creates the lib/some-example/engine.rb file which is just as you described and then requires it in lib/some-example.rb. Shouldn't that be enough?
On Jun 5, 2012, at 2:10 PM, Rodrigo Rosenfeld Rosas wrote:

I've been creating several engines for Rails lately and I found that having an engine class inherited from Rails::Engine is required if you intend to bundle some Sprockets assets.

So, shouldn't the template for "rails plugin new" change so that "rails plugin new some-example" would create something like:

lib/some-example.rb:

module SomeExample
   class Engine<   Rails::Engine
   end
end

instead of an empty SomeExample module?

Maybe the "plugin new" could add some option like '--skip-engine' or disable it automatically if "--skip-sprockets" is used.

Make sense?

Kind regards,
Rodrigo.

Cumprimentos, Luís Ferreira

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.

To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

--
Luiz Felipe G. Pereira

[Rodrigo Rosenfeld Rosas]

I'm not that lazy for avoiding to type "--full -T -O" every time I create a new gem.

By the way I don't get why 's.add_development_dependency "sqlite3"' is added to gemspec when -O is specified.

The problem here is that it seems inconsistent to me for a plugin not to be an Engine. I don't even understand why we have so many concepts for extending Rails, like plugins, Railtie and Engine.

I guess it would be better to provide a single approach for extending Rails 4.

In Rails 1, you could get an app-like tree in your plugin and they would be automatically added to the Rails application. It still seems to be the case for generators, for example:

http://guides.rubyonrails.org/plugins.html

But then, things changed a lot and what Rails 1 used to call a plugin seems to be what an Engine currently is:

http://guides.rubyonrails.org/engines.html

Except that the Engine API is better designed than plugins were by that time.

But it doesn't seem consistent to me that you can just drop generators to lib/generators in your plugins, but can't drop your assets in lib/assets.

So, I guess that what I'd really want is to always create engines and call them plugins.

I can't really understand why you consider useful to have plugins, engines and railties as separate concepts.

Best,
Rodrigo.

[Luiz Felipe Garcia Pereira]

One word: Modularity

If it's a simple plugin, it doesn't need to be a Railtie and inserted in rails

If it's something that extends rails/AR it can be a Railtie and take advantage of that.

If it's an engine then it makes sense to add the Engine and have the extra tools Rails::Engine provides.

It's a simple question of remaining flexible to every type of plugin and not add extra unnecessary code.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.

To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

[Rodrigo Rosenfeld Rosas]

Em 05-06-2012 15:05, Luiz Felipe Garcia Pereira escreveu:
> One word: Modularity
>
> If it's a simple plugin, it doesn't need to be a Railtie and inserted
> in rails

Could you please explain the differences about this and a regular Ruby gem?

> If it's something that extends rails/AR it can be a Railtie and take
> advantage of that.
> If it's an engine then it makes sense to add the Engine and have the
> extra tools Rails::Engine provides.

What kind of improvements/benefits would you expect by using the former
instead of the latter?

If there is no real benefit, it would be better to always create an
engine and avoid user's confusion.

[Luiz Felipe Garcia Pereira]

The same rails guides like you pasted before shows a simple example of
"just a plugin" when it just extends the core class String.

As for the differences between Railties and Engines, I'll  quote the
docs (http://guides.rubyonrails.org/engines.html):
"A Rails::Engine is nothing more than a Railtie with some initializers
already set. And since Rails::Application and Rails::Plugin are
engines, the same configuration described here can be used in all
three."

And extracting from the Engine doc:
"it will automatically load models, controllers and helpers inside
app, load routes at config/routes.rb, load locales at
config/locales/*, and load tasks at lib/tasks/*."

I think it will also add lib/assets to the assets path nowadays, but
the doc might be outdated.

[Rodrigo Rosenfeld Rosas]

Em 05-06-2012 15:40, Luiz Felipe Garcia Pereira escreveu:
> The same rails guides like you pasted before shows a simple example of
> "just a plugin" when it just extends the core class String.

I asked exactly what is the difference between this and a regular Ruby
non-Rails gem.

> As for the differences between Railties and Engines, I'll quote the
> docs (http://guides.rubyonrails.org/engines.html):
> "A Rails::Engine is nothing more than a Railtie with some initializers
> already set. And since Rails::Application and Rails::Plugin are
> engines, the same configuration described here can be used in all
> three."
>
> And extracting from the Engine doc:
> "it will automatically load models, controllers and helpers inside
> app, load routes at config/routes.rb, load locales at
> config/locales/*, and load tasks at lib/tasks/*."
>
> I think it will also add lib/assets to the assets path nowadays, but
> the doc might be outdated.

Assets are correctly processed by engines. But the explanation above
didn't talked about what a Railtie really is. What would it be useful
for? They only explain what an Engine does.

[Luiz Felipe Garcia Pereira]

http://api.rubyonrails.org/classes/Rails/Railtie.html
"if you need to interact with the Rails framework during or after
boot, then Railtie is needed"
It shows examples of how to use a Railtie too.

There is no real difference between a non-rails gem and a basic
plugin. It's just pure ruby that gets loaded automatically for being
in the plugins directory.

Go to the code and you can always have the most updated documentation
explaining these things:
https://github.com/rails/rails/blob/master/railties/lib/rails/engine.rb
https://github.com/rails/rails/blob/master/railties/lib/rails/railtie.rb

But this is not a core issue.

On Tue, Jun 5, 2012 at 3:45 PM, Rodrigo Rosenfeld Rosas

[Rodrigo Rosenfeld Rosas]

The point I'm trying to make is that there is no need for exposing so
much details to extension developers.

I'd prefer Rails 4 to only provide a single generator for an engine that
would fit all other cases covered by plugins and railties.

You don't have generators for Metal or other lightweight controller. Why
would you have for a lightweight Engine?

This will just confuse extension developers for no sensible benefit in
my opinion.

[José Valim]

 > The point I'm trying to make is that there is no need for exposing so much details to extension developers. 

There is. Engine has a longer initialization process, more objects involved, etc. Why would you submit your app to a longer initialization process when there is no need to?

Railties provides all the tools you could use to customize a Rails application.

An Engine is a Railtie with all the capabilities you would have in an Application (app, assets, routes, migrations, etc).

All these things are plugins. A gem is how you package a plugin.

> But the explanation above didn't talked about what a Railtie really is. What would it be useful for?

Read the Railtie docs or search for examples on github.com, there are plenty.

> By the way I don't get why 's.add_development_dependency "sqlite3"' is added to gemspec when -O is specified.

It is a bug. Patches are welcome.

[Rodrigo Rosenfeld Rosas]

Thank you for your explanations, Jos�.

But don't you think that engines should be created by default by the
"rails plugin new" command as I expect them to be more commonly used
than railties or plugins?

This is similar to Rails Metal. You can get a lighter controller using
lower-level classes instead of ActionController::Base for faster
responses but you won't find generators for Rails Metal controllers.

I'm just talking about defaults here. Maybe engines should be created by
default and disabled with --skip-engine in Rails 4. Or maybe Rails 4
could add a new "engine" command?