Process for debugging a third-party gem

Question

While using the guard-cucumber plugin I found it wasn't working with terminal-notifier-guard

What's the best way to figure out what's going wrong and start making lasting fixes?

Some important criteria are:

  1. I want to get up and running as fast as possible.
  2. Once I'm up and running I want to be able to iterate as fast as possible.
  3. I want to alter my project as little as possible.
  4. I want to be able to keep my changes in version control so I don't lose track of them.
  5. I want to be able to get feedback on my changes if I want.
  6. I want to test my changes in an isolated env.
  7. I don't want to change the guard-cucumber gem installed on my system.

This is my process:

  1. Fork the project and clone it.
  2. Create a new branch
  3. Change the name to guard-cucumber-cats in the gemspec.
  4. In the cloned gem, Do some work.
  5. Add a breakpoint near my work with pry:

    require 'pry'
    binding.pry
    
  6. rake install to install guard-cucumber-cats on my machine.

  7. In my project, add guard-cucumber-cats as a dep and comment out guard-cucumber in gemspec. For example:

    # spec.add_development_dependency "guard-cucumber", "~> 2.1.2"
    spec.add_development_dependency "guard-cucumber-cats"
    
  8. Run my project, hit debug, mess around with code.
  9. Repeat 4-8

Thinking about process in terms of criteria:

  1. Getting up and running wasn't too bad
  2. Iterating was pretty painful, having to reinstall the guard-cucumber-cats every time I wanted to test a change was awkward.
  3. Changing one line in my project gemspec doesn't seem bad, however it would be better to be able to change nothing.
  4. All the benefits of git right for the beginning was a huge plus
  5. Same goes for github
  6. I don't have a workflow setup with either vagrant or docker, so my "isolated" test env is basically just me on my laptop. Maybe this is a good opportunity to set up a working containerized dev env? I'm not sure sure, but the way I have it now doesn't seem like it meets this criteria.
  7. Although it seems awkward to have to rename the gem and then install it on my system it is nice that I didn't need to change the actual guard-cucumber on my machine.

Ideally I'd like to be able to do something like:

  1. cp -r my project into some sandboxed env
  2. Clone the forked guard-cucumber into the same sandboxed env
  3. Have everything "just work"
  4. Do work on the cloned guard-cucumber
  5. Repeat 4

I read in another answer to just start edit the system gem but didn't like that solution because I lose the benefits of git and github.

Is there a better process that's working for you? Or areas my process can be improved?

Also, as a side note: this is how you can nest code blocks in a list


Show source
| ruby   | rubygems   | bundler   | development-environment   | rake   2016-12-30 23:12 1 Answers

Answers to Process for debugging a third-party gem ( 1 )

  1. 2016-12-30 23:12

    Use :path in the project's gemfile.

    You are working on gem my_gem and project my_project at the same time. To make this painless use this in the gemfile of your project

    # in /path/to/my_project/Gemfile
    ...
    
    gem 'my_gem', :path => '/path/to/my_gem'
    
    ...
    

    And then you can iterate without having to build the gem all time.

    There's isn't even a need to rename the gem.

Leave a reply to - Process for debugging a third-party gem

◀ Go back