Berkshelf: dependency resolution via Berksfile does not seem to work


#1

Hi all,

I have a question regarding the resolution of cookbook dependencies in
Berkshelf, using the “metadata” line in a Berksfile. Executive summary:
it does not work for me. Suggestion: I am misunderstanding something,
but I can’t see what it is.

At berkshelf.com I read the following: “[…] This allows you to resolve
a Cookbook’s dependencies that you are currently working on just like
you would resolve the dependencies of a Gem that you are currently
working on with Bundle”.

What I expected to work was therefore the following:

cd project/ cat Berksfile
cookbook “berkshelf-test-1”, git:
“git://github.com/froschi/berkshelf-test-1.git”

At said URL, there is a cookbook (created using ‘berks cookbook’, as it
happens, though that probably does not matter). It contains the
following line in metadata.rb:

depends “berkshelf-test-2”, “>= 0.0.1”

and in its Berksfile:

metadata
cookbook “berkshelf-test-2”, git:
“git://github.com/froschi/berkshelf-test-2.git”

In the project folder above, I expected to run:

$ berks install

and watch Berkshelf pull in the berkshelf-test-1 cookbook, resolve the
dependency, then pull in the berkshelf-test-2 cookbook automatically
from the source specified. However, what I get is:

Installing berkshelf-test-1 (0.0.1) from git:
‘git://github.com/froschi/berkshelf-test-1’ with branch:
'58f043037e76b04e1096eed7b2c14941505c13fd’
FATAL: Cookbook ‘berkshelf-test-2’ not found at site:
http://cookbooks.opscode.com/api/v1/cookbooks

So, it finds the dependency (if via metadata.rb or Berksfile, I do not
know), but it does not follow the specification in the Berksfile.

Is this a bug? Am I misunderstanding how it should work?

Cheers,

t


#2

Hey Thorsten,

The issue that you are running into is that a dependency’s Berksfile is not taken into consideration - only their metadata.rb. So the source location that you specified in “berkshelf-test-1” for the dependency “berkshelf-test-2” at the Git source location is not taken into account.

Only the source locations specified in the project’s Berksfile (the one in the directory you are running berks install or specified with --berksfile) are used to override the locations of dependencies.

To solve your problem you should specify that the dependency “berkshelf-test-2” can be found at git: “git://github.com/froschi/berkshelf-test-2.git (http://github.com/froschi/berkshelf-test-2.git)” in your main project’s Berksfile.

example:
cat project/Berksfile
cookbook “berkshelf-test-1”, git: "git://github.com/froschi/berkshelf-test-1.git (http://github.com/froschi/berkshelf-test-1.git)"
cookbook “berkshelf-test-2”, git: “git://github.com/froschi/berkshelf-test-2.git (http://github.com/froschi/berkshelf-test-2.git)”

While this is slightly confusing at first, this is working as intended.

I have an open branch that I have been working on that will ship with 0.4.0 that allows you to define “default source locations” in your project’s Berksfile. This will allow you to say, “check this list of chef servers or community servers before saying that you can’t find my cookbook or dependencies”.

Thanks for using Berkshelf!


Jamie Winsor
@resetexistence

On Thursday, August 23, 2012 at 6:24 AM, Thorsten Fischer wrote:

Hi all,

I have a question regarding the resolution of cookbook dependencies in
Berkshelf, using the “metadata” line in a Berksfile. Executive summary:
it does not work for me. Suggestion: I am misunderstanding something,
but I can’t see what it is.

At berkshelf.com (http://berkshelf.com) I read the following: “[…] This allows you to resolve
a Cookbook’s dependencies that you are currently working on just like
you would resolve the dependencies of a Gem that you are currently
working on with Bundle”.

What I expected to work was therefore the following:

cd project/ cat Berksfile
cookbook “berkshelf-test-1”, git:
“git://github.com/froschi/berkshelf-test-1.git (http://github.com/froschi/berkshelf-test-1.git)”

At said URL, there is a cookbook (created using ‘berks cookbook’, as it
happens, though that probably does not matter). It contains the
following line in metadata.rb:

depends “berkshelf-test-2”, “>= 0.0.1”

and in its Berksfile:

metadata
cookbook “berkshelf-test-2”, git:
“git://github.com/froschi/berkshelf-test-2.git (http://github.com/froschi/berkshelf-test-2.git)”

In the project folder above, I expected to run:

$ berks install

and watch Berkshelf pull in the berkshelf-test-1 cookbook, resolve the
dependency, then pull in the berkshelf-test-2 cookbook automatically
from the source specified. However, what I get is:

Installing berkshelf-test-1 (0.0.1) from git:
‘git://github.com/froschi/berkshelf-test-1’ (http://github.com/froschi/berkshelf-test-1’) with branch:
'58f043037e76b04e1096eed7b2c14941505c13fd’
FATAL: Cookbook ‘berkshelf-test-2’ not found at site:
http://cookbooks.opscode.com/api/v1/cookbooks

So, it finds the dependency (if via metadata.rb or Berksfile, I do not
know), but it does not follow the specification in the Berksfile.

Is this a bug? Am I misunderstanding how it should work?

Cheers,

t


#3

Hi Jamie,

To solve your problem you should specify that the dependency
"berkshelf-test-2" can be found at git:
[…]
example:
cat project/Berksfile
cookbook “berkshelf-test-1”, git:
"git://github.com/froschi/berkshelf-test-1.git
http://github.com/froschi/berkshelf-test-1.git"
cookbook “berkshelf-test-2”, git:
“git://github.com/froschi/berkshelf-test-2.git
http://github.com/froschi/berkshelf-test-2.git

Yes, this is indeed what I found, too. Unfortunately, this kind of
defeats the advantage that I hoped to get out of berkshelf; I have a
stack of cookbooks that have some rather convoluted, multi-level
dependency chains. Typing them all out into the project’s Berksfile
instead of storing them with the cookbooks and have their dependencies
followed recursively is a bit inconvenient.

While this is slightly confusing at first, this is working as intended.

Yep, it works :slight_smile:

I have an open branch that I have been working on that will ship with
0.4.0 that allows you to define “default source locations” in your
project’s Berksfile. This will allow you to say, “check this list of
chef servers or community servers before saying that you can’t find my
cookbook or dependencies”.

Sounds good! I would very much prefer storing 3-4 dependency locations
with the cookbooks themselves, rather than having to collect them into
on central location.

Thanks for your help,

t