." generated with Ronn/v0.7.3 ." github.com/rtomayko/ronn/tree/0.7.3 . .TH “DEP” “1” “April 2012” “” “” . .SH “NAME” fBDEPfR - basic dependency tracking . .SH “SYNOPSIS” . .nf

dep check dep add libname [--pre] dep rm libname dep install . .fi . .SH “DESCRIPTION” . .TP check Checks that all dependencies are met. . .TP add Fetches the latest version of the library in question and automatically adds it to your .gems file. . .TP rm Simply removes the corresponding entry in your .gems file. . .TP install Installs all the missing dependencies for you. An important point here is that it simply does a fBgem installfR for each dependency you have. Dep assumes that you use some form of sandboxing like gs, RVM or rbenv-gemset. . .SH “INSTALLATION” . .nf

$ gem install dep . .fi . .SH “HISTORY” dep is actually more of a workflow than a tool. If you think about package managers and the problem of dependencies, you can summarize what you absolutely need from them in just two points: . .IP “1.” 4 When you build an application which relies on 3rd party libraries, it's best to explicitly declare the version numbers of these libraries. . .IP “2.” 4 You can either bundle the specific library version together with your application, or you can have a list of versions. . .IP “” 0 . .P The first approach is handled by vendoring the library. The second approach typically is done using Bundler. But why do you need such a complicated tool when all you need is simply listing version numbers? . .P We dissected what we were doing and eventually reached the following workflow: . .IP “1.” 4 We maintain a .gems file for every application which lists the libraries and the version numbers. . .IP “2.” 4 We omit dependencies of dependencies in that file, the reason being is that that should already be handled by the package manager (typically rubygems). . .IP “3.” 4 Whenever we add a new library, we add the latest version. . .IP “4.” 4 When we pull the latest changes, we want to be able to rapidly check if the dependencies we have is up to date and matches what we just pulled. . .IP “” 0 . .P So after doing this workflow manually for a while, we decided to build the simplest tool to aid us with our workflow. . .IP “(bu” 4 The first point is handled implicitly by dep. You can also specify a different file by doing dep -f. . .IP “(bu” 4 The second point is more of an implementation detail. We thought about doing dependencies, but then, why re-implement something that's already done for you by rubygems? . .IP “(bu” 4 The third point (and also the one which is most inconvenient), is handled by dep add. . .IP “” 0 . .P The manual workflow for fBdep addfR would be: . .IP “” 4 . .nf

gem search -r “^ohm$” [--pre] # check and remember the version number echo “ohm -v X.x.x” >> .gems . .fi . .IP “” 0 . .P If you try doing that repeatedly, it will quickly become cumbersome. . .P The fourth and final point is handled by typing dep check or simply dep. Practically speaking it's just: . .P fBgit pull depfR . .P And that's it. The dep command typically happens in 0.2 seconds which is something we LOVE.