I agree with you - the "not invented here" libs don't belong in your repo. I'm always amazed when I walk up to a "mature" base of code and find third party and open source dependencies festering all over the repository. This drives me crazy. There is just NO reason this stuff needs to be in source control. It's pure laziness that drives developers to just punt and check whatever version they happened to be using during dev. This makes final packaging as well as future upgrading a nightmare (particularly if other projects have glommed-on to the same dependency in the meantime).

The lowest-budget solution is simply to store the third party and open source projects in a reliable network file share (NFS, samba, etc). Then you can either sync locally or just build/link directly against the mounted file share.

It's also important to keep each project in a directory structure that includes the version number in the path (e.g. /nih_libs/boost/1.44.1/...) so that you can easily drop in a new version and start using as needed on a project by project basis. I'm always amazed how many places neglect this step and then have nothing but pain when they want to upgrade to a new version of a lib.

I still don't understand why dependencies don't belong to the repo. My naive reasoning: I just have to clone the repo and bam, I already have all the dependecies needed to build the artifact. When I need to upgrade to a new version of a library, I only have to commit a new version and delete the old one (possibly integrating the new library in a separate branch if the process is not trivial).

Can you elaborate a bit more on this?

If you use something like Git submodules, Mercurial subrepos, or Subversion externals, you can get the best of both worlds. Your repo contains just your code, but a fresh clone will set up dependencies automatically.

I've also seen really simple projects get by with just an "install_deps" task in the Makefile, which you run first thing on a new clone. ("The simplicity of Maven meets the dependency management of Make," the wags will say.)

Sure, this is a solution. But my confusion remains: why I should't put all these dependencies in the repository with the code that uses them? In the end, doing so I have (almost) all I need to produce the intended software artifact.

There are a few reasons to do this. One is to at least nominally separate code that's licensed differently than yours (something your lawyers may ask you to do). Another is to make it easier to share your tweaks to the third-party code among several of your own projects.

It's funny to see someone defend Maven in 2011.

However, yes, checking in dependencies with your code is the way to go.

Deps that can be reliably included with just a meta-descriptor (i.e. Gemfile, pom.xml, etc.) are still exceptionally rare. Thus the natural choice is to put the rest right next to the code that it belongs to. Well, natural choice unless you're stuck in a 90s java mindset...

What's wrong with Maven? I'm asking this as someone who hasn't used it and who wanted to give it a whirl. Any input would be much appreciated.

If you want to do something simple it takes a 60 line pom.xml to express it. If you want to do something a little trickier it takes another 60 lines and three hours minimum of poking around at inadequately written docs. If you want to do something difficult, forget it. Ant, which is a nightmare of usability and continues to make me wake in the middle of the night screaming, is at least as complex to configure, better documented and is not a quarter as constrained as Maven.

That said the Maven dependency model isn't too bad; fortunately you don't have to adopt Maven to get it, you can just use Ivy.

You've got that backwards. The "90s java mindset" is the lib dir. The 2011 approach is Maven, as evidenced by the fact that 100% of my clients use it, and practically every major open source project uses it as well.

Perfect? No. But standard practice? Yes.

Agreed. It's a problem, but VC just isn't built for dependency management.

Since the histories of the dependencies don't get tracked, merging them can be tricky. Especially when dependencies get upgraded separately by multiple people.

This is a legitimate question--but what if you need to support different versions of open source packages and you need to be sure that they will exist years later. This is something that I'm facing now in that I may be using numpy 1.2.x, but suppose someone else is using numpy 1.3.x and we all need to play well together in a distributed environment--the context needs to be stable. If I don't put this in source control, then where's a good place to stash it so that I can reconstruct the various contexts when I have to migrate to a different server?