Michael Sokol

Software engineer's take on programing languages and paradigms. Talks about my open-source projects.
~ Saturday, February 26 ~
Permalink

‘lib’ folder is a misnomer when creating Ruby Gems applications

Note: If you’re not familiar with gems’ file tree-structure conventions, I would highly recommend reading Steve Klabnik’s Making Ruby Gems post.

Ruby gems offer a powerful way to create and share libraries and applications. After analyzing a few projects on Github, including rake, bundler, haml, mustache, FasterCSV, and a bunch more, I realized that the preferred way of structuring a Ruby Gem (as explained in Making Ruby Gems) is the de-facto structural standard for any Ruby project.

This project-structure standard works well because it’s simple, and it makes sense. All the source files of the library you are developing should go to ‘lib/’, all the binaries to ‘bin/’. It feels natural. This is how we would do it if we were to do it naturally.

However, I would like to issue a little warning when it comes to developing applications (as opposed to libraries) using this project structure.

There is a clear boundary between an application and a library.

In computer science, a library is a collection of resources used to develop software. These may include subroutines, classes, values or type specifications. - Wikipedia

A library is a set of utilitarian classes, methods and definitions available to prevent reinventing the wheel. It provides services to solve problems recurring through projects. It is there to help the developer developing an application.

I like to see it as a real library, where each book gives the solution for a given problem. One can just pick and apply the book’s principle.

A library is not an application because it doesn’t implement the application’s specific behavior. It’s not complete. It doesn’t have a “main” function. It’s too generic. It’s a set of lego blocks to develop your own application.

This is why I wanted to issue the warning. When we are developing applications using Ruby Gems standard structure, we are putting application-specific code in the ‘lib/’ directory, including runner classes. I have never seen any serious Ruby project (although I’m fairly new to Ruby, so I might have missed some) putting source code in a ‘src/’ directory. rake, bundler, world-class ruby applications put their source code in the ‘lib/’ directory even if it’s application specific.

So why are we still using ‘lib/’ when building applications? Because it’s good. Because ‘Convention over Configuration’ is better than a vocabulary issue. Yes, we could easily have an ‘src’ directory instead of a ‘lib’ one, but let’s comply to the globally accepted way of doing things, because maintenance payoff is way bigger if we all agree on a way to do things, especially in the open-source world. On a more technical point of view, ‘lib/’ also happen to be the default folder that gets added to the $LOAD_PATH variable.

So if you should take anything from that, just keep in mind when you’re working on an application that no, you’re not doing a library, and yes, it’s fine to put your source files in the ‘lib’ folder.


 ()