PROPOSAL: Regarding ActionPack Dependencies and ActionView

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

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.

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

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)?