-
Notifications
You must be signed in to change notification settings - Fork 240
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
Fix dependencies #236
Fix dependencies #236
Conversation
Problem ======= With the current rspec dependency definition in guard-rspec: s.add_dependency 'rspec', '>= 2.14', '~> 3.0.0.beta', '< 4.0' And a Gemfile in another project: gem 'rspec', '~> 2.14' gem 'guard-rspec', '~> 4.2.2' Then run Bundler: $ bundle update Fetching gem metadata from https://rubygems.org/......... Fetching additional metadata from https://rubygems.org/.. Resolving dependencies... Bundler could not find compatible versions for gem "rspec": In Gemfile: rspec (~> 2.14) ruby guard-rspec (~> 4.2.2) ruby depends on rspec (3.0.0.beta1) This means the '~> 3.0.0.beta' negates the '>= 2.14'. Solution ======== If guard-rspec defines: s.add_dependency 'rspec', '>= 2.14', '< 4.0' This works in another project: gem 'rspec', '~> 2.14' gem 'guard-rspec', '~> 4.2.2' And this also works: gem 'rspec', '~> 3.0.0.beta1' gem 'guard-rspec', '~> 4.2.2'
'~> 2.1' is equivalent of '>= 2.1', '< 3.0'.
Makes sense to me, but that was added because of #232 @jgorset @yujinakayama which version of ruby/rubygem/bundler are you using? |
$ ruby -v
ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-darwin13.0.0]
$ gem -v
2.0.14
$ bundle version
Bundler version 1.5.0 |
The version specifiers in the dependency specification must be all satisfied. So I think including def test_satisfaction(requirement, label)
puts label
[
'2.13.0',
'2.14.0',
'2.99.0.beta1',
'2.99.0',
'3.0.0.beta1',
'3.0.0',
'4.0.0'
].each do |version|
satisfy = requirement.satisfied_by?(Gem::Version.new(version))
puts " #{version.ljust(12)} #{satisfy}"
end
puts
end
requirement_with_beta = Gem::Requirement.new('>= 2.14', '~> 3.0.0.beta', '< 4.0')
requirement_without_beta = Gem::Requirement.new('>= 2.14', '< 4.0')
test_satisfaction(requirement_with_beta, "With '~> 3.0.0.beta'")
test_satisfaction(requirement_without_beta, "Without '~> 3.0.0.beta'") $ ruby test_requirement.rb
With '~> 3.0.0.beta'
2.13.0 false
2.14.0 false
2.99.0.beta1 false
2.99.0 false
3.0.0.beta1 true
3.0.0 true
4.0.0 false
Without '~> 3.0.0.beta'
2.13.0 false
2.14.0 true
2.99.0.beta1 true
2.99.0 true
3.0.0.beta1 true
3.0.0 true
4.0.0 false I think that “Prereleases need to be opt-in explicitly” is only for installation. It's not related to whether a prerelease version satisfies requirements when resolving dependencies. |
It seems I am using an older version of bundler and a newer version of rubygems, yet my result of |
Can you try running my proof of concept against your fork rather than mine and post your results, @yujinakayama? |
@jgorset I can but the situation is different from your trial because |
I think I've found the cause. Specifying With $ cat Gemfile
source 'https://rubygems.org'
gem 'rspec-rails', '~> 3.0.0.beta1'
gem 'guard-rspec', '4.2.0'
$ bundle install --path vendor/bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching additional metadata from https://rubygems.org/..
Resolving dependencies...
Bundler could not find compatible versions for gem "rspec-mocks":
In Gemfile:
guard-rspec (= 4.2.0) ruby depends on
rspec-mocks (~> 2.14.0) ruby
rspec-rails (~> 3.0.0.beta1) ruby depends on
rspec-mocks (3.0.0.beta1) With $ cat Gemfile
source 'https://rubygems.org'
gem 'rspec', '~> 3.0.0.beta1'
gem 'guard-rspec', '4.2.0'
$ bundle install --path vendor/bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching additional metadata from https://rubygems.org/..
Resolving dependencies...
Installing rb-fsevent (0.9.3)
Installing lumberjack (1.0.4)
Installing timers (1.1.0)
Installing diff-lcs (1.2.5)
Installing formatador (0.2.4)
Installing coderay (1.1.0)
Installing method_source (0.8.2)
Using bundler (1.5.0)
Installing slop (3.4.7)
Installing rspec-support (3.0.0.beta1)
Installing thor (0.18.1)
Installing celluloid (0.15.2)
Installing rspec-mocks (3.0.0.beta1)
Installing rspec-core (3.0.0.beta1)
Installing rspec-expectations (3.0.0.beta1)
Installing pry (0.9.12.4)
Installing rspec (3.0.0.beta1)
Installing ffi (1.9.3)
Installing rb-inotify (0.9.3)
Installing listen (2.4.0)
Installing guard (2.2.5)
Installing guard-rspec (4.2.0)
Your bundle is complete!
It was installed into ./vendor/bundle |
Anyway, I think @jgorset By the way, I found a workaround for your situation: $ cat Gemfile
source 'https://rubygems.org'
gem 'rspec', '~> 3.0.0.beta1' # Specify both `rspec` and `rspec-rails`
gem 'rspec-rails', '~> 3.0.0.beta1'
gem 'guard-rspec', '4.2.0'
$ bundle install --path vendor/bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching additional metadata from https://rubygems.org/..
Resolving dependencies...
Using minitest (4.7.5)
Installing multi_json (1.8.2)
Installing i18n (0.6.9)
Installing atomic (1.1.14)
... Could you try this? |
if @yujinakayama workaround works, I'm to set the preference on 2.14 too. |
@jgorset do you confirm that @yujinakayama workaround is working well? Thanks! |
Ok I confirm that adding |
4.2.3 released, happy new year! |
Thanks! |
Sorry for the late reply (and likewise the inconvenience in the first place), @thibaudgg and @yujinakayama! |
Problem
With the current
rspec
dependency definition inguard-rspec
:And a
Gemfile
in another project:Then run Bundler:
This means the
~> 3.0.0.beta
negates the>= 2.14
.Solution
If
guard-rspec
defines:Then this works in another project:
And this also works:
I've tested these behavior with my gem.
This fixes #235.