| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Adds an extra artifice task to vendorize new `connection_pool`
dependency.
* Cherry-pick's needed Windows fix not yet merged into master branch of
`net-http-persistent`.
* Update bundler usages to be compatible with the new version, and fix
unit specs.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7251: Removed the environmental variables that are BUNDLE_USER_*. r=hsbt a=hsbt
### What was the end-user problem that led to this PR?
When the users uses `BUNDLE_USER_*` environmental variables like `BUNDLE_USER_CONFIG`, the rspec example of Bundler affected by them failed.
### What was your diagnosis of the problem?
The current spec_helper didn't clear and restore them.
### What is your fix for the problem, implemented in this PR?
I remove and restore them same as `Bundler::EnvironmentPreserver::BUNDLER_PREFIX`
### Why did you choose this fix out of the possible options?
This is the most simple solution with the current implementation.
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
| |/ / /
| | |
| | |
| | | |
It's affect with rspec examples and broke them.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7261: Enable `Style/UnneededInterpolation` cop r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that sometimes we have some unneeded string interpolations in our code base.
### What was your diagnosis of the problem?
My diagnosis was that we could remove them, because interpolating string variables seems weird and redundant.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the unnecessary interpolations, and enable the corresponding rubocop cop.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the current issues and it enforces the style rule from now on.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7226: Improve quality specs r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
I'm not really sure of the exact context when I made these changes, but I recall I was getting some invalid encoding errors somehow, and they turned out to be an estraneous `’` quote in one of the documentation files.
### What was your diagnosis of the problem?
My diagnosis was that we should not include this character anywhere, but instead use regular quotes.
### What is your fix for the problem, implemented in this PR?
My fix is to add a quality spec for this, and while I was at it, I added some improvements to quality specs in general.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
And use single quotes consistenly.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
It contains a typo, so it can't be needed.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Instead of setting the encoding globally, set it when reading the files.
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7260: Better info about spec exclusions r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that current tests are very cryptic about the tests that are being excluded:
```
$ bin/rspec
Run options: exclude {:non_windows=>false, :ruby_repo=>false, :bundler=>#<RequirementChecker:./spec/support/requirement_checker.rb:7>, :git=>#<RequirementChecker:./spec/support/requirement_checker.rb:7>, :rubygems=>#<RequirementChecker:./spec/support/requirement_checker.rb:7>, :ruby=>#<RequirementChecker:./spec/support/requirement_checker.rb:7>, :realworld=>true, :sudo=>true}
Randomized with seed 22209
...
```
### What was your diagnosis of the problem?
My diagnosis was that the `RequirementChecker` class needs a better text representation.
### What is your fix for the problem, implemented in this PR?
My fix is to add an `inspect` method that informs better about the exclusion. Now:
```
$ bin/rspec
Run options: exclude {:non_windows=>false, :ruby_repo=>false, :bundler=>"!= 2", :git=>"!= 2.22.0", :rubygems=>"!= 3.0.4", :ruby=>"!= 2.6.3", :realworld=>true, :sudo=>true}
Randomized with seed 36536
...
```
### Why did you choose this fix out of the possible options?
I chose this fix because it makes it easier to understand what's going on.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |/
| |/| |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7238: Point to CoC which contains the contributor covenant r=deivid-rodriguez a=ajwann
### What was the end-user problem that led to this PR?
The generated README contains two different links to contributor covenant. Since the generated Code of Conduct *contains* the text of the Contributor Covenant, we can just point the generated README to the generated CoC, and explicitly refer to it as the code of conduct.
### What is your fix for the problem, implemented in this PR?
The generated readme now points to the gems CoC (which contains the Contributor Covenant)
Closes #6905.
Co-authored-by: Adam Wanninger <ajwann@ajwann.com>
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7255: Improve environment backup and restore r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the specs were removing some environment variables for every tests, but not all of them, causing problems on some environments (see #7251).
### What was your diagnosis of the problem?
My diagnosis was that we don't really need to do this.
### What is your fix for the problem, implemented in this PR?
My fix is to stop doing it, and fix the very few specs that failed after the change. One of the failures actually led to a bug fix (I think), see 6c27ebb.
### Why did you choose this fix out of the possible options?
I chose this fix because I think it's cleaner than adding a public constant in `lib/` only to fix a problem with the specs, like it's done in #7251.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
It sounds like this was mistankenly added in
4337a499d0108fc3748084934aaed7591b355a26. Then the forgotten MANPATH key
was added in bf5bf106230772934602768bb31a68dc925691f0, but this one
should've been removed I think.
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7250: Fix ruby core dsl spec.rb failure, warning on build_metadata.rb r=deivid-rodriguez a=MSP-Greg
### What was the end-user problem that led to this PR?
Travis CI job on Ruby master was failing & had a nuisance warning.
### What is your fix for the problem, implemented in this PR?
1. dls_spec.rb - Minor change to the error msg regexp match string
2. build_metadata.rb - change `if @git_commit_sha` to `if instance_variable_defined? :@git_commit_sha`
Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>
|
| | | |
| | |
| | |
| | | |
initialized'
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7252: spec/bundler/shared_helpers_spec.rb - fixup after 7248 r=hsbt a=MSP-Greg
PR 7248 https://github.com/bundler/bundler/commit/3f57b102c76fea2f701152e087c88f53df17d3d0 incorrectly changed a path calculation. This reverts.
This only affects testing when `ruby_core?` is true.
After running Azure Pipelines CI in my ruby/ruby fork and checking the 'bundler' jobs, the error was apparent...
Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
PR 7248 incorrectly changed a path calculation. This reverts.
After running Azure Pipelines CI in my ruby/ruby fork and checking the 'bundler' jobs, the error was apparent...
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7249: Add `bundle package` functionality to `bundle cache` r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the previous plan provided no migration path from the current `bundle cache` to the future one (an alias to `bundle package`).
### What was your diagnosis of the problem?
My diagnosis was that we should probably tell users first that in bundler 3, `bundle cache` will have a different implementation. However, after playing around with it a bit, I noticed that the additions to `bundle cache` provided by `bundle package` are fully backwards compatible. Or maybe I'm missing something but at least all `bundle cache` tests still pass when changing the implementation under the hood to use `bundle package`. As far as I can see, the only backwards incompatible change (start caching `git` and `path` gems by default) is already covered by the exisiting `cache_all` flag), so we should be good.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the current implementation of `bundle cache`, and replace it with the current implementation of `bundle package`.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows us to remove code and it reduces confusion about `bundle cache` vs `bundle package` making them work exactly the same.
On a future PR, I plan to clean this up so that everything (docs, code, tests) use `bundle cache`, and `bundle package` is left only as an alias.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The additions of the `package` command are not actually backwards
incompatible, so we can do this transition without further care. All
existing specs of `bundle cache` pass when using the `bundle package`
implementation for it.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
So that we handle the removal of `bundle cache` just like we'll handle
the removal of `bundle show` and `bundle console`.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Just change the default. The reason to do this is that the deprecation
message talks about the default being changed, not the option being
removed.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This is inside a code branch where the condition is already met.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7248: Fix nested bundle exec's when bundler is a default gem r=deivid-rodriguez a=MSP-Greg
### What was the end-user problem that led to this PR?
The problem was that when bundler is a default gem, nested `bundle exec` commands generate a LoadError.
```
/home/travis/.rvm/rubies/ruby-head/bin/bundle:30:in `load': cannot load such file --
/home/travis/.rvm/rubies/ruby-head/lib/bin/bundle (LoadError)
```
### What was your diagnosis of the problem?
Not accounting for Bundler being installed as a default gem. When it's a default, the lib and exe folders do not share the same root folder.
This was the result of a change in https://github.com/bundler/bundler/commit/e742c3d5f458a4a59cf0eaab2567eca844f956d1 (#7100).
### Repo Example
Using Ruby master/trunk/ruby-head (as of https://github.com/ruby/ruby/commit/0c6c937904aafc1809386bd892a2d114d22d01fe), from a folder where `bundle exec` can be ran:
```
bundle exec "bundle exec 'ruby -v'"
```
### What is your fix for the problem, implemented in this PR?
Small adjustment to logic for finding the correct exe/bundle file.
### Why did you choose this fix out of the possible options?
I chose this fix because it's similar to previous code.
Fixes #7244.
Co-authored-by: MSP-Greg <msp-greg@users.noreply.github.com>
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7239: Fully remove compatibility guard r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that this code is untested and never run.
### What was your diagnosis of the problem?
My diagnosis was that we can remove it.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the code.
### Why did you choose this fix out of the possible options?
I actually intented to remove this in https://github.com/bundler/bundler/pull/6983, but after a discussing it with @simi I decided to keep it (see https://github.com/bundler/bundler/pull/6983#discussion_r259327593). After a second though I think this is safe to remove and that the potential use case (that the latest bundler is allowed to be installed by a really really old rubygems that didn't support ruby version constraints) is not a problem. The `required_ruby_version` constraint landed in [rubygems 0.6, 15 years ago](https://github.com/rubygems/rubygems/commit/240a9d3a3dc7211cad9680ce2579f502e215b519).
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7247: Drop rubygems 2.5.0 and 2.5.1 support r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we have some conditional code in bundler dependent on the rubygems version being used, that could be easily removed if we dropped support for rubygems 2.5.0 and 2.5.1.
### What was your diagnosis of the problem?
My diagnosis was that we could drop support for these versions now, to remove all of those conditionals and simplify the integration.
### What is your fix for the problem, implemented in this PR?
My fix is to drop support for rubygems 2.5.0 and 2.5.1.
### Why did you choose this fix out of the possible options?
I chose this fix because the oldest ruby we currently support, 2.3, ships with rubygems 2.5.2, so it's very unlikely that any user of the next bundler version will be using these old rubygems versions, because they would need to explicitly downgrade rubygems!
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | |
| | |
| | |
| | | |
It seems to pass under rubygems 2.5.2.
|
| | | |
| | |
| | |
| | | |
Since it covers the whole range we support.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7246: No need to make gem refresh a noop r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that rubygems/rubygems#2711 fails because the test in bundler that checks that `Gem.refresh` reveals no system gems fails.
### What was your diagnosis of the problem?
My diagnosis was that we don't really need to make `Gem.refresh` a noop at all, because we already setup a `post_reset` hook to automatically go back to the set of specs bundler knows about, everytime `Gem::Specification.reset` is called. See https://github.com/bundler/bundler/blob/847db56c6b5d2156d27990d73a9949507693985a/lib/bundler/rubygems_integration.rb#L551-L554.
And `Gem::Specification.reset` is what `Gem.refresh` does: https://github.com/rubygems/rubygems/blob/564bb0a5bb310ccceaf6cd6391b3e67e0712edd5/lib/rubygems.rb#L861-L867.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the redefinition of `Gem.refresh`. This makes sense to me not only because it's unnecessary, but because the monkeypatch could still be very easily workarounded by calling `Gem::Specification.reset` directly.
After undoing the `Gem.refresh` redefinition, I changed the test to still make sure that the (not overriden) `Gem.refresh` still does not change the set of specs bundler knows about.
This is a nice simplification, but doesn't really fix the spec for https://github.com/rubygems/rubygems/pull/2711, because after the first call to `Bundler.rubygems.find_name("rack")`, the `@stubs_by_name` array in rubygems gets populated and thus is no longer empty.
We can test the same thing without using `@stubs_by_name` under the hood, so I changed the test to do that, so that the rubygems PR is not affected.
### Why did you choose this fix out of the possible options?
I chose this fix because it simplifies the integration between bundler & rubygems, and it unblocks https://github.com/rubygems/rubygems/pull/2711.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We plan to incrementally populate this array in rubygems, so that will
break the test because the first time `find_by_name("rack")` is called
will make the `rack` gem available in the array.
We can test the same thing using some other way, which is more
appropriate anyways, because `Bundler.rubygems.find_name` is only used
inside `bundler` to look for the `bundler` gem itself whereas
`Bundler.rubygems.all_specs` is used in more places.
|
| |/ /
| |
| |
| |
| |
| | |
The rubygems integration sets up a `post_reset` hook that resets the
specs back to what bundler knows after `Gem::Specification.reset` is
called (which is what `Gem.refresh` calls under the hood).
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7215: Auto multiplatform r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that currently if the gemfile include gems for specific platforms, like the default `gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby] ` Rails uses, bundler will _always_ print a noisy warning, but I don't think users are doing anything wrong, just running `bundle install` on it.
Also, unless they run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`, and commit the resulting lockfile, they will continue to get the same warning over and over again.
### What was your diagnosis of the problem?
My diagnosis was that the right thing to do is that instead of warning users, bundler does the right thing by default. That is:
* Resolve the gemfile and lock it for all platforms present in the Gemfile.
* Install gems for the current platform if requested.
### What is your fix for the problem, implemented in this PR?
My fix is to do just that.
### Why did you choose this fix out of the possible options?
I chose this fix because I think it's better for our users. We currently have a specific setting to avoid this warning, which I guess we added given the complaints. We no longer need that setting, nor the warning, so I removed both.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
