rubycut-babushka 0.10.6 → 0.10.8

Sign up to get free protection for your applications and to get access to all the features.
data/Gemfile.lock CHANGED
@@ -3,22 +3,22 @@ GEM
3
3
  specs:
4
4
  cloudservers (0.4.1)
5
5
  json
6
- diff-lcs (1.1.2)
6
+ diff-lcs (1.1.3)
7
7
  fuubar (0.0.6)
8
8
  rspec (~> 2.0)
9
9
  rspec-instafail (~> 0.1.8)
10
10
  ruby-progressbar (~> 0.0.10)
11
- json (1.5.3)
12
- rake (0.9.2)
13
- rspec (2.6.0)
14
- rspec-core (~> 2.6.0)
15
- rspec-expectations (~> 2.6.0)
16
- rspec-mocks (~> 2.6.0)
17
- rspec-core (2.6.4)
18
- rspec-expectations (2.6.0)
11
+ json (1.6.1)
12
+ rake (0.9.2.2)
13
+ rspec (2.7.0)
14
+ rspec-core (~> 2.7.0)
15
+ rspec-expectations (~> 2.7.0)
16
+ rspec-mocks (~> 2.7.0)
17
+ rspec-core (2.7.1)
18
+ rspec-expectations (2.7.0)
19
19
  diff-lcs (~> 1.1.2)
20
- rspec-instafail (0.1.8)
21
- rspec-mocks (2.6.0)
20
+ rspec-instafail (0.1.9)
21
+ rspec-mocks (2.7.0)
22
22
  ruby-progressbar (0.0.10)
23
23
 
24
24
  PLATFORMS
data/README.markdown CHANGED
@@ -23,124 +23,18 @@ A lot of the tech jobs we do manually aren't challenging or fun, but they're fin
23
23
 
24
24
  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.
25
25
 
26
+ ## Beginner
26
27
 
27
- # installing
28
28
 
29
- Installing is really easy on supported systems (currently, OS X and Ubuntu). 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.)
30
29
 
31
- If you have curl (OS X):
30
+ * {file:docs/deps.md Deps Guide} - Best place to start is it will teach you what deps is, and how to write one.
31
+ * {file:docs/templates.md Templating Guide} - generating (config) files files based on templates
32
+ * {file:docs/packages.md Packages guide} - Babushka can help you install gem, deb, rpm and other packages
33
+ * {file:docs/sources.md Sources Guide} - Where to save your deps and how to ditribute them
32
34
 
33
- bash -c "`curl babushka.me/up`"
34
-
35
- If you have wget (Ubuntu):
36
-
37
- bash -c "`wget -O - babushka.me/up`"
38
-
39
-
40
- # kicking the tyres
41
-
42
- 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`:
43
-
44
- babushka homebrew
45
-
46
- Or check that your rubygems install is looking good - latest version + gem sources. 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 for us:
47
-
48
- babushka rubygems
49
-
50
- 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.
51
-
52
- OK, something more complex now---a full nginx/passenger stack.
53
-
54
- babushka benhoskings:'webserver configured'
55
-
56
- Then you can set up each virtualhost with
57
-
58
- babushka benhoskings:'vhost configured'
59
-
60
- That's how I set up all 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!
61
-
62
-
63
- # nothing up my sleeve…
64
-
65
- 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.
66
-
67
- 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 how to efficiently use babushka's DSL, you'll be cranking out deps just like the `rubygems` and `homebrew` ones above.
68
-
69
-
70
- ## yeah, but how?
71
-
72
- 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.
73
-
74
- dep 'name' do
75
- requires 'other deps', 'whatever they might be'
76
- met? {
77
- # is this dependency already met?
78
- }
79
- meet {
80
- # this code gets run if it isn't.
81
- }
82
- end
83
-
84
- 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.
85
-
86
- 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.
87
-
88
- 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.
89
-
90
- dep 'llvm in path', :for => :snow_leopard do
91
- requires 'xcode tools'
92
- met? { which 'llvm-gcc-4.2' }
93
- meet {
94
- cd('/usr/local/bin') {|path|
95
- shell "ln -s /Developer/usr/llvm-gcc-4.2/bin/llvm* .", :sudo => !path.writable?
96
- }
97
- }
98
- end
99
-
100
- 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.
101
-
102
- 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.
103
-
104
- 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.
105
-
106
-
107
- ## let's get declarative
108
-
109
- 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.
110
-
111
- 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.
112
-
113
- 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.
114
-
115
- meta :tmbundle, :for => :osx do
116
- accepts_list_for :source
117
-
118
- template {
119
- requires 'TextMate.app'
120
- def path
121
- '~/Library/Application Support/TextMate/Bundles' / name
122
- end
123
- met? { path.dir? }
124
- before { shell "mkdir -p #{path.parent}" }
125
- meet {
126
- source.each {|uri|
127
- git uri, :to => path
128
- }
129
- }
130
- after { shell %Q{osascript -e 'tell app "TextMate" to reload bundles'} }
131
- }
132
- end
133
-
134
- 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 takes values defined by `accepts_list_for` (in this case, `source`) and produces regular deps at runtime under the covers.
135
-
136
- Given the `tmbundle` meta dep, this dep handles the cucumber bundle:
137
-
138
- dep 'Cucumber.tmbundle' do
139
- source 'git://github.com/bmabey/cucumber-tmbundle.git'
140
- end
141
-
142
- 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.
35
+ ## Advanced
143
36
 
37
+ * {file:docs/meta_deps.md Meta Deps Guide}
144
38
 
145
39
  # a runtime example
146
40
 
@@ -153,7 +47,7 @@ If you already have TextMate installed, babushka notices and just installs the b
153
47
  Found at /Applications/TextMate.app.
154
48
  } √ TextMate.app
155
49
  not already met.
156
- Cloning from git://github.com/bmabey/cucumber-tmbundle.git... done.
50
+ Cloning from https://github.com/bmabey/cucumber-tmbundle.git... done.
157
51
  Cucumber.tmbundle met.
158
52
  } √ Cucumber.tmbundle
159
53
 
@@ -170,43 +64,13 @@ But if you don't have TextMate, that's an unmet dependency, so it gets pulled in
170
64
  TextMate.app met.
171
65
  } √ TextMate.app
172
66
  not already met.
173
- Cloning from git://github.com/bmabey/cucumber-tmbundle.git... done.
67
+ Cloning from https://github.com/bmabey/cucumber-tmbundle.git... done.
174
68
  Cucumber.tmbundle met.
175
69
  } √ Cucumber.tmbundle
176
70
 
177
71
 
178
- ## dep sources
179
-
180
- 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.
181
-
182
- 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.
183
-
184
- 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.
185
-
186
- The best way manage your own source is to make <tt>~/.babushka/deps</tt> a git repo, and push it to <tt>git://github.com/username/babushka-deps.git</tt>.
187
-
188
- To run deps from others' sources, you don't need to add the source explicitly. Just prefix the dep name with the correct username:
189
-
190
- babushka freelancing-god:rvm
191
-
192
- The dep source will be cloned into <tt>~/.babushka/sources/freelancing-god</tt>, or updated if it's already there, and then babushka will search for a dep called "rvm" within that source. Because of this partitioning, you don't have to worry about naming conflicts with other people; everything is per-source.
193
-
194
- If you want to rename a source, or add one with a custom URL, you can add sources manually like this:
195
-
196
- babushka sources -a custom-name git://example.com/custom/url.git
197
-
198
- That will make the source available in <tt>~/.babushka/sources/custom-name</tt>.
199
-
200
- 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.
201
-
202
- 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.*
203
-
204
- 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>.
205
-
206
- 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.
207
-
208
72
 
209
- ## n.b.
73
+ ## WARNING
210
74
 
211
75
  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.
212
76
 
data/deps/babushka.rb CHANGED
@@ -73,7 +73,9 @@ dep 'in path.babushka', :from, :path do
73
73
  repo.path / '../bin'
74
74
  end
75
75
  setup {
76
- unmeetable "The binary path alongside babushka, #{bin_path}, isn't in your $PATH." unless ENV['PATH'].split(':').include?(bin_path)
76
+ unless ENV['PATH'].split(':').map {|p| p.chomp('/') }.include?(bin_path)
77
+ unmeetable "The binary path alongside babushka, #{bin_path}, isn't in your $PATH."
78
+ end
77
79
  }
78
80
  met? { which 'babushka' }
79
81
  prepare {
@@ -86,7 +88,7 @@ dep 'in path.babushka', :from, :path do
86
88
  end
87
89
 
88
90
  dep 'installed.babushka', :from, :path do
89
- from.default!("git://github.com/benhoskings/babushka.git")
91
+ from.default!("https://github.com/benhoskings/babushka.git")
90
92
 
91
93
  requires 'ruby', 'git'
92
94
  setup {
data/deps/homebrew.rb CHANGED
@@ -23,7 +23,7 @@ dep 'repo.homebrew' do
23
23
  end
24
24
  }
25
25
  meet {
26
- git "git://github.com/mxcl/homebrew.git" do
26
+ git "https://github.com/mxcl/homebrew.git" do
27
27
  log_shell "Gitifying #{path}", "cp -r .git '#{path}'"
28
28
  end
29
29
  }
data/deps/pkg_managers.rb CHANGED
@@ -73,7 +73,7 @@ dep 'npm' do
73
73
  end
74
74
 
75
75
  dep 'nodejs.src' do
76
- source 'git://github.com/joyent/node.git'
76
+ source 'https://github.com/joyent/node.git'
77
77
  provides 'node >= 0.4', 'node-waf'
78
78
  end
79
79
 
@@ -13,18 +13,26 @@ module Babushka
13
13
 
14
14
  def git_update uri, repo
15
15
  if !repo.exists?
16
- repo.clone! uri
16
+ update_and_log uri, repo, "Cloning #{uri} into #{repo.path}" do
17
+ repo.clone! uri
18
+ end
17
19
  else
18
- log_block "Updating #{uri}" do
19
- if repo.repo_shell('git fetch origin').nil?
20
- log_error " Couldn't fetch,", :newline => false
21
- elsif !repo.behind?
22
- log " Already up-to-date at #{repo.current_head.colorize('yellow')},", :newline => false
23
- true
24
- else
25
- log " #{repo.current_head.colorize('yellow')}..#{repo.repo_shell("git rev-parse --short origin/#{repo.current_branch}").colorize('yellow')} (#{repo.repo_shell("git log -1 --pretty=format:%s origin/#{repo.current_branch}").chomp('.')}),", :newline => false
26
- repo.reset_hard! "origin/#{repo.current_branch}"
27
- end
20
+ update_and_log uri, repo, "Updating #{repo.path} from #{uri}" do
21
+ repo.repo_shell('git fetch origin')
22
+ end
23
+ end
24
+ end
25
+
26
+ def update_and_log uri, repo, message, &block
27
+ log_block message do
28
+ if !block.call
29
+ # failed
30
+ elsif !repo.behind?
31
+ log " at #{repo.current_head.colorize('yellow')},", :newline => false
32
+ true
33
+ else
34
+ log " #{repo.current_head.colorize('yellow')}..#{repo.repo_shell("git rev-parse --short origin/#{repo.current_branch}").colorize('yellow')} (#{repo.repo_shell("git log -1 --pretty=format:%s origin/#{repo.current_branch}").chomp('.')}),", :newline => false
35
+ repo.reset_hard! "origin/#{repo.current_branch}"
28
36
  end
29
37
  end
30
38
  end
@@ -35,17 +35,17 @@ module Babushka
35
35
  end
36
36
 
37
37
  def self.default_remote_for name
38
- "git://github.com/#{name}/babushka-deps.git"
38
+ "https://github.com/#{name}/babushka-deps.git"
39
39
  end
40
40
 
41
41
  require 'uri'
42
42
  def self.discover_uri_and_type path
43
43
  if path.nil?
44
44
  [nil, :implicit]
45
- elsif path.to_s[/^(git|http|file):\/\//]
46
- [path.to_s, :public]
47
- elsif path.to_s[/^(\w+@)?[a-zA-Z0-9.\-]+:/]
45
+ elsif path.to_s.sub(/^\w+:\/\//, '')[/^[^\/]+[@:]/]
48
46
  [path.to_s, :private]
47
+ elsif path.to_s[/^(git|https?|file):\/\//]
48
+ [path.to_s, :public]
49
49
  else
50
50
  [path.p, :local]
51
51
  end
data/lib/babushka.rb CHANGED
@@ -1,5 +1,5 @@
1
1
  module Babushka
2
- VERSION = '0.10.6'
2
+ VERSION = '0.10.8'
3
3
  WorkingPrefix = '~/.babushka'
4
4
  SourcePrefix = '~/.babushka/sources'
5
5
  BuildPrefix = '~/.babushka/build'
@@ -19,19 +19,29 @@ describe Source do
19
19
  it "should label nil paths as implicit" do
20
20
  Source.discover_uri_and_type(nil).should == [nil, :implicit]
21
21
  end
22
- it "should work for public uris" do
22
+ it "should treat URLs containing auth info as private" do
23
+ [
24
+ 'http://ben@server.org/benhoskings/babushka.git',
25
+ 'https://ben:secret@server.org/benhoskings/babushka.git'
26
+ ].each {|uri|
27
+ Source.discover_uri_and_type(uri).should == [uri, :private]
28
+ }
29
+ end
30
+ it "should treat git:// and friends as public" do
23
31
  [
24
32
  'git://github.com/benhoskings/babushka-deps.git',
25
33
  'http://github.com/benhoskings/babushka-deps.git',
34
+ 'https://github.com/benhoskings/babushka-deps.git',
26
35
  'file:///Users/ben/babushka/deps'
27
36
  ].each {|uri|
28
37
  Source.discover_uri_and_type(uri).should == [uri, :public]
29
38
  }
30
39
  end
31
- it "should work for private uris" do
40
+ it "should treat ssh-style URLs as private" do
32
41
  [
33
42
  'git@github.com:benhoskings/babushka-deps.git',
34
- 'benhoskin.gs:~ben/babushka-deps.git'
43
+ 'benhoskin.gs:~ben/babushka-deps.git',
44
+ 'ben.local:/Users/ben/babushka-deps.git'
35
45
  ].each {|uri|
36
46
  Source.discover_uri_and_type(uri).should == [uri, :private]
37
47
  }
metadata CHANGED
@@ -1,13 +1,13 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: rubycut-babushka
3
3
  version: !ruby/object:Gem::Version
4
- hash: 59
4
+ hash: 39
5
5
  prerelease:
6
6
  segments:
7
7
  - 0
8
8
  - 10
9
- - 6
10
- version: 0.10.6
9
+ - 8
10
+ version: 0.10.8
11
11
  platform: ruby
12
12
  authors:
13
13
  - Ben Hoskings
@@ -16,7 +16,7 @@ autorequire:
16
16
  bindir: bin
17
17
  cert_chain: []
18
18
 
19
- date: 2011-11-13 00:00:00 Z
19
+ date: 2011-11-24 00:00:00 Z
20
20
  dependencies: []
21
21
 
22
22
  description: Babushka is a tool for finding, running, writing and sharing recipies to automate things.
@@ -203,7 +203,9 @@ files:
203
203
  homepage: https://github.com/rubycut/babushka
204
204
  licenses: []
205
205
 
206
- post_install_message:
206
+ post_install_message: "\n\
207
+ Gem install is not default type of installation.\n \n\
208
+ To install babushka properly, run this command:\n\n bash -c \"`curl babushka.me/up`\"\n\n See https://github.com/rubycut/babushka for details\n "
207
209
  rdoc_options: []
208
210
 
209
211
  require_paths: