PROPOSAL: Regarding ActionPack Dependencies and ActionView

rubyonrails-core
1

A few days ago, I tried to use ActionView as a standalone dependency of something I was writing. I ended up abandoning that attempt due to the number of unrelated dependencies of the actionpack gem, which ActionView is a part of:

$ gem dependency actionpack

Gem actionpack-3.1.0.rc1

activemodel (= 3.1.0.rc1)

activesupport (= 3.1.0.rc1)

builder (~> 3.0.0)

erubis (~> 2.7.0)

i18n (~> 0.6.0beta1)

rack (~> 1.3.0.beta2)

rack-cache (~> 1.0.1)

rack-mount (~> 0.8.1)

rack-test (~> 0.6.0)

sprockets (~> 2.0.0.beta.5)

tzinfo (~> 0.3.27)

  • activemodel is used for ActiveModel::Naming for a few, mostly optional aspects of ActionPack related to automatically converting an ActiveModel compliant object into a key for params and routing. It uses only two methods of ActiveModel (ActiveModel::Naming.route_key and ActiveModel::Naming.param_key). I think we should remove this dependency, as the point of the ActiveModel API refactor in Rails 3 was to allow any object to work in AP. Additionally, only a few areas of the code use even the ActiveModel API.
  • rack is not used in ActionView at all.
  • rack-cache is not used in ActionView at all.
  • rack-mount is not used in ActionView at all.
  • rack-test is not used in ActionView at all. It is used only in ActionDispatch, and only in test helpers.
  • sprockets is used in ActionView, but only optionally, if asset compilation is desired.
  • tzinfo does not seem to be used at all except in a test

The short version is that ActionDispatch and ActionController use a lot of the dependencies, but ActionView does not.

I would like to propose that we break out ActionView into its own gem with only a few dependencies, and make ActionPack depend on it.

Yehuda Katz Chief Technologist | Strobe

(ph) 718.877.1325

2

Hi, Yehuda, thank you for your efforts in taking this deep research.

I'm all for it to reduce dependencies among packages. I'm currently

(started some months ago, but I read some bits once and then) reading “Clean Code” from Robert C. Martin and there are great advices there, although it is very Java centric and there are better patterns for doing some of the examples in Ruby…

One of its advices, as well as of many other authors on the same

subject, is to reduce coupling between classes, which also extends for packages. The more we isolate them, more we promote software reuse.

If my opinion matters at all, I would say to go with it.

I remember sometime ago I would like to have a framework for non-web

applications that were Rails-like. I wanted ActiveRecord, the generators and file tree structure, as well as tests and ActiveSupport. But I didn’t want anything related to the web, like Rack, ActionPack, etc. Maybe Rails could move into this direction some day… At that time I was planning to start a traffic simulation system…

Cheers!

Rodrigo.
3

Apologies for the thread hijack, but I certainly think abstracting more of rails out so it can be used in non-web projects would be good. For example, with Adhearsion, we need an initialization system much like rails has. It looks like we’re going to have to do that ourselves, rather than being able to make use of all the excellent stuff in railties. If there were a remote chance some sort of abstraction would make it upstream, we’d be all for contributing to it, but I’m not certain that would be the case.

Regards, Ben Langfeld

4

A few days ago, I tried to use ActionView as a standalone dependency of something I was writing. I ended up abandoning that attempt due to the number of unrelated dependencies of the actionpack gem, which ActionView is a part of:

$ gem dependency actionpack Gem actionpack-3.1.0.rc1   activemodel (= 3.1.0.rc1)   activesupport (= 3.1.0.rc1)   builder (~> 3.0.0)   erubis (~> 2.7.0)   i18n (~> 0.6.0beta1)   rack (~> 1.3.0.beta2)   rack-cache (~> 1.0.1)   rack-mount (~> 0.8.1)   rack-test (~> 0.6.0)   sprockets (~> 2.0.0.beta.5)   tzinfo (~> 0.3.27)

   - *activemodel* is used for ActiveModel::Naming for a few, mostly    optional aspects of ActionPack related to automatically converting an    ActiveModel compliant object into a key for params and routing. It uses only    two methods of ActiveModel (ActiveModel::Naming.route_key and    ActiveModel::Naming.param_key). *I think we should remove this dependency    *, as the point of the ActiveModel API refactor in Rails 3 was to allow    *any* object to work in AP. Additionally, only a few areas of the code use    even the ActiveModel API.    - *rack *is not used in ActionView *at all*.    - *rack-cache *is not used in ActionView *at all*.    - *rack-mount *is not used in ActionView *at all*.    - *rack-test *is not used in ActionView *at all*. It is used only in    ActionDispatch, and only in test helpers.    - *sprockets* is used in ActionView, but only optionally, if asset    compilation is desired.    - *tzinfo *does not seem to be used at all except in a test

I've made tzinfo a dev dependency on master and 3-1-stable.

The short version is that ActionDispatch and ActionController use a lot of the dependencies, but ActionView does not.

I would like to propose that we break out ActionView into its own gem with only a few dependencies, and make ActionPack depend on it.

I think it's fine. Please do it (on master)?