It’s not that they have to install an extra gem that’s the problem, I think. 
The problem is that Nokogiri is only used by a tiny, tiny subset of ActionView 
and during the course of the application that tiny subset might not be used at 
all.




The installation of Nokogiri can cause issues for people who are new to Rails 
if they’re missing the libxml or libxslt libraries. A solution is that they 
install those libraries. Another is that we remove the Nokogiri dependency.




I’m +1 on separating it out so that it’s an optional part of ActionView, if 
that’s at all possible.

On Tue, Jul 14, 2015 at 9:46 AM, Nicolás Sanguinetti <godf...@gmail.com>
wrote:

> 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.

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