getting started with babushka

[tcurdt]

Recently I started playing with babushka (to setup my vserver) ...and I've run into a couple of question/issues. As promised to Ben on twitter here is rub:

1. It seems like babushka has some "internal deps" (e.g. 'admins can sudo') which so wasn't obvious.

2. Question this brings up - what happens when there is a clash? Seems it gets silently overridden.

3. Permissions and ownerships. All the deps I found so far have an horrific absence of chmod/chown. A couple of dep call them via shell. In the nginx dep I found

  cd cert_path, :create => "700", :sudo => true do

which when looking at the implementation does not set the permissions as I would have expect. Why not have a :perms and :owner? Or how should one create directory structures?

4. Either I have missed it - but I have not found a description about how "meta" deps are working. Looking the "rbenv" dep I am not sure I fully understand this yet

    meta :rbenv do

      accepts_value_for :version, :basename

      accepts_value_for :patchlevel

      accepts_block_for :customise

      template {

       ...

      }

    end

    dep '1.9.2.rbenv' do

      patchlevel 'p290'

    end

5. Which also brings me to the naming conventions. ".configured", ".managed", ".bin" ...and what's the "1.9.2.rbenv" - almost looks empty. Would be good get some docs/info together on that.

6. Variables I found covered in one of Ben's blog post. There currently is http://babushka.me/running-deps but that does not explain

  dep 'dot files', :username, :github_user, :repo do

  ...and while it point to http://babushka.me/writing-deps for more info - well... that desperately needs some documentation love.

7. How do you guys use babushka with "sudo"? Run babushka itself with sudo or as root? No way in hell it make sense to type in the password for every "sudo" (why doesn't that cached after the first sudo?)

8. Is there somewhere full documentation on the DSL? Right now one has to dig through the code.

I think that's it for now :)

cheers,

Torsten

[tcurdt]

Hm. I have this dep

    dep 'homedir repo', :username, :github_user, :repo do

      username.default!(shell('whoami'))

      github_user.default!(username)

      repo.default!('homedir')

      source "git://github.com/#{username}/#{repo}.git"

    end

Why does this give a

    homedir repo {

      undefined method `source' for #<Babushka::DepContext:0x92ed534>

isn't "source" part of the core? ...and it's being used by so many other deps.

/me is confused

[Ben Hoskings]

Thanks for sending these through, I'll write up a proper reply later in the day. A bit under the pump at work right now.

Cheers
Ben

> --
> To post, email babush...@googlegroups.com
> To unsubscribe, email babushka_app...@googlegroups.com
> ~
> http://babushka.me
> http://github.com/benhoskings/babushka
> http://groups.google.com/group/babushka_app

[Ben Hoskings]

Hi Torsten, thanks again for posting these.

On 19/07/2012, at 6:35 AM, tcurdt wrote:

> Recently I started playing with babushka (to setup my vserver) ...and I've run into a couple of question/issues. As promised to Ben on twitter here is rub:
>
> 1. It seems like babushka has some "internal deps" (e.g. 'admins can sudo') which so wasn't obvious.

You can see them all with `babushka list`, or filter it, e.g. `babushka list sudo`. That's documented by `babushka help`.

> 2. Question this brings up - what happens when there is a clash? Seems it gets silently overridden.

Deps are never overridden. Within a source, a given name will always define (or augment) the same dep. Across sources, deps are independent: you just namespace them with the source name.

In the case above, you'd use 'core:admins can sudo', as is printed by `babushka list`.

> 3. Permissions and ownerships. All the deps I found so far have an horrific absence of chmod/chown. A couple of dep call them via shell. In the nginx dep I found
>
> cd cert_path, :create => "700", :sudo => true do
>
> which when looking at the implementation does not set the permissions as I would have expect. Why not have a :perms and :owner? Or how should one create directory structures?

Most deps purposefully don't chown, except where ownership change is the actual purpose of the dep. The intention is that babushka is invoked by the user in question, so ownership naturally falls into place.

Permissions are a separate issue, and you're right about :create, that's probably not the best name.

In general though, the same thing applies: the idea is to invoke babushka as the user in question, so that changing ownership isn't relevant within the scope of the deps you're running.

> 4. Either I have missed it - but I have not found a description about how "meta" deps are working. Looking the "rbenv" dep I am not sure I fully understand this yet
>
> meta :rbenv do
> accepts_value_for :version, :basename
> accepts_value_for :patchlevel
> accepts_block_for :customise
> template {
> ...
> }
> end
>
> dep '1.9.2.rbenv' do
> patchlevel 'p290'
> end

This core code explains the function of `accepts_list_for` and friends:

http://github.com/benhoskings/babushka/blob/master/lib/babushka/dep_context.rb

They define methods on the dep that will accept specific data types. The other purpose of a template is to define baked-in met?{} and meet{} blocks, to wrap up the logic for that type of dep (those are overrideable later).

In that case, met?{} and meet{} aren't missing, they're just defaulting to those in the template, using the customised 'patchlevel' value.

Another example is '.bin'. If the package name and binary name match the dep name, you can just declare, e.g.

dep 'curl.bin'

And you're done: all the logic defaults to that in the template. You can still open the block and customise as much of it as you like though.

> 5. Which also brings me to the naming conventions. ".configured", ".managed", ".bin" ...and what's the "1.9.2.rbenv" - almost looks empty. Would be good get some docs/info together on that.

I don't have a '.configured' anywhere, but the suffix just matches a template name. A dep called 'curl.bin' is defined against the 'bin' template.

> 6. Variables I found covered in one of Ben's blog post. There currently is http://babushka.me/running-deps but that does not explain
>
> dep 'dot files', :username, :github_user, :repo do
>
> ...and while it point to http://babushka.me/writing-deps for more info - well... that desperately needs some documentation love.

Yep, the docs need work. I'm sorry, I'm very busy. :)

There are plenty of examples of parameter use in the core deps. In that case, you could do, on the command line:

babushka 'dot files' github_user=benhoskings ...

Or, in a dep:
requires 'dot files'.with('ben', 'benhoskings', 'dot-files')

Or
requires 'dot files'.with(username: 'ben')

> 7. How do you guys use babushka with "sudo"? Run babushka itself with sudo or as root? No way in hell it make sense to type in the password for every "sudo" (why doesn't that cached after the first sudo?)

Either will work fine, you can use whichever you like.

The repetitive password typing isn't specific to babushka; it's a result of the way `sudo` is configured on newer versions of ubuntu and friends, and affects many other apps to. It's unfortunate.

> 8. Is there somewhere full documentation on the DSL? Right now one has to dig through the code.

The docs are at http://babushka.me and the rdocs are at http://rubydoc.info/github/benhoskings/babushka/master/frames -- but yeah, reading the code is the only complete reference.

- Ben

[Torsten Curdt]

Hey Ben,

thanks for getting back to me so quickly - despite the fact you are busy.

>> 1. It seems like babushka has some "internal deps" (e.g. 'admins can sudo') which so wasn't obvious.
>
> You can see them all with `babushka list`, or filter it, e.g. `babushka list sudo`. That's documented by `babushka help`.

Yeah, found that. It's really just a "getting started" problem.

>> 2. Question this brings up - what happens when there is a clash? Seems it gets silently overridden.
>
> Deps are never overridden. Within a source, a given name will always define (or augment) the same dep. Across sources, deps are independent: you just namespace them with the source name.
>
> In the case above, you'd use 'core:admins can sudo', as is printed by `babushka list`.

Well, it seems like if there is no 'admins can sudo' in my source it
falls back to 'core:admins can sudo'.
If I define 'admins can sudo' in my source that one is used - not
'core:admins can sudo'.
So I am not really "overriding" but I hope you see my point?

>> 3. Permissions and ownerships. All the deps I found so far have an horrific absence of chmod/chown. A couple of dep call them via shell. In the nginx dep I found
>>
>> cd cert_path, :create => "700", :sudo => true do
>>
>> which when looking at the implementation does not set the permissions as I would have expect. Why not have a :perms and :owner? Or how should one create directory structures?
>
> Most deps purposefully don't chown, except where ownership change is the actual purpose of the dep. The intention is that babushka is invoked by the user in question, so ownership naturally falls into place.

That's a nice idea - but how does that work when you setup a full
machine (including users) or run as root because of the 'sudo' thing?
I fear it falls down for certain but common use cases.

> Permissions are a separate issue, and you're right about :create, that's probably not the best name.

Well, the name is not the problem. The code just checks for :create
but does not use the passed in string to chmod. The dep above just
creates the dir but will not give it 700 permissions ...unless I am
missing something.

>> 4. Either I have missed it - but I have not found a description about how "meta" deps are working. Looking the "rbenv" dep I am not sure I fully understand this yet

..snip...

> This core code explains the function of `accepts_list_for` and friends:
>
> http://github.com/benhoskings/babushka/blob/master/lib/babushka/dep_context.rb
>
> They define methods on the dep that will accept specific data types. The other purpose of a template is to define baked-in met?{} and meet{} blocks, to wrap up the logic for that type of dep (those are overrideable later).
>
> In that case, met?{} and meet{} aren't missing, they're just defaulting to those in the template, using the customised 'patchlevel' value.
>
> Another example is '.bin'. If the package name and binary name match the dep name, you can just declare, e.g.
>
> dep 'curl.bin'
>
> And you're done: all the logic defaults to that in the template. You can still open the block and customise as much of it as you like though.

OK, think I got it. The only thing that creeps me out is that it's
apparently based on matching the dep's name. Why not have that as part
of the dsl instead?

>> 5. Which also brings me to the naming conventions. ".configured", ".managed", ".bin" ...and what's the "1.9.2.rbenv" - almost looks empty. Would be good get some docs/info together on that.
>
> I don't have a '.configured' anywhere, but the suffix just matches a template name. A dep called 'curl.bin' is defined against the 'bin' template.

OK (nod)

>> 6. Variables I found covered in one of Ben's blog post. There currently is http://babushka.me/running-deps but that does not explain
>>
>> dep 'dot files', :username, :github_user, :repo do
>>
>> ...and while it point to http://babushka.me/writing-deps for more info - well... that desperately needs some documentation love.
>
> Yep, the docs need work. I'm sorry, I'm very busy. :)

Who isn't :) ...but I'll see if I can turn my learning experience into
some docs.
You will have to find the time to review them though :)

>> 7. How do you guys use babushka with "sudo"? Run babushka itself with sudo or as root? No way in hell it make sense to type in the password for every "sudo" (why doesn't that cached after the first sudo?)
>
> Either will work fine, you can use whichever you like.
>
> The repetitive password typing isn't specific to babushka; it's a result of the way `sudo` is configured on newer versions of ubuntu and friends, and affects many other apps to. It's unfortunate.

Hm. But when I 'sudo' twice from the shell it only asks me for the
password once.


I am making progress but still stuck on the "source" problem. (see other mail)

cheers,
Torsten

[tcurdt]

Ben, any thoughts on this?

[Torsten Curdt]

actually ... is the source a parameter to a template?

[Lachlan Donald]

Source isn't a parameter in the base DepContext from what I can tell:

https://github.com/benhoskings/babushka/blob/master/lib/babushka/dep_context.rb

Are you perhaps thinking of one of the templates like .app or .installer?

https://github.com/benhoskings/babushka/blob/master/deps/templates/app.rb

For it to use a template, one must either specify a dep name with a .{template} at the end like this:

dep 'homedir.repo' do

   # dep uses the repo meta

end

Or like this:

dep 'homedir', template=>'repo'

  # etc etc

end

In your case, it looks like you are trying to checkout a git repo in your dep, I'd just use (assuming :repo is a directory name):

dep 'homedir repo', :username, :github_user, :repo do

   username.default!(shell('whoami'))

   github_user.default!(username)

   repo.default!('homedir')

   met? { repo.p.exists? }

   meet { git "git://github.com/#{username}/#{repo}.git", :to => repo }

end

If you were trying to create a .repo template, I'd look at all of the other template examples in the babushka codebase and also the GitRepo class for dealing with git sources:

https://github.com/benhoskings/babushka/blob/master/lib/babushka/git_repo.rb

Hope that helps.

Cheers,

Lachlan

On Friday, July 20, 2012 2:42:40 PM UTC-7, tcurdt wrote:

actually ... is the source a parameter to a template?

On Fri, Jul 20, 2012 at 10:50 PM, tcurdt <tcu...@vafer.org> wrote:
> Ben, any thoughts on this?
>
>
> On Thursday, July 19, 2012 1:29:36 AM UTC+2, tcurdt wrote:
>>
>> Hm. I have this dep
>>
>>     dep 'homedir repo', :username, :github_user, :repo do
>>       username.default!(shell('whoami'))
>>       github_user.default!(username)
>>       repo.default!('homedir')
>>
>>       source "git://github.com/#{username}/#{repo}.git"
>>
>>     end
>>
>> Why does this give a
>>
>>     homedir repo {
>>       undefined method `source' for #<Babushka::DepContext:0x92ed534>
>>
>> isn't "source" part of the core? ...and it's being used by so many other
>> deps.
>>
>> /me is confused
>
> --
> To post, email babush...@googlegroups.com

> To unsubscribe, email babushka_app+unsubscribe@googlegroups.com

[Ben Hoskings]

Sorry about the delay, I've been offline most of the weekend :)

Lachlan is right, 'source' isn't available on a base dep. For an acceptor like 'source' to be available, it has to be defined on the dep using `accepts_list_for'. You do that by defining a meta, including e.g. 'accepts_list_for :source', and then defining deps on top of that template.

-> Check the 'app', 'src', and 'installer' templates for examples of 'accepts_list_for :source'.

The same is true of all the base parts of the DSL, like 'requires': they're just defined on DepContext instead of a template. When you define a template, all that happens internally is that DepContext is subclassed.

-> Check lib/babushka/dep_context.rb for the equivalent 'accepts_list_for' definitions that base deps use.

There's definitely a disadvantage to wrapping that stuff up in the DSL: if you were to manually subclass DepContext yourself, then it would be more obvious to get started with because it's just pure ruby. I usually would prefer that to inventing DSL for it, but in this case I thought it was worth it for concision and namespacing. It's too hard to avoid naming clashes between dep sources if every source is free to define 'class GitDepContext < DepContext'.

- Ben

> --
> To post, email babush...@googlegroups.com

> To unsubscribe, email babushka_app...@googlegroups.com

[tcurdt]

Thanks folks. The template dir - that was the missing link :)

I am still struggling with a good usecase to use the meta deps though. Looking at the rbenv deps I don't see the value yet. Adds a lot of complexity. You could also just treat deps as a function. So right now I much prefer to just use

  require [

    'rbenv ruby'.with(:version => '1.9.3', :patchlevel => 'p194'),

    'rbenv ruby'.with(:version => '1.8.7', :patchlevel => 'p352'),

  ]

which seems to work fine.

I am still going back and forth whether it would be nice for babuska to report the parameters in the output - in general. But for now log_ok does the trick.

cheers,

Torsten

[Ben Hoskings]

You're absolutely right, a dep with parameters is usually a better choice.

There are two cases where a template is useful -- when you want to wrap up the arguments you're passing, and when you want per-dep custom blocks.

I'll fill in the missing piece of the docs. One sec :)

- Ben

[Ben Hoskings]

Also, you can use the --show-args commandline argument to show the arguments that each dep was called with.

- Ben



On 22/07/2012, at 7:50 PM, tcurdt wrote:

[Torsten Curdt]

> Also, you can use the --show-args commandline argument to show the arguments that each dep was called with.

uh! nice!

cheers,
Torsten

[Ben Hoskings]

I've started on this section of the docs.

http://babushka.me/writing-deps

Only the basics so far, but it's the foundation of the next bit which will be more relevant to this thread.

- Ben