Lemme pry!

Every so often when I hear about a new gem, someone reports a bug, or when reading about new goodies in a gem, I'm like: lemme try!
This is when an imaginary timer starts…

TTR to the rescue

The timer will stop when my cursor is at a REPL-prompt and I can actually try out the stuff I just read about.
The total time elapsed at this point we'll call TTR, or "Time To REPL". As you can learn a lot from lemme-try sessions, our aim is to make the TTR as low as possible.

Let's look at the steps involved in a typical TTR for Ruby:

  • open a terminal
  • ensure the relevant gem is installed
  • start irb
  • require the gem
  • stop the time!

Hmmm, quite some steps and typing involved just to try something out. Not a good TTR-score!
Moreover: the steps are slightly different when I want to try multiple gems at once. Things get even more complex when I need specific versions. (In that case it's probably better to write a Gemfile and let bundler sort it out).

All in all not a great experience and as with all cumbersome workflows: you do them less often or stop doing them altogether.
Fewer lemme-try sessions: boooh!

When in doubt…

What if we could put decision fatigue to good use and make it actually hard to not give in to the impulse of trying things out on a REPL? That's right: a consistent TTR of a couple of seconds. When in doubt, try it out!

Well, I wrote a thing…


Lemme-pry is a gem meant to make the lemme-try workflow quick and consistent. It's inspired by Clojure's lein-try and uses Pry, which is essentialy IRB on steroids. Source-code browsing, syntax highlighting, gist integration among a whole lot more: Pry has it.

Let's install it and see how to play with Active Support for example:

$ gem install lemme-pry
$ lemme-pry activesupport
...crunching gems...
Using activesupport 5.1.1 (was 4.2.6)
[2] pry(main)> 1.second
=> 1 second

💥 That's it: one simple command and you have AS at your fingertips!

A version can be specified like you would in a Gemfile:

$ lemme-pry activesupport '~> 4.2'

Want multiple gems? Just ask:

$ lemme-pry activesupport '~> 4.2' redis

stick it in a pipe

While trying one or more gems is nice and dandy, sometimes you need a bit more context. For cases like this you can pipe-in a script. It will eval every line on the REPL, after which it's your turn:

$ echo 'time = Time.now' | lemme-pry
...initing stuff...
[2] pry(main)> time
2017-05-25 18:23:40 +0200

This is ideal for sharing scripts with other contributors that need to follow-along (think bug-reports, tutorials etc).

Being able to pipe-in a script means your script can live anywhere. E.g. using the gist-commandline tool you can easily curl-pipe-pry a gist1 :

$ gist -r 76955c57512c1e4ac01cdd913b76c92d | lemme-pry
[2] pry(main)> 

If you need gems in these scripts you can use Bundler's inline gemfile capabilities.
This allows you to have the benefits of bundler even for simple scripts:

#!/usr/bin/env ruby
require 'bundler/inline'

gemfile(true) do
  source 'https://rubygems.org'
  gem 'activesupport', require: 'active_support/all'

# Actual stuff you want to do starts here...

Under the hood lemme-pry uses bundler-inline scripts extensively so generating a template is just a flag away:

$ lemme-pry --inline activesupport > script-using-as.rb

Bundler-inline is awesome and lemme-pry makes it easy for you to generate a template you can base your script on.

put it on Rails

Last but not least you can use lemme-pry within your project.

Say for example I want to share a script with teammembers to show how a bug manifests itself:

# issue-12.rb
require './config/environment' # load Rails

@ann = User.find(1)

# this crashes
@sub = Subscription.create(user: @ann).pay!

For teammembers to see what's wrong and inspect from the REPL, they can execute:

# requires `lemme-pry` to be be added to the project's Gemfile
$ cat issue-12.rb | bundle exec lemme-pry

A very powerful way to get on the same page with other developers!

Give it a spin and start pry-ing!

  1. Indeed, curl-pipe-evaluating stuff is not without risk. Sticking vipe in the pipe (npm variant) might reduce the risk somewhat.