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

live errors with latest nanoc #1273

Closed
jm3 opened this Issue Dec 14, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@jm3

jm3 commented Dec 14, 2017

Live errors when running nanoc-4.8.16 via Foreman Procfile on ruby 2.4.2 with global gemset. adsf-live gem is bundled.

Steps to reproduce

  1. ran bundle update
  2. made sure nanoc was using latest gem (not github source)

Expected behavior

site should compile, run

Actual behavior

errors about nanoc/live or asdf/live ensue.

Procfile

(same as discussed at length in #1243)

watch: bundle exec nanoc compile --watch
view: bundle exec nanoc view --live-reload

Details

foreman start
watch.1 | started with pid 35641
view.1  | started with pid 35642
watch.1 |
watch.1 | Captain! We’ve been hit!
watch.1 |
watch.1 |   ... 12 lines omitted (see crash.log for details)
watch.1 |   9. from ~/.rvm/gems/ruby-2.4.2@global/gems/cri-2.10.1/lib/cri/command.rb:329:in `run_this'
watch.1 |   8. from ~/.rvm/gems/ruby-2.4.2@global/gems/cri-2.10.1/lib/cri/command_dsl.rb:256:in `block in runner'
watch.1 |   7. from ~/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/command_runner.rb:13:in `call'
watch.1 |   6. from ~/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/error_handler.rb:15:in `handle_while'
watch.1 |   5. from ~/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/error_handler.rb:57:in `handle_while'
watch.1 |   4. from ~/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/error_handler.rb:15:in `block in handle_while'
watch.1 |   3. from ~/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/command_runner.rb:14:in `block in call'
watch.1 |   2. from ~/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/commands/compile.rb:22:in `run'
watch.1 |   1. from ~/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/commands/compile.rb:29:in `run_repeat'
watch.1 |   /Users/jm3/.rvm/rubies/ruby-2.4.2/lib/ruby/gems/2.4.0/gems/nanoc-4.8.16/lib/nanoc/cli/commands/compile.rb:29:in `require'
watch.1 |
watch.1 | LoadError: cannot load such file -- nanoc/live
watch.1 | Make sure the gem is added to Gemfile and run `bundle install`.
watch.1 |
watch.1 | A detailed crash log has been written to ./crash.log.
view.1  | [2017-12-14 09:39:07] INFO  WEBrick 1.3.1
view.1  | [2017-12-14 09:39:07] INFO  ruby 2.4.2 (2017-09-14) [x86_64-darwin16]
view.1  | [2017-12-14 09:39:07] INFO  WEBrick::HTTPServer#start: pid=35642 port=3000
watch.1 | exited with code 1
system  | sending SIGTERM to all processes
view.1  | exited with code 0

Crash log

https://gist.github.com/jm3/28c58b16bb7697cf07b7daec12804f65

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Dec 14, 2017

Member

The live command now lives in its separate gem, nanoc-live. Add nanoc-live to the Gemfile and it should work.

Nonetheless, the error message that Nanoc shows when nanoc-live is missing should be nicer. Nanoc has the concept of “trivial” errors, which don’t print exception details (i.e. no class name, no stack trace, …), but rather show a simple message to explain that there’s a problem along with succinct steps on how to fix it.

To solve this issue, I think I need the following:

  1. Turn LoadErrors for known gems only into trivial errors. (See below for details.)
  2. Add a test that ensures that new requires are either explicitly marked as a known gem, or explicitly ignored (e.g. test dependencies, stdlib stuff, …).

Known gems:

  • require 'adsf'
  • require 'adsf/live' (gem adsf-live)
  • require 'builder'
  • require 'coderay'
  • require 'colored'
  • require 'fog/core' (gem fog-core)
  • require 'haml'
  • require 'listen'
  • require 'nanoc/live' (gem nanoc-live)
  • require 'nokogiri'
  • require 'nokogumbo'
  • require 'pry'
  • require 'pygments'
  • require 'redcarpet'
  • require 'ref'
  • require 'rouge'
  • require 'slow_enumerator_tools'
  • require 'w3c_validators'
Member

ddfreyne commented Dec 14, 2017

The live command now lives in its separate gem, nanoc-live. Add nanoc-live to the Gemfile and it should work.

Nonetheless, the error message that Nanoc shows when nanoc-live is missing should be nicer. Nanoc has the concept of “trivial” errors, which don’t print exception details (i.e. no class name, no stack trace, …), but rather show a simple message to explain that there’s a problem along with succinct steps on how to fix it.

To solve this issue, I think I need the following:

  1. Turn LoadErrors for known gems only into trivial errors. (See below for details.)
  2. Add a test that ensures that new requires are either explicitly marked as a known gem, or explicitly ignored (e.g. test dependencies, stdlib stuff, …).

Known gems:

  • require 'adsf'
  • require 'adsf/live' (gem adsf-live)
  • require 'builder'
  • require 'coderay'
  • require 'colored'
  • require 'fog/core' (gem fog-core)
  • require 'haml'
  • require 'listen'
  • require 'nanoc/live' (gem nanoc-live)
  • require 'nokogiri'
  • require 'nokogumbo'
  • require 'pry'
  • require 'pygments'
  • require 'redcarpet'
  • require 'ref'
  • require 'rouge'
  • require 'slow_enumerator_tools'
  • require 'w3c_validators'
@jm3

This comment has been minimized.

Show comment
Hide comment
@jm3

jm3 Dec 14, 2017

Oh wow, that was it! Thank you! I guess it can't be marked as a requirement because not everyone uses live reload?

jm3 commented Dec 14, 2017

Oh wow, that was it! Thank you! I guess it can't be marked as a requirement because not everyone uses live reload?

@jm3

This comment has been minimized.

Show comment
Hide comment
@jm3

jm3 Dec 14, 2017

Two questions:

  1. Should I just fully delete my (old) Guardfile now that I'm using the latest nanoc watching stuff?
  2. It's ok to kill adsf and adsf-live from my Gemfile now, correct, since I'm bundling nanoc-live which (I believe) requires adsf-liveadsf?

jm3 commented Dec 14, 2017

Two questions:

  1. Should I just fully delete my (old) Guardfile now that I'm using the latest nanoc watching stuff?
  2. It's ok to kill adsf and adsf-live from my Gemfile now, correct, since I'm bundling nanoc-live which (I believe) requires adsf-liveadsf?
@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Dec 14, 2017

Member

I guess it can't be marked as a requirement because not everyone uses live reload?

nanoc-live has some dependencies that might make it difficult to install on certain platforms.

Should I just fully delete my (old) Guardfile now that I'm using the latest nanoc watching stuff?

The nanoc-live stuff is still experimental, so maybe hold off for a bit!

can i get rid of adsf and adsf-live in my gemfile now, since I've bundled nanoc-live which I believe requires adsf-live → adsf?

Yup.

Member

ddfreyne commented Dec 14, 2017

I guess it can't be marked as a requirement because not everyone uses live reload?

nanoc-live has some dependencies that might make it difficult to install on certain platforms.

Should I just fully delete my (old) Guardfile now that I'm using the latest nanoc watching stuff?

The nanoc-live stuff is still experimental, so maybe hold off for a bit!

can i get rid of adsf and adsf-live in my gemfile now, since I've bundled nanoc-live which I believe requires adsf-live → adsf?

Yup.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Dec 15, 2017

Member

#1274 and #1275 mostly fix this confusing issue, but in order for this issue to be closed, Nanoc still needs a test to ensure that all LoadError for known gems have an entry in GEM_NAMES.

Member

ddfreyne commented Dec 15, 2017

#1274 and #1275 mostly fix this confusing issue, but in order for this issue to be closed, Nanoc still needs a test to ensure that all LoadError for known gems have an entry in GEM_NAMES.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Dec 16, 2017

Member

I made a separate issue for GEM_NAMES: #1276

Member

ddfreyne commented Dec 16, 2017

I made a separate issue for GEM_NAMES: #1276

@ddfreyne ddfreyne closed this Dec 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment