instead of
/app I used /nanoc which I mount to host's PWD
and now I'm heading towards separating
/nanoc (mounted with -v "$PWD:/nanoc") and the place where gems are installed
because it may make no sense to install gem in a host path
and I don't want the gems to be part of the provisioning, so I'm using this entrypoint
#!/bin/sh
set -e
hr() {
printf "%.0s—" $(seq 1 80)
printf '\n'
}
bundle config set --local deployment true
bundle config set --local path .bundle
bundle config set --local without development
if ! bundle check 2>/dev/null; then
hr
printf "Installing gems...\n"
bundle install
printf 'done.\n'
hr
fi
exec bundle exec nanoc "$@"
@ddfreyne btw will you make a release soon? with the timeout fix
Hmm I thought all the Ruby 2.7 warnings were solved
/home/vagrant/.bundle/ruby/2.7.0/gems/nanoc-cli-4.11.16/lib/nanoc/cli/commands/show-plugins.rb:17: warning: already initialized constant Nanoc::CLI::Commands::ShowPlugins::PLUGIN_CLASS_ORDER
/home/vagrant/.bundle/ruby/2.7.0/gems/nanoc-cli-4.11.16/lib/nanoc/cli/commands/show-plugins.rb:17: warning: previous definition of PLUGIN_CLASS_ORDER was here
/home/vagrant/.bundle/ruby/2.7.0/gems/nanoc-cli-4.11.16/lib/nanoc/cli/commands/show-plugins.rb:22: warning: already initialized constant Nanoc::CLI::Commands::ShowPlugins::PLUGIN_CLASSES
/home/vagrant/.bundle/ruby/2.7.0/gems/nanoc-cli-4.11.16/lib/nanoc/cli/commands/show-plugins.rb:22: warning: previous definition of PLUGIN_CLASSES was here
/home/vagrant/.bundle/ruby/2.7.0/gems/nanoc-cli-4.11.16/lib/nanoc/cli/commands/view.rb:19: warning: already initialized constant Nanoc::CLI::Commands::View::DEFAULT_HANDLER_NAME
/home/vagrant/.bundle/ruby/2.7.0/gems/nanoc-cli-4.11.16/lib/nanoc/cli/commands/view.rb:19: warning: previous definition of DEFAULT_HANDLER_NAME was here
3 replies
running
nanoc live from within the container is not really bearable
Sad but true
previously, when using Vagrant, I could forward port
3000 from host to guest guest
and just launch
$ bundle exec nanoc view
now I need to do
$ bundle exec nanoc view -o 0.0.0.0
(which makes sense from a security point of view)
I mean who serves a site with
nanoc view?
:)
and what to do when trying to connect live reload yields
Cannot download livereload.js
hmm seems to be caused by
#<Thread:0x00007f98a1d07280 /usr/local/lib/ruby/gems/2.7.0/gems/guard-livereload-2.5.2/lib/guard/livereload/reactor.rb:11 run> terminated with exception (report_on_exception is true):
/usr/local/lib/ruby/gems/2.7.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:531:in `start_tcp_server'14:17:51 - INFO - Guard is now watching at '/Users/greedo/Projects/myscript_sdk/doc'
: no acceptor (port is in use or requires root privileges) (RuntimeError)
from /usr/local/lib/ruby/gems/2.7.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:531:in `start_server'
from /usr/local/lib/ruby/gems/2.7.0/gems/guard-livereload-2.5.2/lib/guard/livereload/reactor.rb:51:in `block in _start_reactor'
from /usr/local/lib/ruby/gems/2.7.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:171:in `run'
from /usr/local/lib/ruby/gems/2.7.0/gems/guard-livereload-2.5.2/lib/guard/livereload/reactor.rb:50:in `_start_reactor'
from /usr/local/lib/ruby/gems/2.7.0/gems/guard-livereload-2.5.2/lib/guard/livereload/reactor.rb:11:in `block in initialize'
I'm using
bundle exec nanoc live -L -V
apparently I can't use
nanoc live -L if I have guard live reload
it's both logical and so confusing
Also @ddfreyne , a bigger timeout doesn't always help
I'm still hitting
I'm still hitting
Magick::ImageMagickError: unable to open image `/vagrant/output/images/convert-batch.png': No such file or directory @ error/blob.c/OpenBlob/2874
Current item: /tools/inktool/overview.md (:default representation)
0. _factory/lib/images.rb:43:in `ping'
1. _factory/lib/images.rb:43:in `image'
2. item /tools/inktool/overview.md (rep default):185:in `get_binding'
Item A depends on Image B. And Item A's compilation tries to open image in
output/ before it has arrived
I'm not sure if you commented that already but imho when an item A depends on a binary item B, the only correct option is to wait for item B to arrive in
output/ before launching compilation of item A. Is it what Nanoc is currently doing?
2 replies
nanoc live (the one that is provided by guard-nanoc) is a thin wrapper around both
what it the 'trick' in the blogging extension, why the question if items are frozen, and if, the data gets assigned to a variable just to return that
blk = -> { @items.select { |item| item[:kind] == 'article' } }
if @items.frozen?
@article_items ||= blk.call
else
blk.call
endI can understsand that there might be some caching wanted, and that the result is returned if it exists
or does this something different?
but why the items.frozen question ? if this is not the case there is no caching, when is which branch relevant?
Are the people having performance issues with the host file system in Docker running on Macs? The main issue is not file system speed per se but the overhead required to get bidirectional consistency. There are mount options that can improve performance a fair bit depending on what you're doing. See https://docs.docker.com/docker-for-mac/osxfs-caching/ for details.
Ran into this on a project I was working on recently: https://github.com/iay/shibboleth-build-docker/blob/master/README.md#performance
(The workround we used -- temporarily moving the data to /tmp in the container -- obviously wouldn't apply here)