| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| | |
Version 1.15.0.pre.4
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[RubygemsIntegration] Stub out Gem.finish_resolve
Fixes https://github.com/rubygems/rubygems/issues/1911
Small novel:
In RubyGems 2.6.11, I changed `Gem.finish_resolve` to respect all of the currently resolved (i.e. `Gem.loaded_specs`) gems. This fixed some bugs that would lead `Gem.finish_resolve` to incorrectly raise gem incompatibility exceptions. That's great, except Bundler's resolver doesn't always resolve the same thing as RG's. In particular, `Source::Gemspec` gems that come from the `gemspec` DSL method are allowed to have conflicts. It appears projects, such as rails, were taking advantage of that fact. Since `stub_entrypoints` is called whenever `Bundler.setup` is run, this is essentially us 'activating' all of the gems in the bundle. Since everything is eagerly activated, it should be impossible for there to ever be any unresolved dependencies, and thus `Gem.finish_resolve` should always be a no-op anyways. We can save CPU cycles and keep our special resolution behavior for `Source::Gemspec` by just acknowledging that `Gem.finish_resolve` should always be a no-op once the bundle has been setup.
(cherry picked from commit a1925cb18c58232ba009df01478b65dfe43d51ba)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Return Bundler::StubSpec if stub is a Bundler::StubSpec
Supersedes https://github.com/bundler/bundler/pull/5593
Fixes https://github.com/bundler/bundler/issues/5592
Explanation
---
In some cases the `Gem::Specification.stubs` call in [this method](https://github.com/bundler/bundler/blob/master/lib/bundler/rubygems_integration.rb#L773-L778) in the rubygems integration returns a mixed bag of `Bundler::StubSpecification` and `Gem::StubSpecification` objects. We then instantiate `Bundler::StubSpecification` objects and set the `stub` to be both `Gem::StubSpecification` and `Bundler::StubSpecification` objects.
This happens after we tell rubygems to use our overrides [here](https://github.com/bundler/bundler/blob/master/lib/bundler/runtime.rb#L21-L24).
A `Bundler::StubSpecification` does not define `to_spec` where `Gem::StubSpecification` does. In `Bundler::StubSpecification` we assume the `stub` to be a `Gem::StubSpecification` rather than the `to_spec`-less `Bundler::StubSpecification`. This means that in `_remote_specification`, the call to `to_spec` [here](https://github.com/bundler/bundler/blob/master/lib/bundler/stub_specification.rb#L88) fails. This falls back to `method_missing` [here](https://github.com/bundler/bundler/blob/master/lib/bundler/remote_specification.rb#L96-L98) which, of course, calls `_remote_specification` (and thus an infinite failing loops occurs).
### Why did this happen in such a weird way?
We needed to use a combination of `foreman`, `unicorn`, and a call to `Gem::Specification.find_by_name(*args)` to replicate.
I suspect this was required because Bundler doesn't call these methods as much. The last call in a doubly nested `bundle exec` resulted in the issue being exasperated.
You can however replicate with this:
```ruby
gem_stub = Gem::Specification.stubs.first
bundler_stub = Bundler::StubSpecification.from_stub(gem_stub)
bundler_stub = Bundler::StubSpecification.from_stub(bundler_stub)
bundler_stub.to_spec
```
We basically got to a point where we tried calling a method that doesn't exist on a `Bundler::StubSpecification`, so `_remote_specification` was called, but that had a method which didn't exist since we had the weirdness going on described here.
It was just a very specific sequence of events that is hard to replicate.
Options
---
1. We implement `to_spec` on `Bundler::StubSpecification`, as is done in https://github.com/bundler/bundler/pull/5593
2. We assume that `stub` is a `Gem::Specification`. Therefore if we try to create a `Bundler::StubSpecification` with the stub being a `Bundler::StubSpecification`, we simply return that stub we already made instead.
Thoughts
---
1. This basically ends up making a linked list of `Bundler::StubSpecifications` where you can follow `stub` all the way up until it's no longer a `Bundler::StubSpecification`. This means that the implementation is an accidental fix as `to_spec` in #5593 actually just calls `stub.to_spec` - which, if the stub is a `Bundler:StubSpecification`, would call that `Bundler::StubSpecification`, following the list up until we find a `Gem::StubSpecification`.
2. This is the right solution IMO. This breaks the weird linked list we made by mistake and just returns the object as we'd expect. Then, when `stub.to_spec` is called in `_remote_specification`, we always know it is a `Gem::StubSpecification` which has it defined.
cc @segiddins
(cherry picked from commit 47e7dd0e93a11b40fa982aaef5eb7d35cb7c2717)
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[Mirror] Properly handle casing of file URIs
This came up when running the bundler specs in a path that had at least 1 upper case character
```
Run options:
include {:last_run_status=>"failed"}
exclude {:rubygems_master=>true, :git=>"=< 2.9.0", :rubygems=>"=< 2.6.12", :ruby=>"=< 2.3.1", :realworld=>true, :sudo=>true}
bundle install
with bundler dependencies
$ /Users/kenrettberg/.rbenv/versions/2.3.1/bin/ruby -rubygems -S gem --backtrace generate_index
Generating Marshal quick index gemspecs for 64 gems
................................................................
Complete
Generated Marshal quick index gemspecs: 0.036s
Generating specs index
Generated specs index: 0.000s
Generating latest specs index
Generated latest specs index: 0.000s
Generating prerelease specs index
Generated prerelease specs index: 0.000s
Compressing indices
Compressed indices: 0.001s
# $? => 0
$ /Users/kenrettberg/.rbenv/versions/2.3.1/bin/ruby -I/Users/kenrettberg/opensource/bundler/lib:/Users/kenrettberg/opensource/bundler/spec -r/Users/kenrettberg/opensource/bundler/spec/support/artifice/fail.rb -rsupport/hax /Users/kenrettberg/opensource/bundler/exe/bundle install --retry 0 --no-color
Fetching source index from file:/users/kenrettberg/opensource/bundler/tmp/gems/remote2/
Resolving dependencies...
Bundler could not find compatible versions for gem "bundler":
In Gemfile:
bundler (= 0.9.2)
Current Bundler version:
bundler (1.15.0.pre.3)
This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running `gem install bundler`?
Could not find gem 'bundler (= 0.9.2)' in any of the sources
# $? => 6
causes a conflict if explicitly requesting a different version (FAILED - 1)
Retried examples: 0
Failures:
1) bundle install with bundler dependencies causes a conflict if explicitly requesting a different version
Failure/Error: expect(out).to eq(nice_error)
expected: "Fetching source index from file:/Users/kenrettberg/opensource/bundler/tmp/gems/remote2/\nResolving d...r by running `gem install bundler`?\n\nCould not find gem 'bundler (= 0.9.2)' in any of the sources"
got: "Fetching source index from file:/users/kenrettberg/opensource/bundler/tmp/gems/remote2/\nResolving d...r by running `gem install bundler`?\n\nCould not find gem 'bundler (= 0.9.2)' in any of the sources"
(compared using ==)
Diff:
@@ -1,4 +1,4 @@
-Fetching source index from file:/Users/kenrettberg/opensource/bundler/tmp/gems/remote2/
+Fetching source index from file:/users/kenrettberg/opensource/bundler/tmp/gems/remote2/
Resolving dependencies...
Bundler could not find compatible versions for gem "bundler":
In Gemfile:
Commands:
$ /Users/kenrettberg/.rbenv/versions/2.3.1/bin/ruby -rubygems -S gem --backtrace generate_index
Generating Marshal quick index gemspecs for 64 gems
................................................................
Complete
Generated Marshal quick index gemspecs: 0.036s
Generating specs index
Generated specs index: 0.000s
Generating latest specs index
Generated latest specs index: 0.000s
Generating prerelease specs index
Generated prerelease specs index: 0.000s
Compressing indices
Compressed indices: 0.001s
# $? => 0
$ /Users/kenrettberg/.rbenv/versions/2.3.1/bin/ruby -I/Users/kenrettberg/opensource/bundler/lib:/Users/kenrettberg/opensource/bundler/spec -r/Users/kenrettberg/opensource/bundler/spec/support/artifice/fail.rb -rsupport/hax /Users/kenrettberg/opensource/bundler/exe/bundle install --retry 0 --no-color
Fetching source index from file:/users/kenrettberg/opensource/bundler/tmp/gems/remote2/
Resolving dependencies...
Bundler could not find compatible versions for gem "bundler":
In Gemfile:
bundler (= 0.9.2)
Current Bundler version:
bundler (1.15.0.pre.3)
This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running `gem install bundler`?
Could not find gem 'bundler (= 0.9.2)' in any of the sources
# $? => 6
# ./spec/install/bundler_spec.rb:54:in `block (3 levels) in <top (required)>'
Finished in 2.4 seconds (files took 1.66 seconds to load)
1 example, 1 failure
Failed examples:
rspec ./spec/install/bundler_spec.rb:33 # bundle install with bundler dependencies causes a conflict if explicitly requesting a different version
```
Notice the failure is just in the casing of the path... but that path is actually a file URI that is printed by a `Mirror` instance. Tracing back that initialization led me to undoing some down casing, so hopefully this is more correct without introducing any further regressions?
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Update comments in installer that was a bit out of date
This PR just updates some comments/documentation that was written ~6 years ago that is a fair bit out of date.
Let me know if any information is incorrect.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add specs for #find_by_name_and_platform and #merge in SpecSet
As the title says, this PR just adds a few specs that i noticed were missing in SpecSet.
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[RubygemsIntegration] Stub out Gem.finish_resolve
Fixes https://github.com/rubygems/rubygems/issues/1911
Small novel:
In RubyGems 2.6.11, I changed `Gem.finish_resolve` to respect all of the currently resolved (i.e. `Gem.loaded_specs`) gems. This fixed some bugs that would lead `Gem.finish_resolve` to incorrectly raise gem incompatibility exceptions. That's great, except Bundler's resolver doesn't always resolve the same thing as RG's. In particular, `Source::Gemspec` gems that come from the `gemspec` DSL method are allowed to have conflicts. It appears projects, such as rails, were taking advantage of that fact. Since `stub_entrypoints` is called whenever `Bundler.setup` is run, this is essentially us 'activating' all of the gems in the bundle. Since everything is eagerly activated, it should be impossible for there to ever be any unresolved dependencies, and thus `Gem.finish_resolve` should always be a no-op anyways. We can save CPU cycles and keep our special resolution behavior for `Source::Gemspec` by just acknowledging that `Gem.finish_resolve` should always be a no-op once the bundle has been setup.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Return Bundler::StubSpec if stub is a Bundler::StubSpec
Supersedes https://github.com/bundler/bundler/pull/5593
Fixes https://github.com/bundler/bundler/issues/5592
Explanation
---
In some cases the `Gem::Specification.stubs` call in [this method](https://github.com/bundler/bundler/blob/master/lib/bundler/rubygems_integration.rb#L773-L778) in the rubygems integration returns a mixed bag of `Bundler::StubSpecification` and `Gem::StubSpecification` objects. We then instantiate `Bundler::StubSpecification` objects and set the `stub` to be both `Gem::StubSpecification` and `Bundler::StubSpecification` objects.
This happens after we tell rubygems to use our overrides [here](https://github.com/bundler/bundler/blob/master/lib/bundler/runtime.rb#L21-L24).
A `Bundler::StubSpecification` does not define `to_spec` where `Gem::StubSpecification` does. In `Bundler::StubSpecification` we assume the `stub` to be a `Gem::StubSpecification` rather than the `to_spec`-less `Bundler::StubSpecification`. This means that in `_remote_specification`, the call to `to_spec` [here](https://github.com/bundler/bundler/blob/master/lib/bundler/stub_specification.rb#L88) fails. This falls back to `method_missing` [here](https://github.com/bundler/bundler/blob/master/lib/bundler/remote_specification.rb#L96-L98) which, of course, calls `_remote_specification` (and thus an infinite failing loops occurs).
### Why did this happen in such a weird way?
We needed to use a combination of `foreman`, `unicorn`, and a call to `Gem::Specification.find_by_name(*args)` to replicate.
I suspect this was required because Bundler doesn't call these methods as much. The last call in a doubly nested `bundle exec` resulted in the issue being exasperated.
You can however replicate with this:
```ruby
gem_stub = Gem::Specification.stubs.first
bundler_stub = Bundler::StubSpecification.from_stub(gem_stub)
bundler_stub = Bundler::StubSpecification.from_stub(bundler_stub)
bundler_stub.to_spec
```
We basically got to a point where we tried calling a method that doesn't exist on a `Bundler::StubSpecification`, so `_remote_specification` was called, but that had a method which didn't exist since we had the weirdness going on described here.
It was just a very specific sequence of events that is hard to replicate.
Options
---
1. We implement `to_spec` on `Bundler::StubSpecification`, as is done in https://github.com/bundler/bundler/pull/5593
2. We assume that `stub` is a `Gem::Specification`. Therefore if we try to create a `Bundler::StubSpecification` with the stub being a `Bundler::StubSpecification`, we simply return that stub we already made instead.
Thoughts
---
1. This basically ends up making a linked list of `Bundler::StubSpecifications` where you can follow `stub` all the way up until it's no longer a `Bundler::StubSpecification`. This means that the implementation is an accidental fix as `to_spec` in #5593 actually just calls `stub.to_spec` - which, if the stub is a `Bundler:StubSpecification`, would call that `Bundler::StubSpecification`, following the list up until we find a `Gem::StubSpecification`.
2. This is the right solution IMO. This breaks the weird linked list we made by mistake and just returns the object as we'd expect. Then, when `stub.to_spec` is called in `_remote_specification`, we always know it is a `Gem::StubSpecification` which has it defined.
cc @segiddins
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | |_|/ /
| |/| | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Unify the notation of RubyGems
This PR is mainly replacing Rubygems with RubyGems.
`Rubygems` is a Ruby module name (e.g. `Bundler::Source::Rubygems`) , whereas RubyGems is the proper notation as below.
https://github.com/rubygems/rubygems/blob/master/README.md
In this PR, it changed the notation mainly used in console output and documentation (and some source code comments) .
|
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | | |
Fix a typos
I picked up a typical typos using [misspell](https://github.com/client9/misspell) and applied it.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Permit absolute paths in cache_path setting
Removes check on leading `/` from `cache_path` and updates tests.
Fixes #5627
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | /
| | |/
| |/| |
Version 1.15.0.pre.3
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[Git] Only shorten refs if they are SHAs
Closes #5620
(cherry picked from commit fea23637886c1b1bde471c98344b8844f82e60ce)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
bundler:seg-test-default-gem-substitutes-are-activated, r=indirect
Test that default gem substitutes are properly activated
This is currently failing on ruby trunk
(cherry picked from commit ad5cd9ee66e45b6f243720107b751d2341b4261c)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
[Documentation] Pristine documentation
(cherry picked from commit 28e67dc7e4b9e3a6c67524597f7cd64e12ddbf6d)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
[CLI] Avoid loading Thor::Actions when it is not used
(cherry picked from commit 8552918f7faefc7f003d8a20979d5223bbd5b8ac)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
[Documentation] `bundle add` documentation
(cherry picked from commit a270b29445e31b6b0dff7201686950c28731a0ab)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Unify the names of GitHub and RuboCop
As far as I know, I think that "GitHub" and "RuboCop" become more precise names. This PR unifies the name in that way.
(cherry picked from commit f18c3727cad933a95714057b8c9ac475f29f8283)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
add metadata to gemspec
Including new changelog link!
(cherry picked from commit 2656fd7c54a81271f0ced674cf78905529728aa9)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Tweak a template of newgem
if value of `config[:coc]` is not `true` when executing `bundle gem <gemname>`, redundant blank lines are created in README.md.
This patch will not create these redundant blank lines.
```diff
## Contributing
Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/foo.
-
## License
The gem is available as open source under the terms of the [MIT License]
(http://opensource.org/licenses/MIT).
-
```
Related PR: #5523
(cherry picked from commit 29a0e80c9f9fa745c0adaf4de6366b4f582e8a51)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Fix exec_spec on ruby-head
(cherry picked from commit ec06cf0788bd1f82697a6e12748d997030bfe1ea)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[Git] Allow specifying non-branch symbolic refs
> The intention here is to allow installing a gem from git using a
> ref of the form "refs/zuul/" (which are used by the zuul
> continuous-integration system). There are likely other use cases for
> arbitrary refs.
Closes #4845
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[Git] Only shorten refs if they are SHAs
Closes #5620
|
| | | | | | |
|
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
bundler:seg-test-default-gem-substitutes-are-activated, r=indirect
Test that default gem substitutes are properly activated
This is currently failing on ruby trunk
|
| | | | |
| | | |
| | | |
| | | | |
default gem
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | | |
[Documentation] Pristine documentation
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[Settings] Allow configuring a mirror fallback timeout without a trailing slash
Closes #4830
|
| | | | | | |
|
