Minimizing Library Dependencies

Peter Marklund

Contents

Weighing In At

Application LOC: 16008

28 vendor/gems, LOC: 36000

37 vendor/plugins, LOC: 28000

vendor/rails, LOC: 96000

Library Smells

• The library does too much (low cohesion) or too little
• You need to patch the library to fit your application
• A lot of gem dependencies
• The gem dependencies duplicate or conflict with your gems
• Coupling through global variables, Rails or Ruby patches
• Lack of test coverage
• Not mature/stable. Unclear interface.
• No active maintenance or community
• Hard to read and understand. A lot of code.

Advantages to Rolling Your Own

• You understand your own code and know how to maintain it
• You run regression tests for your code when you make changes
• The code does exactly what your app needs, no more, no less
• You control the quality and style of the code
• Ruby and Rails upgrades are easier

1. Application Level Libraries

• restful_authentication/device
• paperclip/carrierwave
• aasm/state_machine
• acts-as-taggable-on

2. Libraries To Make Your App More DRY

• inherited_resource
• simple_form/formtastic
• show_for

3. Wrapper Libraries (Ruby DSLs)

• mongoid
• right_aws
• sunspot-rails (sunspot – rsolr)
• whenever
• httparty
• tiny_mce

Specifying Versions

	gem 'foobar', '>= 4.3.2' # probably not backwards compatible
	gem 'foobar', '~> 4.3'   # should be backwards compatible
	gem 'foobar', '~> 4.3.2' # most likely backwards compatible
	gem 'foobar', '4.3.2'    # version lock

Version Lock/Promiscuity (Hell)

“In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.”

Look at all the libs I’m Not Depending On

Libraries I Still Depend On

• rails (bundler, treetop, rake, thor, erubis, builder, tzinfo, i18n, mime-types etc.)
• pg
• delayed_job
• right_aws (Github fork)
• mongo (bson, bson_etx)

Resources

• Using >= Considered Harmful
• Semantic Versioning
• RubyGems Versioning Policies