Lono projects have a
Gemfile.lock. This file ensures that gem dependencies for are pinned. To use it, you run
bundle exec lono. It can be annoying to remember typing
bundle exec, though. Using a shim spares you from having to remember this, saving you precious finger-typing energy.
Using a Shim
A shim wrapper ensures that
bundle exec is prepended in front of lono when you’re within a project. You only have to set up the shim once. You can generate a shim with:
$ lono new shim create /usr/local/bin/lono chmod /usr/local/bin/lono
The shim looks something like this:
#!/bin/bash if [ -f config/app.rb ]; then exec bundle exec lono "$@" else exec lono "$@" fi
By default, the shim is written to
/usr/local/bin/lono. As long as
/usr/local/bin is early enough in your system
$PATH, you can type
lono instead of
bundle exec lono.
You can change the path with the
--path option. More info: lono new shim.
The shim wrapper generally work for most systems, it might require adjustments depending on your system.
Rbenv Shim Slowness
If you are using rbenv, it can be slow on some systems. You may want to consider replacing the shim that rbenv generates with a faster one. Here’s an example:
#!/usr/bin/env bash EXE=$(gem which lono | sed 's|lib/lono.rb|exe/lono|') if [ -f config/app.rb ]; then exec bundle exec $EXE "$@" else exec $EXE "$@" fi
Multiple Lono Versions
A shim is recommended when you have multiple versions of Lono installed on the same system. See: Multiple Lono Versions
Long Answer: Why bundle exec?
The key to understanding why
bundle exec is needed sometimes is understadning Ruby, bundler, and system paths work. You see, when you run any cli command with
bundle exec pretended, it affects the system load path.
bundle exec lono version
bundle exec adjusts the load path. The load paths are adjusted to ensure that the exact versions specified in
Gemfile.lock are used. This includes, not only lono, but all Ruby gem dependencies.
When you don’t use
bundle exec, the gem versions used are more dependent how on your environment is configured. In this case, Ruby has little choice but to make some assumptions and uses the first gems found based on your system load path. Usually, the latest gem versions installed on the system are used.
Lono actually calls
bundle exec super early on internally. This helps mitigate dependencies graph resolution issues. But Lono is only able to pin at that point and won’t work for all cases. Sometimes gems must be pinned even before Lono is loaded.
It won’t work when there’s a later version of lono installed on the system, and your
Gemfile.lock pins a different lono version. In this case, you’ll need to use
bundle exec or uninstall other versions of lono from your system.
Bundler already activated Warnings
If you are seeing an error that says a gem dependency is “already activated”, for example:
You have already activated faraday 1.7.0, but your Gemfile requires faraday 0.17.4. Prepending `bundle exec` to your command may solve this.
bundle exec should resolve the issue. Or you can generate a shim as described above.