Um, deviating a little from your particular concern (which may or may not be 
justified), but you really can’t complain about being forced to include a gem 
multiple times when you’re including action view (and thus active support, 
I18n, TZInfo, builder, erubis, and a couple more…) *just* to use a method that 
you could very well implement yourself in very simple ruby.




I mean, you were pulling like 8 or 9 gems (without counting nokogiri) just so 
you can avoid formatting a number a little bit, rounding it off, and prepending 
a “$” (or your currency of choice) to a string.




…but *then* you complain that now you have to install an extra gem?




o_O




Cheers,

-foca

On Tue, Jul 14, 2015 at 12:37 AM, null <iybet...@gmail.com> wrote:

> Rails goes out of its way to avoid forcing an installation of bcrypt 
> because it is a binary library. 
>  See https://github.com/rails/rails/blob/v4.2.3/Gemfile#L21
> Nokogiri forces installation of 2 binary libraries (libxml2 and libxslt), 
> so one would expect it not to be a dependency of any of the core components 
> of Rails.
> However, starting with actionview 4.2.0, nokogiri is now a dependency.
> That means every time actionview appears in a Gemfile.lock, so does 
> nokogiri.  I would often include ActionView 4.1 in non-Rails projects just 
> to use number_to_currency, but now with the nokogiri dependency, the 
> overhead is hardly worth it.
> Consider the fact that I'm deploying about 5 such projects to the same 
> server, all using separate BUNDLE_PATH's.  That means 5 installations of 
> nokogiri, none of which are being used.  This adds time to every 
> `capistrano bundler:install` and a significant amount of disk space is 
> wasted on this.  For any other gem, this wouldn't make much of a 
> difference, but nokogiri is really big and takes a long time to install, 
> and Rails has already set a precedent by not including the (much lighter) 
> bcrypt.
> Is the rails-core team open to the following solutions:
> ---------------
> 1) Separate the parts of actionview that depend on rails-dom-testing into a 
> separate gem
> Create an actionview-testing gem, which would only be necessary in the 
> Gemfile's test group, thus saving even more overhead in production.  This 
> would depend on action-view and rails-dom-testing, but actionview would not 
> depend on rail-dom-testing.
> (The same approach that I suggest below for rails-html-sanitizer might work 
> for rails-dom-testing too, but it may add more complexity that carving a 
> separate gem--there are multiple code paths that can lead you to 
> rails-dom-testing methods, whereas there's a single method that's a 
> bottleneck for all entries to rails-html-sanitizer.)
> ---------------
> 2) In ActionView::Helpers::SanitizeHelper, move `require 
> "rails-html-sanitizer"` into the  #sanitizer_vendor method.
> If a LoadError is raised, handle it just as we do for 
> bcrypt: 
> https://github.com/rails/rails/blob/v4.2.3/activemodel/lib/active_model/secure_password.rb#L60
> Add rails-html-sanitizer to the Gemfile template so that it's automatically 
> in new Rails projects.  Only upgrades and would need to manually add this 
> to the Gemfile, so we would have to add it to the upgrade guide. 
>  Standalone actionview projects would also need to add it to their Gemfile, 
> but *rafaelfranca <https://github.com/rafaelfranca>* has assured me that 
> non-Rails projects should never be using rails-html-sanitizer anyway: 
> https://github.com/rails/rails-html-sanitizer/issues/25#issuecomment-60833972.
> ---------------
> I would love to get started on a PR.  I just need to know if it will be 
> considered.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Reply via email to