Category: Note To Self

An Odd Behaviour When Creating A Rails App

I’m currently looking into Rails 7 and found an odd behaviour when creating a new Rails app. Before creating a Rails app a few other things need to be in place, most notably Ruby, and _a_ database. My set up is this:


The simplest way to create a new Rails app is this:

rails new app_name

You can also specify various options, including, for example --css=tailwind, to use Tailwind for CSS. Since that’s what is used in a book I’m reading (‘Agile Web Development with Rails 7’ by Sam Ruby & Dave Thomas), I ran this:

rails new app_name --css=tailwind

Now I got an exception logged in the output, while also the exit code of the command was 0. Interesting. Here’s the command and the output (lots of output omitted for brevity):

rails new a_new_app --css=tailwind
      create  Gemfile
         run  git init from "."
Initialized empty Git repository in /Users/stephan/dev/tmp/a_new_app/.git/
      create  app
      create  config/master.key
      append  .gitignore
      create  config/boot.rb
      remove  config/initializers/new_framework_defaults_7_0.rb
         run  bundle install
Fetching gem metadata from
Resolving dependencies....
Using rake 13.0.6
Using minitest 5.15.0

Using rails 7.0.2
Bundle complete! 16 Gemfile dependencies, 75 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
         run  bundle binstubs bundler
       rails  importmap:install
Add Tailwindcss include tags and container element in application layout
      insert  app/views/layouts/application.html.erb
      insert  app/views/layouts/application.html.erb
      insert  app/views/layouts/application.html.erb
Add default
Ensure foreman is installed
         run  gem install foreman from "."
Successfully installed foreman-0.87.2
/Users/stephan/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0/gems/yard-0.9.27/lib/yard/rubygems/hook.rb:88:in `require': cannot load such file -- yard (LoadError)
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:88:in `load_yard'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:163:in `setup'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:152:in `generate'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:63:in `block in generation_hook'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:52:in `each'
  from ….rbenv/…/ruby/…/yard-0.9.27/lib/yard/rubygems/hook.rb:52:in `generation_hook'
  from ….rbenv/…/ruby/…/request_set.rb:311:in `block in install_hooks'
  from ….rbenv/…/ruby/…/request_set.rb:310:in `each'
  from ….rbenv/…/ruby/…/request_set.rb:310:in `install_hooks'
  from ….rbenv/…/ruby/…/request_set.rb:209:in `install'
  from ….rbenv/…/ruby/…/commands/install_command.rb:210:in `install_gem'
  from ….rbenv/…/ruby/…/commands/install_command.rb:226:in `block in install_gems'
  from ….rbenv/…/ruby/…/commands/install_command.rb:219:in `each'
  from ….rbenv/…/ruby/…/commands/install_command.rb:219:in `install_gems'
  from ….rbenv/…/ruby/…/commands/install_command.rb:167:in `execute'
  from ….rbenv/…/ruby/…/command.rb:323:in `invoke_with_build_args'
  from ….rbenv/…/ruby/…/command_manager.rb:180:in `process_args'
  from ….rbenv/…/ruby/…/command_manager.rb:149:in `run'
  from ….rbenv/…/ruby/…/gem_runner.rb:53:in `run'
  from ….rbenv/versions/3.1.0/bin/gem:13:in `<main>'
Add bin/dev to start foreman
      create  bin/dev
Compile initial Tailwind build
         run  rails tailwindcss:build from "."
+ /Users/stephan/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0/gems/tailwindcss-rails-2.0.5-x86_64-darwin/exe/x86_64-darwin/tailwindcss -i /Users/stephan/dev/tmp/a_new_app/app/assets/stylesheets/application.tailwind.css -o /Users/stephan/dev/tmp/a_new_app/app/assets/builds/tailwind.css -c /Users/stephan/dev/tmp/a_new_app/config/tailwind.config.js

Done in 228ms.

This is … interesting, since yard is found, when listing matching gems:

> gem list yard

*** LOCAL GEMS ***

yard (0.9.27)

However, the command that is running at this time is (apparently) executed in the context of Bundler. Since yard isn’t listed in the Gemfile, Bundler won’t find or use it:

bundle info yard
Could not find gem 'yard'.

After uninstalling yard, creating a new Rails app works fine and doesn’t log an exception.

While this solves the issue of getting the exception, it was still unclear why this happened in the first place.

Now, what is yard?

YARD is a documentation generation tool for the Ruby programming language.

Aha, looking into my .gemrc (which is used to configure Rubygems), I found these two lines (Yes, I like to have the documentation generated 🙂):

install: --rdoc --ri --document=yri
update: --rdoc --ri --document=yri

After removing the --document=yri, creating a new Rails app worked fine even with yard being installed.

I still don’t completely understand, why this is an issue when specifying a CSS processor, but not otherwise. This may be topic for another post.
If you have an idea about why this happens, please let me know.

The Different Ways of Pry and Irb

I ran into an interesting little problem when doing sone Ruby (and Rails) work today: I wanted to try something in pry and, inside that Rails project I issued the following command:

$ pry -r sqlite3
…/gems/pry-0.14.1/lib/pry/pry_class.rb:103:in `require': cannot load such file -- sqlite3 (LoadError)
  from …/gems/pry-0.14.1/lib/pry/pry_class.rb:103:in `block in load_requires'
  from …/gems/pry-0.14.1/lib/pry/pry_class.rb:102:in `each'
  from …/gems/pry-0.14.1/lib/pry/pry_class.rb:102:in `load_requires'
  from …/gems/pry-0.14.1/lib/pry/pry_class.rb:143:in `final_session_setup'
  from …/gems/pry-0.14.1/lib/pry/cli.rb:82:in `parse_options'
  from …/gems/pry-0.14.1/bin/pry:12:in `<top (required)>'
  from …/bin/pry:23:in `load'
  from …/bin/pry:23:in `<main>'
  from …/bin/ruby_executable_hooks:22:in `eval'
  from …/bin/ruby_executable_hooks:22:in `<main>'

Interesting! I have both gems, pry and sqlite3 installed. A similar attempt using irb worked fine:

$ irb -r sqlite3
3.0.1 :001 > SQLite3::VERSION
 => "1.4.2"
3.0.1 :002 >

Maybe I confused the environment by setting some environment variable or other? With a newly opened command shell I got this:

$ pry -r sqlite3
[1] pry(main)> SQLite3::VERSION
=> "1.4.2"
[2] pry(main)>

Remarkable. In that new shell the irb command behaved the same as before.

The only difference I could find was that the original call to pry happened in a Rails project – which is using Bundler to organise the Rubygems used in the project and resolve dependencies. As a small experiment I set up a minimal project that uses bundler and a rather short Gemfile:

source ""

gem  'limit_detectors'

The gem ‘limit_detectors’ is one I wrote and I know that is doesn’t depend on other gems. Issuing the pry command again … worked? Why? Some more investigation was needed…

Finally, I realised that another gem (Guard, to be specific), uses pry. Therefore my Rails project’s development environment indirectly depends on pry. It looks like pry recognises that it’s running as part of a Bundler project, even when it is not explicitly called using bundle exec pry …, which in turn causes it (pry) to ‘only’ recognise the gems that are also installed using Bundler. – And sqlite3 isn’t in this case, since I’m using PostgreSQL throughout.

Since irb comes with the Ruby installation and is not part of the bundled gems, it ignores the bundler context when called like this:

irb -r sqlite3

However, explicitly calling it in the bundler context in a project that doesn’t depend on ‘sqlite3’ (directly or indirectly) will cause an error message:

$ bundle exec irb -r sqlite3
…/rubies/ruby-3.0.1/lib/ruby/3.0.0/irb/init.rb:376: warning: LoadError: cannot load such file -- sqlite3
3.0.1 :001 >

Nice! This is essentially the same problem, I faced at the very beginning, when pry couldn’t find the sqlite3 gem.

A Local Rails Server in a Local Network

I’m currently working on a Rails app, that I want to have available in my local network on the default port that Ruby on Rails uses: 3000.

To do that, I added a line to the development config (config/environments/development.rb):

config.hosts << 'hostname.local'

Update: Apparently adding the line config.hosts.clear works as well. Details about this are explained in the Rails Guides.

I started using Foreman to achieve this, and installed it using:

gem install foreman

Note that, according to a Wiki Page on Github, it’s not recommended to put foreman into the Gemfile.

Then I created a Procfile that Foreman uses to start the web server (which currently is the only process I need it to start):

web: bundle exec rails s -b -p 3000

The -b binds the process to that IP address and -p 3000 instructs it to use port 3000.

With that set up foreman start can be used to start a Rails server in development which is available in the local network.

This way I can check the layout and functionality on a mobile phone or one of my iPads.

Seeing And Saying On The Command Line

Occasionally I like command line tools to also say the output, in addition to ‘printing’ it (to STDOUT).

A current context is starting a server locally with updated information. The start up takes time, so I tend to not wait at the command line for it to fully boot.

I wanted a noticeable signal when the thing is up – and also a confirmation that the version of the information source *is* actually updated. The commands tee and (the macOS) say do this for me:

tee >(say&)

tee copies the output of its input to STDOUT (usually the terminal) and the given file. The construction >(other command&) causes tee to send the input not to a file but to othercommand and the & causes that command to return immediately (instead of returning only after the command to finish).

Overall, I do something like this. The system returns a lengthy JSON string, so I use jq to get to the version information I’m looking for:

curl -s -u <username:thepassword> “<url_to_locally_running_service>” | jq “<path_to_version_info_in_json>” | tee >(say&)

The GitHub page explains that

jq is a lightweight and flexible command-line JSON processor.

It’s well worth trying, if you’re dealing with JSON input on the command line.

Passing Multiple Arguments To One Rake Task

Occasionally, I want Rake tasks to take multiple arguments. If the number of these arguments are know beforehand, Rake provides a nice way to express that in the Rakefile (see the Rake documentation for more details).

However, sometimes I like to pass a varying number of arguments the a task, which shall all be processed in the same way. Maybe its user IDs that need to be removed from a database, or a given list of piles to be processed.

Today I found a way to do this, by using Rake::TaskArguments#extras . The method extras returns a list of all the extra arguments passed to a Rake task, that are not named in the task definition. If no argument name(s) are declared in the task definition, then all arguments will be ‘extra arguments’.

An example Rakefile is this:

task :list do |t, args|
  puts "In task '#{}"
  puts 'Passed arguments:'
  puts { |extra| "  * #{extra}" }

Calling this task from the command line and its output (in zsh) looks like this:

$ rake list\[one,2,3.141]
In task 'list
Passed arguments:
  * one
  * 2
  * 3.141

Note, the \ before the opening bracket ‘[‘. In zsh, this is needed to escape the ‘[‘ (pairs of ‘[]’ have a special meaning in zsh). Also note, that there are no spaces between the arguments, just the comma.

If you prefer to add a space after the comma, there’s a way to achieve this (again in zsh): Drop the ‘\’ and instead put the task name and the arguments in quotes:

$ rake "list[one, 2, 3.141]"
In task 'list
Passed arguments:
  * one
  * 2
  * 3.141

$ rake 'list[one, 2, 42]'
In task 'list
Passed arguments:
  * one
  * 2
  * 42

In this example it doesn’t affect the output whether single or double quotes are used. Quoting in shells is … complicated, see for example:

Did you find this helpful? Or do you know a better way to pass multiple arguments to one Rake task? Please let me know.


%d bloggers like this: