Berkshelf ignores version constraints in metadata when there is already a version of the cookbook installed. about berkshelf HOT 9 CLOSED

So... this also happens with Bundler ironically. I haven't looked, but are they using the same Version library? It might be a bug further down the stack.

from berkshelf.

@sethvargo no it is a problem with how we are building the graph. Right now we always favor what we "know" about before we go discover more. Since we always "know" about what we already have on our computer, we use that to resolve our dependencies.

You are right that this behavior is also present in Bundler. You run the update command in Bundler to update a Gem.

The problem I see here is that somehow 0.9.3 is considered acceptable when ~> 0.9.4 was the constraint.

from berkshelf.

I believe I am also seeing this issue now. With a metadata.rb of:

depends "java", "~> 1.5.2"
depends "nginx", "~> 1.0.0"
depends "artifact", "~> 0.11.0"
depends "build-essential", "~> 1.3.2"
depends "yum", "2.0.6"

I get the wrong Yum cookbook

kallan-2:nexus kallan$ be berks install
Using nexus (0.17.0) at path: '/Users/kallan/src/nexus'
Using java (1.5.2)
Using nginx (1.0.0)
Using build-essential (1.3.2)
Using runit (0.15.0)
Using bluepill (1.0.6)
Using yum (0.6.2)
Using ohai (1.0.2)
Using artifact (0.11.5)

👍 for this issue.

from berkshelf.

I think this is related to the issues with the lockfile expressed in other issues

from berkshelf.

Is this still an issue?

from berkshelf.

@sethvargo this is still an issue but should be 100% resolved by #397

from berkshelf.

@KAllan357 think you could wrap this up into a test case? I know I've experienced this before, but it might be fresher in your mind than mine.

from berkshelf.

@josephholsten here's a full cucumber test case:

Scenario: Doing something
  Given a cookbook named "fake"
  And I write to "Berksfile" with:
    """
    site :opscode
    cookbook 'fake', path: './fake'
    """
  And the cookbook "fake" has the file "metadata.rb" with:
    """
    name 'fake'
    version '1.0.0'

    depends 'berkshelf-cookbook-fixture', '~> 0.2.0'
    """
  And I successfully run `berks install`
  Then the cookbook store should have the cookbooks:
    | berkshelf-cookbook-fixture | 0.2.0 |
  When the cookbook "fake" has the file "metadata.rb" with:
    """
    name 'fake'
    version '1.0.0'

    depends 'berkshelf-cookbook-fixture', '~> 1.0.0'
    """
  When I successfully run `berks install`
  Then the cookbook store should have the cookbooks:
    | berkshelf-cookbook-fixture | 1.0.0 |
  And the output should contain:
    """
    Installing berkshelf-cookbook-fixture (1.0.0)
    """
  And the exit status should be 0

from berkshelf.

What's interesting - changing the second install to update will make the spec pass

from berkshelf.