title: When is it (not) appropriate to bundle dependencies with an application?
body: <p><strong>Summary</strong></p>
  
  <p>I recently had a conversation with the creator of a framework that one of my applications depends on.  During that conversation he mentioned as a sort of aside that it would make my life simpler if I just bundled his framework with my application and delivered to the end user a version that I knew was consistent with my code.  Intuitively I have always tried to avoid doing this and, in fact, I have taken pains to segment my own code so that portions of it could be redistributed without taking the entire project (even when there was precious little chance anyone would ever reuse any of it).  However, after mulling it over for some time I have not been able to come up with a particularly good reason <em>why</em> I do this.  In fact, now that I have thought about it, I'm seeing a pretty compelling case to bundle <em>all</em> my smaller dependencies.  I have come up with a list of pros and cons and I'm hoping someone can point out anything that I'm missing.</p>
  
  <p><strong>Pros</strong></p>
  
  <ul>
  <li>Consistency of versions means easier
  testing and troubleshooting.</li>
  <li>Application may reach a wider
  audience since there appear to be
  fewer components to install.</li>
  <li>Small tweaks to the dependency can
  more easily be made downstream and
  delivered with the application,
  rather than waiting for them to
  percolate into the upstream code base.</li>
  </ul>
  
  <p><strong>Cons</strong></p>
  
  <ul>
  <li>More complex packaging process to include
  dependencies.</li>
  <li>User may end up with multiple copies
  of a dependency on their machine.</li>
  <li>Per bortzmeyer's response, there are potential security concerns with not being able to upgrade individual components.</li>
  </ul>
  
  <p><strong>Notes</strong></p>
  
  <p>For reference, my application is written in Python and the dependencies I'm referencing are "light", by which I mean small and not in very common use.  (So they do not exist on all machines or even in all repositories.)  And when I say "package with" my application, I mean distribute under my own source tree, not install with a script that resides inside my package, so there would be no chance of conflicting versions.  I am also developing solely on Linux so there are no Windows installation issues to worry about.</p>
  
  <p>All that being said, I am interested in hearing any thoughts on the broader (language-independent) issue of packaging dependencies as well.  Is there something I am missing or is this an easy decision that I am just over-thinking?</p>
  
  <p><strong>Addendum 1</strong></p>
  
  <p>It is worth mentioning that I am also quite sensitive to the needs of downstream packagers.  I would like it to be as straightforward as possible to wrap the application up in a distribution-specific Deb or RPM.</p>