`berks vendor` "cannot be trusted!" error #1124

reset · 2014-04-11T20:25:42Z

Since upgrading from beta6 to rc1 I'm getting the following error:

$ be berks vendor /Users/Jean/code/kabisa/internal/server-provisioning/tmp/tests \
    --berksfile /Users/Jean/code/kabisa/internal/server-provisioning/cookbooks/wrappers/base/Berksfile \
    -d

# ...

I, [2014-04-11T14:02:03.404224 #91543]  INFO -- : Checking if lockfile is trusted
D, [2014-04-11T14:02:03.404256 #91543] DEBUG -- : Checking base (1.5.2)
D, [2014-04-11T14:02:03.404276 #91543] DEBUG -- :   Detected there is a cached cookbook
D, [2014-04-11T14:02:03.404337 #91543] DEBUG -- :   Different location - cannot be trusted!
D, [2014-04-11T14:02:03.404511 #91543] DEBUG -- :     Dependency location: #<Berkshelf::PathLocation metadata: true, path: .>
D, [2014-04-11T14:02:03.404718 #91543] DEBUG -- :     Locked location:     #<Berkshelf::PathLocation metadata: false, path: ../../..>
I, [2014-04-11T14:02:03.404745 #91543]  INFO -- : Installing from universe
Fetching 'base' from source at ../../..
The resource at '/Users/Jean/code/kabisa/internal/server-provisioning' does not appear to be a valid cookbook. Does it have a metadata.rb?
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/locations/base.rb:59:in `validate_cached!'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/locations/path.rb:16:in `install'

Not sure how, but the path in the Locked location seems to be the issue.

sethvargo · 2014-04-11T14:45:27Z

@JeanMertz paths are expanded relative to the Berksfile. It seems there is some path wonkiness going on. Can you show us:

Your Berksfile
Your Berksfile.lock
Your directory structure (tree would be nice)
The metadata for any cookbook as appropiate

JeanMertz · 2014-04-11T17:56:23Z

@sethvargo so our directory structure is unlike a regular Chef project directory or a Cookbook directory. It's just the way we can manage our cookbooks best, and it's something we've settled on about a year ago.

Having said that, Berkshelf has never given us any issues with this structure. But maybe you decide not to support this way of working, so it might not really be a bug per-se.

After investigating, it seems that the vendor command can only be run from inside the cookbook itself. In the below directory structure, I'm at ./ and the cookbook is at ./cookbooks/helpers/attribute-helpers.

When using this position to fire the following command:

berks vendor /Users/Jean/code/kabisa/internal/server-provisioning/tmp/tests \
    --berksfile /Users/Jean/code/kabisa/internal/server-provisioning/cookbooks/helpers/attribute-helpers/Berksfile -d

the following error is returned:

I, [2014-04-11T19:45:38.668015 #489]  INFO -- : Reducing lockfile
D, [2014-04-11T19:45:38.668078 #489] DEBUG -- : Current lockfile:
D, [2014-04-11T19:45:38.668096 #489] DEBUG -- : 
D, [2014-04-11T19:45:38.668375 #489] DEBUG -- :   DEPENDENCIES
D, [2014-04-11T19:45:38.668419 #489] DEBUG -- :     attribute-helpers
D, [2014-04-11T19:45:38.668434 #489] DEBUG -- :       path: ../../..
D, [2014-04-11T19:45:38.668446 #489] DEBUG -- :   
D, [2014-04-11T19:45:38.668469 #489] DEBUG -- :   GRAPH
D, [2014-04-11T19:45:38.668482 #489] DEBUG -- :     attribute-helpers (1.0.0)
D, [2014-04-11T19:45:38.668494 #489] DEBUG -- : 
D, [2014-04-11T19:45:38.668506 #489] DEBUG -- : Unlocking dependencies no longer in the Berksfile
D, [2014-04-11T19:45:38.668535 #489] DEBUG -- :   Checking attribute-helpers (>= 0.0.0)
D, [2014-04-11T19:45:38.668566 #489] DEBUG -- :     Skipping unlock for attribute-helpers (exists in the Berksfile)
D, [2014-04-11T19:45:38.668602 #489] DEBUG -- : Removing transitive dependencies
D, [2014-04-11T19:45:38.668629 #489] DEBUG -- :   Checking attribute-helpers (>= 0.0.0)
D, [2014-04-11T19:45:38.672838 #489] DEBUG -- :     Cached cookbook exists
D, [2014-04-11T19:45:38.672884 #489] DEBUG -- :     Checking dependencies on the cached cookbook
D, [2014-04-11T19:45:38.672902 #489] DEBUG -- : New lockfile:
D, [2014-04-11T19:45:38.672916 #489] DEBUG -- : 
D, [2014-04-11T19:45:38.673148 #489] DEBUG -- :   DEPENDENCIES
D, [2014-04-11T19:45:38.673180 #489] DEBUG -- :     attribute-helpers
D, [2014-04-11T19:45:38.673194 #489] DEBUG -- :       path: ../../..
D, [2014-04-11T19:45:38.673209 #489] DEBUG -- :   
D, [2014-04-11T19:45:38.673233 #489] DEBUG -- :   GRAPH
D, [2014-04-11T19:45:38.673246 #489] DEBUG -- :     attribute-helpers (1.0.0)
D, [2014-04-11T19:45:38.673258 #489] DEBUG -- : 
Resolving cookbook dependencies...
I, [2014-04-11T19:45:38.673330 #489]  INFO -- : Checking if lockfile is trusted
D, [2014-04-11T19:45:38.673360 #489] DEBUG -- : Checking attribute-helpers (1.0.0)
D, [2014-04-11T19:45:38.673388 #489] DEBUG -- :   Detected there is a cached cookbook
D, [2014-04-11T19:45:38.673412 #489] DEBUG -- :   Different location - cannot be trusted!
D, [2014-04-11T19:45:38.673585 #489] DEBUG -- :     Dependency location: #<Berkshelf::PathLocation metadata: true, path: .>
D, [2014-04-11T19:45:38.673789 #489] DEBUG -- :     Locked location:     #<Berkshelf::PathLocation metadata: false, path: ../../..>
I, [2014-04-11T19:45:38.673821 #489]  INFO -- : Installing from universe
Fetching 'attribute-helpers' from source at ../../..
The resource at '/Users/Jean/code/kabisa/internal/server-provisioning' does not appear to be a valid cookbook. Does it have a metadata.rb?
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/locations/base.rb:59:in `validate_cached!'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/locations/path.rb:16:in `install'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/installer.rb:169:in `block in download_locations'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/installer.rb:166:in `each'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/installer.rb:166:in `download_locations'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/installer.rb:137:in `install_from_universe'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/installer.rb:39:in `run'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/berksfile.rb:373:in `install'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/berksfile.rb:588:in `vendor'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/cli.rb:381:in `vendor'
    /Users/Jean/.gem/ruby/2.1.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    /Users/Jean/.gem/ruby/2.1.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    /Users/Jean/.gem/ruby/2.1.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/cli.rb:52:in `dispatch'
    /Users/Jean/.gem/ruby/2.1.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/lib/berkshelf/cli.rb:27:in `execute!'
    /Users/Jean/.gem/ruby/2.1.0/gems/berkshelf-3.0.0.rc1/bin/berks:5:in `<top (required)>'
    /Users/Jean/.gem/ruby/2.1.0/bin/berks:23:in `load'
    /Users/Jean/.gem/ruby/2.1.0/bin/berks:23:in `<main>'

as you can see, Berkshelf interpreted the . path in the Berksfile.lock as ../../... For each path that I go up, the calculated relative path in Berksfile.lock changes as well:

./ vs ./helpers/attribute-helpers (so I went up into the ./cookbooks path):

I, [2014-04-11T19:47:25.770130 #667]  INFO -- : Reducing lockfile
D, [2014-04-11T19:47:25.770183 #667] DEBUG -- : Current lockfile:
D, [2014-04-11T19:47:25.770225 #667] DEBUG -- : 
D, [2014-04-11T19:47:25.770486 #667] DEBUG -- :   DEPENDENCIES
D, [2014-04-11T19:47:25.770531 #667] DEBUG -- :     attribute-helpers
D, [2014-04-11T19:47:25.770545 #667] DEBUG -- :       path: ../..

./ vs ./attribute-helpers (so I went up into the ./cookbooks/helpers path):

I, [2014-04-11T19:47:31.879391 #706]  INFO -- : Reducing lockfile
D, [2014-04-11T19:47:31.879451 #706] DEBUG -- : Current lockfile:
D, [2014-04-11T19:47:31.879469 #706] DEBUG -- : 
D, [2014-04-11T19:47:31.879740 #706] DEBUG -- :   DEPENDENCIES
D, [2014-04-11T19:47:31.879774 #706] DEBUG -- :     attribute-helpers
D, [2014-04-11T19:47:31.879789 #706] DEBUG -- :       path: ..

and only after I enter the cookbook path itself, does the vendor command actually work.

Maybe this is intended behaviour since rc1 (or somewhere since beta7), and we already worked around it in our provisioning scripts to cd into the cookbook path, instead of using absolute paths as shown in the above command, but still, if it's a bug, it'd be nice if this was fixed 👍.

DIRECTORY STRUCTURE

note, I removed a few subdirectories with some sensitive and/or irrelevant data

.
├── bin
├── config
│   ├── data_bags
│   │   └── *
│   └── environments
├── cookbooks
│   ├── helpers
│   │   ├── attribute-helpers
│   │   │   ├── libraries
│   │   │   ├── recipes
│   │   │   └── spec
│   │   ├── encryption-helpers
│   │   │   ├── libraries
│   │   │   ├── recipes
│   │   │   └── spec
│   │   ├── environment-helpers
│   │   │   ├── libraries
│   │   │   ├── recipes
│   │   │   └── spec
│   │   ├── kabisa-helpers
│   │   │   ├── libraries
│   │   │   ├── recipes
│   │   │   └── spec
│   │   └── service-helpers
│   │       ├── libraries
│   │       ├── providers
│   │       ├── recipes
│   │       ├── resources
│   │       └── spec
│   │           └── support
│   ├── public
│   │   ├── backuppc-client
│   │   │   ├── attributes
│   │   │   ├── libraries
│   │   │   ├── recipes
│   │   │   └── templates
│   │   │       └── default
│   │   └── backuppc-server
│   │       ├── attributes
│   │       ├── libraries
│   │       ├── recipes
│   │       └── templates
│   │           └── default
│   ├── services
│   │   └── *
│   └── wrappers
│       ├── backupable
│       │   ├── libraries
│       │   ├── recipes
│       │   └── spec
│       ├── base
│       │   ├── attributes
│       │   ├── files
│       │   │   └── default
│       │   │       └── test
│       │   ├── recipes
│       │   └── spec
│       ├── handlers
│       │   ├── files
│       │   │   └── default
│       │   │       └── handlers
│       │   ├── recipes
│       │   └── spec
│       ├── kabisa-application
│       │   ├── recipes
│       │   └── templates
│       │       └── default
│       └── testable
│           ├── attributes
│           ├── recipes
│           └── spec
├── doc
│   └── *
├── lib
│   ├── foodcritic
│   ├── hooks
│   ├── provision
│   │   └── test
│   │       └── test_case
│   ├── rspec
│   └── vagrant
│       └── provider
└── tmp
    └── packer

Berksfile (cookbooks/helpers/attribute-helpers)

source 'http://api.berkshelf.com'
metadata

Berksfile.lock

DEPENDENCIES
  attribute-helpers
    path: .

GRAPH
  attribute-helpers (1.0.0)

metadata.rb

def read(file, default = '')
  IO.read(File.join(File.dirname(__FILE__), file))
rescue Errno::ENOENT
  default
end

name             'attribute-helpers'
maintainer       'Jean Mertz'
maintainer_email 'jean@kabisa.nl'
license          'All rights reserved'
description      'Installs/Configures attribute-helpers'
long_description read('README.md')
version          read('VERSION', '0.1.0')

reset · 2014-04-11T18:12:26Z

@JeanMertz didn't intend to only be able to run vendor from within the cookbook. It should run relative to the path of the Berksfile. This will be fixed before 3.0.

sethvargo · 2014-04-11T20:09:36Z

I've labeled this as a bug and assigned to me

reset · 2014-04-11T20:26:29Z

@sethvargo need to fix the cucumber features but this should take care of the grossness

reset · 2014-04-11T20:27:09Z

lib/berkshelf/berksfile.rb


-      add_dependency(name, nil, path: path, metadata: true)
+      add_dependency(metadata.name, nil, path: path, metadata: true)


accidentally snuck this in to the PR. We don't need to do this song and dance of figuring out the name of the cookbook anymore.

sethvargo · 2014-04-11T20:29:30Z

lib/berkshelf/locations/path.rb

    def expanded_path
-      parent = File.expand_path(File.dirname(dependency.berksfile.filepath))
-      File.expand_path(relative_path, parent)
+      @expanded_path ||= Pathname.new File.expand_path(options[:path], File.dirname(dependency.berksfile.filepath))


This is really difficult to follow. Can we make a helper or something? There's a ton of expanding and contracting.

I see File.dirname(dependency.berksfile.filepath) twice - maybe that could become a more semantic name, like "berksfile_directory"?

`berks vendor` "cannot be trusted!" error

sethvargo added the Bug label Apr 11, 2014

expand default berksfile path

fb1ef51

sethvargo self-assigned this Apr 11, 2014

fix relative/absolute path functions for path locations

6f8a010

reset assigned reset and unassigned sethvargo Apr 11, 2014

reset reviewed Apr 11, 2014
View reviewed changes

reset added this to the 3.0.0 milestone Apr 11, 2014

sethvargo reviewed Apr 11, 2014
View reviewed changes

reset added 2 commits April 11, 2014 13:31

show relative instead of expanded path in path location#to_s

06ddbcb

fix cucumber features

7df7fcd

reset added a commit that referenced this pull request Apr 11, 2014

Merge pull request #1124 from berkshelf/fix-vendor-relative

eabb03a

`berks vendor` "cannot be trusted!" error

reset merged commit eabb03a into master Apr 11, 2014

reset deleted the fix-vendor-relative branch April 11, 2014 22:11

berkshelf locked and limited conversation to collaborators Jun 16, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`berks vendor` "cannot be trusted!" error #1124

`berks vendor` "cannot be trusted!" error #1124

reset commented Apr 11, 2014

sethvargo commented Apr 11, 2014

JeanMertz commented Apr 11, 2014

reset commented Apr 11, 2014

sethvargo commented Apr 11, 2014

reset commented Apr 11, 2014

reset Apr 11, 2014

sethvargo Apr 11, 2014

sethvargo Apr 11, 2014


		add_dependency(name, nil, path: path, metadata: true)
		add_dependency(metadata.name, nil, path: path, metadata: true)

berks vendor "cannot be trusted!" error #1124

berks vendor "cannot be trusted!" error #1124

Conversation

reset commented Apr 11, 2014

sethvargo commented Apr 11, 2014

JeanMertz commented Apr 11, 2014

DIRECTORY STRUCTURE

Berksfile (cookbooks/helpers/attribute-helpers)

Berksfile.lock

metadata.rb

reset commented Apr 11, 2014

sethvargo commented Apr 11, 2014

reset commented Apr 11, 2014

reset Apr 11, 2014

Choose a reason for hiding this comment

sethvargo Apr 11, 2014

Choose a reason for hiding this comment

sethvargo Apr 11, 2014

Choose a reason for hiding this comment

`berks vendor` "cannot be trusted!" error #1124

`berks vendor` "cannot be trusted!" error #1124