Minimizing Library Dependencies

Peter Marklund


  • Minimizing Library Dependencies

Minimizing Library Dependencies

Weighing In At

Application LOC: 16008

28 vendor/gems, LOC: 36000

37 vendor/plugins, LOC: 28000

vendor/rails, LOC: 96000

Library Smells

Advantages to Rolling Your Own

1. Application Level Libraries

2. Libraries To Make Your App More DRY

3. Wrapper Libraries (Ruby DSLs)

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

  • carrierwave and fog
  • minimagick/rmagick
  • s3_swf_upload and aws/s3
  • httparty
  • restful_acl
  • whenever
  • restful_authentication
  • ssl_requirement
  • friendly_id – babosa
  • FasterCSV (replaced in Ruby 1.9.2)
  • logworm_amqp (json, minion, amqp, bunny, eventmatchine, ruby-hmac, memcache-client, hpricot, oauth, heroku)

Libraries I Still Depend On