If you are an early adopter like me you like using the latest and greatest technology. When working with Open Source software however early adopters can face challenges when the latest is not always the greatest. Bugs are a problem in any software but thankfully the community-driven nature of Open Source projects means that those bugs are often reported and resolved very quickly.
That does not mean, however, that a new release of that software is made available to everyone as soon as the bug has been resolved. The release cadence of Open Source project varies greatly from project-to-project and it is unreasonable (and likely undesirable for everyone) if a new release of a gem was made available every time a bug was resolved. The maintainers would be constantly building and users would be constantly upgrading. The internet would be littered with relatively meaningless patch releases for thousands of gems.
So what do you do if you run into a particularly troublesome bug that is causing you grief? You have a couple choices:
- Ignore and/or workaround the problem.
- Downgrade the software to a previous stable release.
- Build the software locally from source.
Options 1 and 2 are what most users are familiar with. If the new version of an application doesn't work we either deal with it or downgrade to a previous version. If you are savvy though (and you are reading this blog post so I know you are), option 3 provides a fantastic way to always keep on the bleeding edge.
In this blog post I am going to briefly explain how you can build a gem directly from source so that you can find relief from a bug that has been fixed in the source code but has not yet made it into a release. For me, the bug I want addressed is Berkshelf #1034. This was a bug in the publically-release beta version of Berkshelf 3.0.0 which caused an infinite loop when trying to resolve cookbook dependencies. This was not something that I could ignore or workaround easily so option 1 was out. Option 2 was feasible but Berkshelf 3 has a lot of features that I really liked so I decided to go with option 3: build the software locally from source.
Step One: Clone the Repo
The first step is to clone the repository to your local machine. It doesn't really matter where on your machine - that is your personal preference. For me, I maintain a folder called OpenSource where I clone all of the Open Source projects I follow or contribute to.
~/OpenSource $ git clone firstname.lastname@example.org:berkshelf/berkshelf.git
This command will create a berkshelf folder in my OpenSource folder. Inside the cloned repository folder (~/OpenSource/berkshelf) there will be a .gemspec file. In this case, I am looking for ~/OpenSource/berkshelf/berkshelf.gemspec.
Step Two: Build the Gem locally
Once you have the source code checked out you can use the .gemspec file to build the gem locally.
~/OpenSource/berkshelf $ gem build berkshelf.gemspec
This command will use the specified .gemspec file to generate a .gem file. In my case, it generated ~/OpenSource/berkshelf/berkshelf-3.0.0.beta7.gem. The name of the .gem will depend on how the .gemspec is configured. Be aware, there may be certain system requirements (i.e. Ruby versions, other gems, etc) that you may need to resolve before you can continue.
Step Three: Install the Gem
Once the .gem file has been created, you can install that gem onto your system.
~/OpenSource/berkshelf $ gem install berkshelf-3.0.0.beta7.gem
Step Four: Rejoice!
You're done! You can run the following command to double check that your gem installed successfully.
~/OpenSource/berkshelf $ gem list --local | grep berkshelf