Github-pages gem incompatible with Ruby 2.3 on Windows due to nokogiri

[qwertie]

• I believe this to be a bug, not a question about using Jekyll.
• I Updated to the latest Jekyll (or) if on Github Pages to the latest github-pages
• I Read the CONTRIBUTION file at https://jekyllrb.com/docs/contributing/
• This is a feature request.
• I am on (or have tested on) _Windows_ 10+ (same issue occurs on Win7)
• I was trying to install.

I've had this problem for a few weeks now. Repro: Make a Gemfile like

source 'https://rubygems.org'
gem 'github-pages'

install Ruby 2.3, install bundler and do bundle install. Fails 'cause you need DevKit. Install DevKit. bundle install again. Output:

C:\Dev\ecsharp.net>bundle install
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Fetching dependency metadata from https://rubygems.org/
Resolving dependencies....
Installing RedCloth 4.2.9 with native extensions
Using i18n 0.7.0
Using json 1.8.3
Using minitest 5.8.4
Using thread_safe 0.3.5
Using addressable 2.4.0
Using coffee-script-source 1.10.0
Using execjs 2.6.0
Using colorator 0.1
Using ffi 1.9.10
Using multipart-post 2.0.0
Using gemoji 2.1.0
Using net-dns 0.8.0
Using public_suffix 1.5.3
Using sass 3.4.21
Using rb-fsevent 0.9.7
Using kramdown 1.10.0
Using liquid 3.0.6
Using mercenary 0.3.5
Using rouge 1.10.1
Using safe_yaml 1.0.4
Using jekyll-feed 0.4.0
Using mini_portile2 2.0.0
Using jekyll-paginate 1.1.0
Using jekyll-sitemap 0.10.0
Installing rdiscount 2.1.8 with native extensions
Installing redcarpet 3.3.3 with native extensions
Using terminal-table 1.5.2
Using bundler 1.12.5
Installing jekyll-textile-converter 0.1.0
Installing tzinfo 1.2.2
Installing coffee-script 2.4.1
Installing ethon 0.8.1
Installing rb-inotify 0.9.7
Installing faraday 0.9.2
Installing jekyll-sass-converter 1.3.0
Installing nokogiri 1.6.7.2

Gem::InstallError: nokogiri requires Ruby version < 2.3, >= 1.9.2.
Installing activesupport 4.2.6
Installing jekyll-coffeescript 1.0.1
Installing typhoeus 0.8.0
Installing listen 3.0.6
Installing sawyer 0.7.0
An error occurred while installing nokogiri (1.6.7.2), and Bundler cannot
continue.
Make sure that `gem install nokogiri -v '1.6.7.2'` succeeds before bundling.

Rumor has it that this can be fixed by changing the dependency from nokogiri 1.6.7.2 to 1.6.8 or at least 1.6.8.rc3.

[ashmaroli]

you could try running bundle update to update the gemfile.lock or manually install with

gem update --system
gem install nokogiri

[qwertie]

Wow! Even though I'd fruitlessly tried installing a couple of other versions of nokogiri, bundle update did the trick! Thank you!

Now if only it didn't take 173 seconds for jekyll serve --watch to regenerate... dam slow ssd ;)

[ashmaroli]

whoa! 173 seconds?! Thats a lonngg wait.. How huge is your blog?

[DirtyF]

@qwertie you can always give a shot at jekyll serve --incrementaloption (auto-regeneration with --watch is enabled by default you don't need to specify it anymore)

[qwertie]

ashmaroli commented 23 hours from now

LOL GitHub, way to remind me I set my clock back a day due to the expired certificate on Jekyll Talk (now fixed).

How huge is your blog?

30 MB, 2068 files, almost all of which are plain HTML generated by Doxygen with no front matter. After adding --incremental it's taking less time:

  Regenerating: 1 file(s) changed at 2016-08-24 01:27:54 ...done in 57.733302 seconds.
  Regenerating: 1 file(s) changed at 2016-08-24 01:28:51 ...done in 59.900426 seconds.

although I don't necessarily believe --incremental is what made the difference, since historically Jekyll has taken much different amounts of time on different days of the week and phases of the moon.

[ashmaroli]

ahem..
the comment makes it look like, I said the following (which I didnt):

LOL GitHub, way to remind me I set my clock back a day due to the expired certificate on Jekyll Talk (now fixed).

You might want to edit your comment there.

--incremental helped you gain 113 seconds, though.. thats a huge gain especially since there so many files to parse.

[DirtyF]

@qwertie use --profile option if you wanna identify the time consuming parts, maybe you can optimize some Liquid parts and avoid unnecessary computing.

[ashmaroli]

@DirtyF, is there a page in the docs that lists all the available options for the entire Jekyll Module?

---

Update: Yes, there is a page detailing them:
Jekyll Configuration

[qwertie]

@DirtyF Sure. Here are the results:

      Regenerating: 1 file(s) changed at 2016-08-24 01:49:03
Filename                                        | Count |  Bytes |  Time
------------------------------------------------+-------+--------+------
_layouts/default.html                           |     1 | 10.44K | 0.159
/Dev/Loyc.net/_includes/sidebar.html            |     1 |  1.48K | 0.028
/Dev/Loyc.net/_includes/head.html               |     1 |  0.85K | 0.002
index.md                                        |     1 |  6.73K | 0.001
/Dev/Loyc.net/_includes/comments.html           |     1 |  0.00K | 0.001
/Dev/Loyc.net/_includes/redirectDomainBody.html |     1 |  0.00K | 0.000

...done in 56.771248 seconds.

[ashmaroli]

Try stopping your server and run jekyll serve --profile to get the entire list.
That'll help you identify the slow files.
(You dont have to post that result here.)

[qwertie]

@ashmaroli the results are similar - initial generation without --incremental is about 47 seconds but the --profile time only totals up to about 5 seconds.

[qwertie]

Anyway, thanks for the quick responses guys! Let me know if there's any other possible performance bottleneck on Windows besides the pages themselves.

[DirtyF]

@ashmaroli no, it's only listed in the CLI when you run jekyll build --help or jekyll serve --help. Will fix that.

[envygeeks]

LOL GitHub, way to remind me I set my clock back a day due to the expired certificate on Jekyll Talk (now fixed).

@qwertie uhm, Github has nothing to do with Jekyll Talk, that is ran by me personally, out of my own pocket.

[ashmaroli]

@DirtyF, Cool! Let me know if you need collaboration.

[jekyllbot]

Hello! We are utilizing a new workflow in our issues and pull requests. Affinity teams have been setup to allow community members to hear about pull requests that may be interesting to them. When a new issue or pull request comes in, we are asking that the author mention the appropriate affinity team. I then assign a random "team captain" or two to the issue who is in charge of triaging it until it is closed or passing it off to another captain. In order to move forward with this new workflow, we need to know: which of the following teams best fits your issue or contribution?

• @jekyll/build – Concerned with the Jekyll build pipeline, from reading files, rendering them, and writing them. Includes incremental regeneration.
• @jekyll/documentation – Concerned with making jekyllrb.com and other Jekyll documentation great.
• @jekyll/ecosystem – Concerned with the fostering of a vibrant ecosystem. Plugins, themes, etc.
• @jekyll/performance – Concerned with Jekyll's speed.
• @jekyll/stability – Concerned with all things stability, including configuration, defaults, deprecation, etc.
• @jekyll/windows – Concerned with Windows compatibility. Can provide testing and guidance for Windows-related bug fixes and enhancements.

Mention one of these teams in a comment below and we'll get this sorted. Thanks!

[DirtyF]

@ashmaroli Thanks, profile option is now documented in #5279

[qwertie]

@envygeeks Since you didn't understand the joke:

1. I went to Jekyll talk while filing this issue. It said the HTTPS certificate had expired a few hours ago (it has since been updated).
2. I set my clock back 24 hours so that I didn't have to create a certificate exception.
3. Later I noticed that message from GitHub which reminded me my clock was wrong.