Chapter 18. Packaging and Distributing Software
No matter how productive it makes you, a programming language won’t save you any time if you can’t take advantage of a body of code written by other people. A community works faster than any one person, and it’s usually easier to install and learn a library than to write and debug the same code yourself.
That is, if you can find the library in the first place. And if you’re not sucked into an mess of dependencies that grow and grow, making you want to write the code yourself just so you can be doing some real programming.
The success of Perl’s CPAN archive has made the Ruby community work on our own centralized code repository and packaging system. Whatever you think of Perl, you must admit that a Perl programmer can find just about any library they need in CPAN. If you write your own Perl library, you know where to send it: CPAN. This is not really a technical aspect of Perl, but it’s a powerful component of that language’s popularity.
The problem of packaging is more a logistical problem than a
technical one. It’s a matter of coordination: getting everyone to agree on
a single mechanism for installing packages, and a single place to go to
find those packages. For Ruby, the installation mechanism is Ruby gems (or
rubygems or just “gems”), and
rubyforge.org is the place to go to find gems (packaged libraries and
programs).
In many recipes in this book, we tell you to use a gem for some task: the alternative is often to show you pages and ...
Get Ruby Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
