Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump pact_broker version to 1.14.0 to resolve twisted dependencies. #84

Conversation

tancnle
Copy link
Contributor

@tancnle tancnle commented Mar 27, 2017

I have managed to reproduced this error as reported per #83

Bundler could not find compatible versions for gem "activesupport":
  In Gemfile:
    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      trailblazer (~> 0.1.0) was resolved to 0.1.0, which depends on
        actionpack (>= 3.0.0) was resolved to 3.0.0, which depends on
          activesupport (= 3.0.0)

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      trailblazer (~> 0.1.0) was resolved to 0.1.0, which depends on
        reform (= 1.2.0.beta1) was resolved to 1.2.0.beta1, which depends on
          activemodel was resolved to 5.0.2, which depends on
            activesupport (= 5.0.2)

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      padrino-core (~> 0.12.4) was resolved to 0.12.4, which depends on
        activesupport (>= 3.1)
Bundler could not find compatible versions for gem "rack":
  In Gemfile:
    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      trailblazer (~> 0.1.0) was resolved to 0.1.0, which depends on
        actionpack (>= 3.0.0) was resolved to 5.0.2, which depends on
          rack (~> 2.0)

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      padrino-core (~> 0.12.4) was resolved to 0.12.4, which depends on
        http_router (~> 0.11.0) was resolved to 0.11.2, which depends on
          rack (>= 1.0.0)

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      rack

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      rack

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      rack

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      trailblazer (~> 0.1.0) was resolved to 0.1.0, which depends on
        actionpack (>= 3.0.0) was resolved to 5.0.2, which depends on
          rack-test (~> 0.6.3) was resolved to 0.6.3, which depends on
            rack (>= 1.0)

    pact_broker (~> 1.9.3) was resolved to 1.9.3, which depends on
      padrino-core (~> 0.12.4) was resolved to 0.12.4, which depends on
        sinatra (~> 1.4.2) was resolved to 1.4.8, which depends on
          rack (~> 1.5)

    thin was resolved to 1.7.0, which depends on
      rack (< 3, >= 1)

Tested on:

  • MacOSX Darwin Kernel Version 16.4.0
  • Ruby 2.2.6 (2016-11-15 patchlevel 396) [x86_64-darwin16]
  • Bundler 1.14.6

This should solve #83

@bethesque bethesque merged commit 381b8e5 into pact-foundation:master Mar 28, 2017
@bethesque
Copy link
Member

Ah! Of course.

Can you think of any reason we can't actually just drop the version specification entirely @tancnle?

@tancnle tancnle deleted the kaizen/example-pact-broker-version-bump branch March 28, 2017 12:11
@tancnle
Copy link
Contributor Author

tancnle commented Mar 31, 2017

Dropping the version spec will ensure a fresh bundle install will pulling in the latest pact_broker version. This however does not guarantee it will pull in the latest if we already downloaded a local version and locked in Gemfile.lock

ie. if I have downloaded 1.14.0 and generated Gemfile.lock, subsequently running bundle install will not download 1.15.0 unless we update pact_broker version specification in Gemfile.

I think it is ok to make sure we update this version spec whenever a new version is pushed. Alternatively we can use relative local path, rather than pulling from gem.

@bethesque
Copy link
Member

Good points. I actually have a copy of the example directory where I use a relative path to start up the app. My original thought was that the directory would be able to be copied as a standalone thing without the rest of the project, hence the gem reference rather than the relative reference.

I think that the use case for that directory is that someone is new the the broker, and hence, is unlikely to have an old copy of the gem lying around, so I'm going to remove the version restriction.

bethesque referenced this pull request Apr 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants