dep 1.0.0 → 1.0.1

data/README.1

@@ -0,0 +1,115 @@
+.\" generated with Ronn/v0.7.3
+.\" http://github.com/rtomayko/ronn/tree/0.7.3
+.
+.TH "DEP" "1" "April 2012" "" ""
+.
+.SH "NAME"
+\fBDEP\fR \- 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 install\fR 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 add\fR 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 dep\fR
+.
+.P
+And that\'s it\. The dep command typically happens in 0\.2 seconds which is something we LOVE\.

data/bin/dep

@@ -5,7 +5,7 @@ require_relative "../lib/dep"
 require "fileutils"
 require "clap"
 
-help = File.expand_path("../README", File.dirname(__FILE__))
+help = File.expand_path("../README.1", File.dirname(__FILE__))
 file = nil
 
 commands = Clap.run ARGV,
@@ -72,7 +72,7 @@ end
 
 commands = Clap.run commands,
   "--pre"  => lambda { @prerelease = true },
-  "--help" => lambda { exec "${PAGER:-less} #{help}" }
+  "--help" => lambda { exec "man #{help}" }
 
 Clap.run commands,
   "add"     => method(:add),

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: dep
 version: !ruby/object:Gem::Version
-  version: 1.0.0
+  version: 1.0.1
   prerelease: 
 platform: ruby
 authors:
@@ -10,11 +10,11 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2012-03-28 00:00:00.000000000 Z
+date: 2012-04-03 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: clap
-  requirement: &70327220901300 !ruby/object:Gem::Requirement
+  requirement: &70133804725260 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ~>
@@ -22,7 +22,7 @@ dependencies:
         version: 0.0.2
   type: :runtime
   prerelease: false
-  version_requirements: *70327220901300
+  version_requirements: *70133804725260
 description: Specify your project's dependencies in one file.
 email:
 - cyx.ucron@gmail.com
@@ -32,7 +32,7 @@ executables:
 extensions: []
 extra_rdoc_files: []
 files:
-- README
+- README.1
 - bin/dep
 - lib/dep.rb
 - test/dep.rb

data/README

@@ -1,89 +0,0 @@
-DEP(1)
-
-NAME
-      dep -- Basic dependency tracking
-
-SYNOPSIS
-      dep check
-      dep add libname [--pre]
-      dep rm libname
-      dep install
-
-DESCRIPTION
-      check
-          Checks that all dependencies are met.
-
-      add
-          Fetches the latest version of the library in question
-          and automatically adds it to your .gems file.
-
-      rm
-          Simply removes the corresponding entry in your .gems file.
-
-      install
-          Installs all the missing dependencies for you. An important
-          point here is that it simply does a `gem install` for each
-          dependency you have. Dep assumes that you use some form of
-          sandboxing like RVM or rbenv-gemset.
-
-
-INSTALLATION
-      $ gem install dep
-
-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:
-
-      1. When you build an application which relies on 3rd party libraries,
-         it's best to explicitly declare the version numbers of these
-         libraries.
-
-      2. You can either bundle the specific library version together with
-         your application, or you can have a list of versions.
-
-      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?
-
-      We dissected what we were doing and eventually reached the following
-      workflow:
-
-      1. We maintain a .gems file for every application which lists the
-         libraries and the version numbers.
-      2. We omit dependencies of dependencies in that file, the reason being
-         is that that should already be handled by the package manager
-         (typically rubygems).
-      3. Whenever we add a new library, we add the latest version.
-      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.
-
-      So after doing this workflow manually for a while, we decided to
-      build the simplest tool to aid us with our workflow.
-
-      The first point is handled implicitly by dep. You can also specify
-      a different file by doing dep -f.
-
-      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?
-
-      The third point (and also the one which is most inconvenient), is
-      handled by dep add.
-
-      The manual workflow for that would be:
-
-      gem search -r "^ohm$" [--pre] # check and remember the version number
-      echo "ohm -v X.x.x" >> .gems
-
-      If you try doing that repeatedly, it will quickly become cumbersome.
-
-      The fourth and final point is handled by typing dep check or simply dep.
-      Practically speaking it's just:
-
-      git pull
-      dep
-
-      And that's it. The dep command typcially happens in 0.2 seconds which
-      is something we LOVE.