-
-
Notifications
You must be signed in to change notification settings - Fork 898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nokogiri 1.6.0 is very large when installed #952
Comments
What would help a lot is documentation on how to specify in the Gemfile that nokogiri should use system libraries. Currently I have to use: "$ NOKOGIRI_USE_SYSTEM_LIBRARIES=true bundle install --path gems" |
The development branch I mentioned in #923 includes a measure for this issue. Please check out. |
Im not sure what's applicable in #923 but I remembered that a Gemfile is ruby so this is a simple way to avoid having lib built
|
Merged the static_clean branch in ab984ce. |
When will this make it into a release? |
Related: the 7+ MB of libxml2 and libxslt documentation installed in |
This is probably really a general rubygems issue but nokogiri 1.6.0 is an extreme case.
After running
gem install nokogiri -v 1.6.0
(or letting bundler do the equivalent), the installednokogiri-1.6.0
directory is very large. On a Heroku dyno using ruby 1.9.3 it is 120M. This is for a couple reasons:ports
directory contains tarballs for libxml and libxslt, as included in the gemports
directory contains extracted contents of those tarballsext
directory contains a duplicate set of extracted contents of those tarballsext
directory contains build artifacts for libxml, libxslt, and nokogiri itselfHere's
du
output for thenokogiri-1.6.0
directory on the same Heroku dyno:This translates to 120M of data not necessary for actually using nokogiri hanging around. In Heroku's case this data goes into the compiled slug which isn't ideal. There are likely other cases outside building slugs for Heroku where this extra data causes subtle size-related issues.
If possible, it would be great if nokogiri could clean up after itself a bit after building its extensions. I am not immediately sure what that would look like within current gem conventions but I am happy to help figure it out.
Ref heroku/heroku-buildpack-ruby#122
The text was updated successfully, but these errors were encountered: