rubycut-babushka 0.10.8 → 0.15.6.1

data/Gemfile

@@ -5,4 +5,5 @@ group :test do
   gem 'rspec'
   gem 'fuubar'
   gem 'cloudservers'
+  gem 'ir_b'
 end

data/Gemfile.lock

@@ -1,25 +1,26 @@
 GEM
   remote: http://rubygems.org/
   specs:
-    cloudservers (0.4.1)
+    cloudservers (0.4.2)
       json
     diff-lcs (1.1.3)
-    fuubar (0.0.6)
+    fuubar (1.1.0)
       rspec (~> 2.0)
-      rspec-instafail (~> 0.1.8)
-      ruby-progressbar (~> 0.0.10)
-    json (1.6.1)
+      rspec-instafail (~> 0.2.0)
+      ruby-progressbar (~> 1.0.0)
+    ir_b (1.5.0)
+    json (1.7.5)
     rake (0.9.2.2)
-    rspec (2.7.0)
-      rspec-core (~> 2.7.0)
-      rspec-expectations (~> 2.7.0)
-      rspec-mocks (~> 2.7.0)
-    rspec-core (2.7.1)
-    rspec-expectations (2.7.0)
-      diff-lcs (~> 1.1.2)
-    rspec-instafail (0.1.9)
-    rspec-mocks (2.7.0)
-    ruby-progressbar (0.0.10)
+    rspec (2.11.0)
+      rspec-core (~> 2.11.0)
+      rspec-expectations (~> 2.11.0)
+      rspec-mocks (~> 2.11.0)
+    rspec-core (2.11.1)
+    rspec-expectations (2.11.3)
+      diff-lcs (~> 1.1.3)
+    rspec-instafail (0.2.4)
+    rspec-mocks (2.11.3)
+    ruby-progressbar (1.0.2)
 
 PLATFORMS
   ruby
@@ -27,5 +28,6 @@ PLATFORMS
 DEPENDENCIES
   cloudservers
   fuubar
+  ir_b
   rake
   rspec

data/README.markdown

@@ -1,40 +1,132 @@
-# About this repo
+# babushka: test-driven sysadmin.
 
-While using this gem, keep in mind:
+- _docs: http://babushka.me_
+- _rdocs: http://babushka.me/rdoc_
 
-* This software is packaged as rubycut-babushka, since author asked us not to use babushka as gem name since he wants to keep only one way of installing babushka (see https://github.com/benhoskings/babushka/issues/173 for details)
-* by using this babushka as gem, it is not possible for babushka to configure ruby and rubygems 
-* switching the active rvm/rbenv ruby, or installing a new ruby that shadows the existing one, changes the set of gems that are in the path, which would make it look like babushka had disappeared.
-* lot of tools are confined to a single set of gems, or a single bundle. But babushka should exist outside of those things so it can configure them.
-* This is unstandard way to install babushka, standard way is explained at: http://babushka.me/installing
-* This gem is built using https://github.com/rubycut/babushka, we try to follow main repo but can not guearantee that we will produce gem same day official babushka version comes out
-* we will not be adding any new code to babhushka source code for now, but we will add more source documentation
+A lot of the tech jobs we do manually aren't challenging or fun, but they're quite particular and have to be done just right -- they're chores. Things that are important to do, but that are better automated than done manually.
 
+That's what babushka is for. Once you describe a job using its DSL, babushka can not only accomplish each part of the job, but also check if each part is already satisfied. For each component of the job, a test, along with the code to make that test pass -- test-driven sysadmin.
 
-## Development status
 
-This gem is not fully tested in realistic environment, although all the spec work.
+# installing
 
-# babushka: test-driven sysadmin.
+Installing is really easy. All it takes is one command, and it can be the first command you run on the machine. (Babushka will happily install on any machine though, not just new ones.)
+
+If you have curl (OS X):
+
+    bash -c "`curl babushka.me/up`"
+
+If you have wget (Ubuntu):
+
+    bash -c "`wget -O - babushka.me/up`"
+
+Babushka should run on any Unix. OS X and Ubuntu are fully supported, including their respective package managers, homebrew and apt. There is some yum (RedHat/Fedora/CentOS) and pacman (Arch) support, but I'm not familiar with those systems so it might be incomplete. Patches are most welcome.
+
+
+# kicking the tyres
+
+Once the install process has finished, you're ready to rock. If you have a Mac, maybe a good example is to install homebrew. To do that, we run the dependency (in babushka parlance, 'dep') called `homebrew`:
+
+    babushka homebrew
+
+Another example. Here's how you could check that your rubygems install is up to date and in the right place. This demonstrates how babushka works: it's the goal (rubygems set up well) that's important. You can safely run this whether rubygems is outdated, up to date, or missing, and babushka will work out what tasks need to be done in order to achieve the end goal. The `rubygems` dep handles that.
+
+    babushka rubygems
+
+Things like rubygems and homebrew aren't hard to install on their own, but with babushka it's _really_ easy, and _fast_. But more importantly, you know the job is being done just right, every time.
+
+(These deps aren't special, they're just bundled along with babushka because I like to ship package manager support.)
+
+OK, something more complex now---a vhosting nginx. Since there's not much point configuring nginx until it's installed, this dep `requires` another called `nginx.src` that does the actual install (i.e. downloading and building the source). That means calling this one will include the installation if it's not already present (i.e. if `nginx.src` is unmet).
+
+    babushka benhoskings:'configured.nginx'
+
+Then you can set up each virtualhost with another dep (which itself requires `configured.nginx`). In fact, you could call just this one, and leave the one above: configuring a vhost requires the global config, which in turn requires the install.
+
+The idea is that you can talk solely about your actual goal, without regard for the dependencies -- they'll all be pulled in as required.
+
+    babushka benhoskings:'vhost configured.nginx'
+
+That's how I set up my production machines. If something isn't working, you have a list of things that _aren't_ the culprit: everything in the output with a green ✓ beside it. Conversely, if babushka can detect the problem, the failing dep will have a red ✗ beside it instead, which leads you straight to the cause of the problem. Test-driven sysadmin!
+
+
+# nothing up my sleeve…
+
+Creating and sharing this knowledge is central to babushka. It's all very well to run `babushka rubygems` and have it do a job for you, but the real power is in babushka's ability to automate whatever chore you want, not just ones that others have thought of already.
+
+To that end, I've tried really hard to make the process quick and satisfying. If you spend a little bit of time getting the feel for babushka's DSL, you'll be cranking out deps just like the rubygems, homebrew, and nginx ones above.
+
+
+## yeah, but how?
 
-When you spend time researching something new, it's pretty easy to forget what you found, and have to re-research it again next time.
+A dep is one single piece of a larger task. A little nugget of code that does just one thing, and does it right. Here's a babushka dep, at its most generic.
 
-A lot of the tech jobs we do manually aren't challenging or fun, but they're finicky and have to be done just right. They're chores. Things that are important to do, but that are better automated than done manually by us people, right? After all, that's what is supposed to happen in the future. And the future is good, because in the future, we'll all have jetpants. So, onward.
+    dep 'name', :argument do
+      requires 'other deps'.with('args'), 'whatever they might be'
+      met? {
+        # is this dependency already met?
+      }
+      meet {
+        # this code gets run if it isn't.
+      }
+    end
 
-The idea is this: you take a job that you'd rather not do manually, and describe it to babushka using its DSL. The way it works, babushka not only knows how to accomplish each part of the job, it also knows how to check if each part is already done. You're teaching babushka to achieve an end goal with whatever runtime conditions you throw at it, not just to perform the task that would get you there from the very start.
+The important bit here is that when you're writing a dep, you don't have to think about context at all, just the one little task it's doing in isolation. As long as your `requires` are correct, you can leave the overall structure to babushka and just write each little dep separately. When you run `babushka name`, babushka uses the `requires` in each dep to assemble a tree of deps and achieve the end goal you're after.
 
-## Beginner
+The idea is to keep a clean separation between `met?` and `meet`: the code in `met?` should do nothing except just check whether the dep is met and return a boolean, and `meet` should unconditionally satisfy the dep without doing any checks.
 
+Right, here's one I prepared earlier. Given you're on a Mac with Xcode installed, this dep knows how to achieve the goal of having llvm available in the PATH.
 
+    dep 'llvm in path', :for => :snow_leopard do
+      requires 'xcode tools'
+      met? { which 'llvm-gcc-4.2' }
+      meet {
+        cd('/usr/local/bin') {|path|
+          shell "ln -s /Developer/usr/llvm-gcc-4.2/bin/llvm* .", :sudo => !path.writable?
+        }
+      }
+    end
 
-* {file:docs/deps.md Deps Guide} - Best place to start is it will teach you  what deps is, and how to write one.
-* {file:docs/templates.md Templating Guide} - generating (config) files files based on templates
-* {file:docs/packages.md Packages guide} - Babushka can help you install gem, deb, rpm and other packages
-* {file:docs/sources.md Sources Guide} - Where to save your deps and how to ditribute them
+All the common logic is handled by babushka, which means that all the code in the dep is specific to the job at hand. The idea is maximising that signal-to-noise ratio: as much of the code in the dep above should be talking about llvm, not about other things that can be inferred elsewhere.
 
-## Advanced
+Notice that there's no conditional or nested logic within the dep. That's by design: the more declarative things are, the more composable and re-interpretable they are later.
+
+If you find you're checking for the presence of some condition in your `meet` block, it probably means you're trying to do too much in a single dep, and you should be splitting it up into smaller ones. Remember, deps are small, self-contained and context-free - the more focused, the better.
+
+
+## let's get declarative
+
+The basic dep, with just `requires`, `met?` and `meet`, is all you need to describe an end goal. But this generic nature of `met?` and `meet` means just as they're general purpose, they can lack focus. For example, installing an app using the system's package manager has a predictable `met?` block---check whether the package is present and its binaries are in the path.
+
+A lot of chores are variations on a theme like this, or just too cumbersome to do repeatedly at a low level. So babushka provides a way to write dep templates, or _meta deps_, that can be reused later. These meta deps allow you to focus the DSL, and make it even more concise.
+
+For example, Babushka ships with a meta dep that knows how to install TextMate bundles, given just the URL. All the actual logic, including the code for `met?` and `meet`, is wrapped up in the meta dep.
+
+    meta :tmbundle, :for => :osx do
+      accepts_value_for :source
+
+      template {
+        requires 'TextMate.app'
+        def path
+          '~/Library/Application Support/TextMate/Bundles' / name
+        end
+        met? { path.dir? }
+        before { path.parent.mkdir }
+        meet { git source, :to => path }
+        after { shell %Q{osascript -e 'tell app "TextMate" to reload bundles'} }
+      }
+    end
+
+Notice how the contents of the `template` block looks like a normal dep. That's cause it is---the meta dep is a factory, that accepts a value defined by `accepts_value_for` (in this case, `source`) and produces regular deps at runtime under the covers.
+
+Given the `tmbundle` meta dep, this dep handles the cucumber bundle:
+
+    dep 'Cucumber.tmbundle' do
+      source 'https://github.com/bmabey/cucumber-tmbundle.git'
+    end
+
+Notice there's no imperative code there at all---just declarations. That's what the DSL aims for. Instead of saying "do this, then do this, then do this", the code should say "here's a description of the problem, now you work it out." Also notice that there's no TextMate-specific logic. Adding this extra level of abstraction means all that's left are the specifics for _this_ TextMate bundle.
 
-* {file:docs/meta_deps.md Meta Deps Guide}
 
 # a runtime example
 
@@ -45,32 +137,62 @@ If you already have TextMate installed, babushka notices and just installs the b
     Cucumber.tmbundle {
       TextMate.app {
         Found at /Applications/TextMate.app.
-      } √ TextMate.app
-      not already met.
-      Cloning from https://github.com/bmabey/cucumber-tmbundle.git... done.
-      Cucumber.tmbundle met.
-    } √ Cucumber.tmbundle
+      } ✓ TextMate.app
+      meet {
+        Cloning from https://github.com/bmabey/cucumber-tmbundle.git... done.
+      }
+    } ✓ Cucumber.tmbundle
 
 But if you don't have TextMate, that's an unmet dependency, so it gets pulled in too.
 
     Cucumber.tmbundle {
       TextMate.app {
-        not already met.
-        Downloading http://download-b.macromates.com/TextMate_1.5.9.dmg... done.
-        Attaching TextMate_1.5.9.dmg... done.
-        Found TextMate.app in the DMG, copying to /Applications... done.
-        Detaching TextMate_1.5.9.dmg... done.
+        meet {
+          Downloading http://download-b.macromates.com/TextMate_1.5.9.dmg... done.
+          Attaching TextMate_1.5.9.dmg... done.
+          Found TextMate.app in the DMG, copying to /Applications... done.
+          Detaching TextMate_1.5.9.dmg... done.
+        }
         Found at /Applications/TextMate.app.
-        TextMate.app met.
-      } √ TextMate.app
-      not already met.
-      Cloning from https://github.com/bmabey/cucumber-tmbundle.git... done.
-      Cucumber.tmbundle met.
-    } √ Cucumber.tmbundle
+      } ✓ TextMate.app
+      meet {
+        Cloning from https://github.com/bmabey/cucumber-tmbundle.git... done.
+      }
+    } ✓ Cucumber.tmbundle
+
+
+## dep sources
+
+Babushka only contains the deps that it needs to know how to install itself, and set up a bare minimum of software like package managers, `ruby` and `git`. Everything else is stored separately, in _dep sources_. A dep source is a babushka-managed git repo that contains a bunch of ruby files.
+
+The organisation and naming of the files within the source is completely up to you - babushka will recursively load all the .rb files it can find in the source, in alphabetical order.
+
+You can define deps and templates in the same source, arranged however you like. You don't have to worry about having templates loaded before deps that are defined against them, because the load is a two-stage process that first reads every file and sets up the templates, and then defines all the deps that were found.
+
+The best way manage your own source is to make <tt>~/.babushka/deps</tt> a git repo, and push it to <tt>https://github.com/username/babushka-deps.git</tt>.
+
+To run deps from others' sources, you don't need to add the source explicitly. Just prefix the dep name with the correct username:
+
+    babushka conversation:coffeescript.src
+
+The dep source will be cloned into <tt>~/.babushka/sources/conversation</tt>, or updated if it's already there, and then babushka will search for a dep called "coffeescript" within that source. Because of this partitioning, you don't have to worry about naming conflicts with other people; everything is per-source.
+
+If you want to rename a source, or add one with a custom URL, you can add sources manually like this:
+
+    babushka sources -a custom-name git://example.com/custom/url.git
+
+That will make the source available in <tt>~/.babushka/sources/custom-name</tt>.
+
+There's no configuration file for dep sources; the only state is stored in the contents of <tt>~/.babushka/sources</tt>. Specifically, the source names are the directory names, and the URLs are the locations of the corresponding 'origin' git remotes.
+
+Because of this, you can safely add, remove, rename and edit the directories and repositories in there as much as you like---but importantly, *babushka assumes it has free run of <tt>~/.babushka/sources</tt>, and won't hesitate to `git reset --hard`. If you leave uncommitted or unpushed changes in a source, they'll be lost when that source is updated.*
+
+If you want to write deps just for yourself that you don't plan to push online, just drop them in <tt>~/.babushka/deps</tt>. If you'd rather keep them elsewhere, like in <tt>~/src</tt> or similar, you can symlink the directory into <tt>~/.babushka/deps</tt>.
 
+Finally, babushka also loads deps from `./babushka-deps` in the directory from which it was run. This is a good place for project-specific deps, because you can keep them within the project's source control.
 
 
-## WARNING
+## n.b.
 
 A dep can run any code. Run deps of unknown origin at your own risk, and when choosing deps and dep sources, use the only real security there is: a network of trust.
 
@@ -105,6 +227,6 @@ Thanks to my rubyist friends who've helped with brainstorming and testing---the
 
 Babushka is licensed under the BSD license, except for the following exception:
 
-lib/support/levenshtein.rb, which is licensed under the MIT license.
+lib/levenshtein/levenshtein.rb, which is licensed under the MIT license.
 
-The BSD license can be found in full in the LICENSE file, and the MIT license at the top of lib/support/levenshtein.rb.
+The BSD license can be found in full in the LICENSE file, and the MIT license at the top of lib/levenshtein/levenshtein.rb.

data/Rakefile

@@ -14,7 +14,7 @@ RSpec::Core::RakeTask.new('acceptance') {|t|
 
 desc 'Profile the spec suite'
 RSpec::Core::RakeTask.new('profile') {|t|
-  t.rspec_opts = %w[--colour --profile]
+  t.rspec_opts = ['--colour', '--format Fuubar', '--profile']
 }
 
 desc 'Run code coverage'

data/bin/babushka

@@ -8,4 +8,4 @@ Object.send :include, Babushka::DSL
 Babushka::Base.exit_on_interrupt!
 
 # Invoke babushka, returning the correct exit status to the shell.
-exit !!Babushka::Base.run
+exit !!Babushka::Base.run

data/deps/apt.rb

@@ -0,0 +1,44 @@
+dep 'apt source', :uri, :release, :repo do
+  uri.default!(Babushka::AptHelper.source_for_system)
+  release.default!(Babushka.host.name)
+
+  def present_in_file? filename
+    filename.p.exists? &&
+    # e.g. deb http://au.archive.ubuntu.com/ubuntu/ natty main restricted
+    filename.p.read[/^deb\s+#{Regexp.escape(uri)}\s+#{release}\b.*\b#{repo}\b/]
+  end
+
+  met? {
+    present_in_file?('/etc/apt/sources.list') or
+      Dir.glob("/etc/apt/sources.list.d/*").any? {|f| present_in_file?(f) }
+  }
+  meet {
+    '/etc/apt/sources.list.d/babushka.list'.p.append("deb #{uri} #{release} #{repo}\n")
+  }
+  after {
+    Babushka::AptHelper.update_pkg_lists "Updating apt lists to load #{uri}."
+  }
+end
+
+dep 'ppa', :spec do
+  requires 'python-software-properties.bin'
+  def spec_name
+    log_error("'#{spec}' doesn't look like 'ppa:something'.") unless spec[/^ppa\:\w+/]
+    spec.to_s.sub(/^ppa\:/, '')
+  end
+  def ppa_release_file
+    # This may be hardcoded to some extent, but I'm calling YAGNI on it for now.
+    "ppa.launchpad.net_#{spec_name.gsub('/', '_')}_ubuntu_dists_#{Babushka.host.name}_Release"
+  end
+  met? {
+    ('/var/lib/apt/lists/' / ppa_release_file).exists?
+  }
+  meet {
+    log_shell "Adding #{spec}", "add-apt-repository '#{spec}'", :spinner => true
+    log_shell "Updating apt lists to load #{spec}.", "apt-get update"
+  }
+end
+
+dep 'python-software-properties.bin' do
+  provides 'add-apt-repository'
+end

data/deps/babushka.rb

@@ -2,68 +2,80 @@ meta :babushka do
   def repo
     Babushka::GitRepo.new(path)
   end
+
+  def qualified_ref
+    # Prepend "origin/" we're installing from scratch, or if the result is a
+    # valid remote branch.
+    if repo.exists? && repo.all_branches.include?("origin/#{ref}")
+      "origin/#{ref}"
+    else
+      ref
+    end
+  end
+
+  def resolved_ref
+    repo.resolve(qualified_ref)
+  end
 end
 
-dep 'babushka', :from, :path, :branch do
-  requires 'up to date.babushka'.with(from, path, branch)
+dep 'babushka', :from, :path, :version, :branch do
+  ref = if branch.set?
+    deprecated! '2012-12-20', :method_name => "the :branch parameter to 'babushka'", :instead => ':version'
+    branch
+  else
+    version.default!('master')
+  end
+  requires 'up to date.babushka'.with(from, path, ref)
   requires 'in path.babushka'.with(from, path)
   path.ask("Where would you like babushka installed").default('/usr/local/babushka')
   path.default!(Babushka::Path.path) if Babushka::Path.run_from_path?
-  branch.default!('master')
 end
 
-dep 'up to date.babushka', :from, :path, :branch do
+dep 'up to date.babushka', :from, :path, :ref do
   requires 'repo clean.babushka'.with(from, path)
-  requires 'update would fast forward.babushka'.with(from, path, branch)
+  requires 'resolvable ref.babushka'.with(from, path, ref)
+
   met? {
-    (!repo.behind?).tap {|result|
+    (repo.current_head == resolved_ref).tap {|result|
       if result
-        log_ok "babushka is up to date at revision #{repo.current_head}."
+        log_ok "babushka is up to date at #{repo.current_head}."
       else
-        log "babushka can be updated: #{repo.current_head}..#{repo.repo_shell("git rev-parse --short origin/#{branch}")}"
+        log "babushka can be updated: #{repo.current_head}..#{resolved_ref}"
       end
     }
   }
   meet {
-    log "#{repo.repo_shell("git diff --stat #{repo.current_head}..origin/#{branch}")}"
-    repo.reset_hard! "origin/#{branch}"
+    log "#{repo.repo_shell("git diff --stat #{repo.current_head}..#{resolved_ref}")}"
+    repo.detach!(resolved_ref)
   }
 end
 
-dep 'update would fast forward.babushka', :from, :path, :branch do
-  requires 'on correct branch.babushka'.with(from, path, branch)
+dep 'repo clean.babushka', :from, :path do
+  requires 'installed.babushka'.with(from, path)
   met? {
-    if !repo.repo_shell('git fetch origin')
-      unmeetable "Couldn't pull the latest code - check your internet connection."
-    else
-      if !repo.remote_branch_exists?
-        unmeetable "The current branch, #{repo.current_branch}, isn't pushed to origin/#{repo.current_branch}."
-      elsif repo.ahead?
-        unmeetable "There are unpushed commits in #{repo.current_branch}."
-      else
-        true
-      end
-    end
+    repo.clean? or unmeetable!("There are local changes in #{repo.path}.")
   }
 end
 
-dep 'on correct branch.babushka', :from, :path, :branch do
-  requires 'branch exists.babushka'.with(from, path, branch)
-  requires_when_unmet 'repo clean.babushka'.with(from, path)
-  met? { repo.current_branch == branch.to_s }
-  meet { repo.checkout! branch }
-end
-
-dep 'branch exists.babushka', :from, :path, :branch do
-  requires 'installed.babushka'.with(from, path)
-  met? { repo.branches.include? branch.to_s }
-  meet { repo.track! "origin/#{branch}" }
-end
-
-dep 'repo clean.babushka', :from, :path do
-  requires 'installed.babushka'.with(from, path)
+dep 'resolvable ref.babushka', :from, :path, :ref do
   met? {
-    repo.clean? or unmeetable("There are local changes in #{repo.path}.")
+    if !@fetched && qualified_ref['origin/']
+      false # Always fetch before resolving a remote ref.
+    else
+      resolved_ref.tap {|result|
+        if result
+          log_ok "#{ref} resolves to #{result}."
+        else
+          log "#{ref} doesn't resolve to a ref."
+        end
+      }
+    end
+  }
+  meet {
+    log_block "Fetching #{from}", :failure => "failed, check your internet connection." do
+      @fetched = true
+      repo.repo_shell?('git fetch origin')
+    end
   }
 end
 
@@ -74,12 +86,12 @@ dep 'in path.babushka', :from, :path do
   end
   setup {
     unless ENV['PATH'].split(':').map {|p| p.chomp('/') }.include?(bin_path)
-      unmeetable "The binary path alongside babushka, #{bin_path}, isn't in your $PATH."
+      unmeetable! "The binary path alongside babushka, #{bin_path}, isn't in your $PATH."
     end
   }
   met? { which 'babushka' }
   prepare {
-    unmeetable "The current user, #{shell('whoami')}, can't write to #{bin_path} (to symlink babushka into the path)." unless bin_path.hypothetically_writable?
+    unmeetable! "The current user, #{shell('whoami')}, can't write to #{bin_path} (to symlink babushka into the path)." unless bin_path.hypothetically_writable?
   }
   meet {
     bin_path.mkdir
@@ -92,7 +104,7 @@ dep 'installed.babushka', :from, :path do
 
   requires 'ruby', 'git'
   setup {
-    unmeetable "The current user, #{shell('whoami')}, can't write to #{repo.path}." unless repo.path.hypothetically_writable?
+    unmeetable! "The current user, #{shell('whoami')}, can't write to #{repo.path}." unless repo.path.hypothetically_writable?
   }
   met? { repo.exists? }
   meet {