Best way to split public/private deps

[lachlan...@gmail.com]

Spent some time over the past week migrating our Chef recipes to Babushka:

https://github.com/99designs/babushka-deps

I'm interested how other people tackle public vs private deps. The way we did it was to use a submodule to a private repo, which has our per-application deps and application configuration in it. The downside of this approach is that we can't just simply `babushka 99designs:"developer environment"`, instead we have to clone our deps repo, update submodules and run the recipe from current dir.

Any better suggestions?

- Lox

[Ben Hoskings]

Hi Lachlan, glad to hear you guys are making use of babushka.

I haven't had to deal with that issue because I don't have any private deps. For instance, at The Conversation all our deps are public, and just our API keys etc are kept private:

http://github.com/conversation/babushka-deps

If I was using a separate repo of private deps, I'd clone it as a separate source.

Firstly, babushka decides which deps to report statistics on based on the URL of the source as it sees it. If the top-level source is public, babushka will report on all the runs within that source, including a nested private repo.

(Reporting only involves the names of the deps and whether they succeeded or failed, not anything about their content. More info here: http://benhoskin.gs/2010/09/24/babushka-community-stats )

Secondly, submodules are a bit clunky. You're better off having a dep in your public source that installs the private source.

You don't have to do anything special to install a source: just make it available at ~/.babushka/sources/blah, and then run deps within it with 'blah:dep name'.

The github user naming convention only applies when ~/.babushka/sources/blah doesn't exist and babushka attempts to pull it from github automatically. If the directory is already present, babushka will use it; if it's a git repo, babushka will update from whatever its 'origin' source is set to.

- 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

[Lachlan Donald]

Thanks Ben, I'll try that approach.

- Lox

On Sunday, July 22, 2012 1:47:01 AM UTC-7, Ben Hoskings wrote:

Hi Lachlan, glad to hear you guys are making use of babushka.

I haven't had to deal with that issue because I don't have any private deps. For instance, at The Conversation all our deps are public, and just our API keys etc are kept private:

http://github.com/conversation/babushka-deps

If I was using a separate repo of private deps, I'd clone it as a separate source.

Firstly, babushka decides which deps to report statistics on based on the URL of the source as it sees it. If the top-level source is public, babushka will report on all the runs within that source, including a nested private repo.

(Reporting only involves the names of the deps and whether they succeeded or failed, not anything about their content. More info here: http://benhoskin .gs/2010/09/24/babushka-community-stats )

Secondly, submodules are a bit clunky. You're better off having a dep in your public source that installs the private source.

You don't have to do anything special to install a source: just make it available at ~/.babushka/sources/blah, and then run deps within it with 'blah:dep name'.

The github user naming convention only applies when ~/.babushka/sources/blah doesn't exist and babushka attempts to pull it from github automatically. If the directory is already present, babushka will use it; if it's a git repo, babushka will update from whatever its 'origin' source is set to.

- Ben



On 17/07/2012, at 6:16 AM, lachlan...@gmail.com wrote:

>
> Spent some time over the past week migrating our Chef recipes to Babushka:
>
> https://github.com/99designs/babushka-deps
>
> I'm interested how other people tackle public vs private deps. The way we did it was to use a submodule to a private repo, which has our per-application deps and application configuration in it. The downside of this approach is that we can't just simply `babushka 99designs:"developer environment"`, instead we have to clone our deps repo, update submodules and run the recipe from current dir.
>
> Any better suggestions?
>
> - Lox
>
> --
> To post, email babush...@googlegroups.com

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