| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7580: Automultiplatform again r=indirect a=deivid-rodriguez
This PR is a reintroduction of #7215, now that I consider the multiplatform feature usable enough.
### 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 is that the fact that some gems will be unused under some platforms is inherent to the multiplatform feature itself, so we shouldn't warn about it because it's expected.
Take the following Gemfile for example (a simplification of the default Gemfile Rails generators create):
```ruby
source "https://rubygems.org"
gem "rails"
gem "tzinfo-data", platforms: "jruby"
```
If I type that Gemfile, it means that I'm explicitly opting into the multiplatform feature. So the behavior I would want as a user when I run `bundle install` on it is:
* Resolve and lock the Gemfile for all platforms (`jruby` and whatever platform I'm running).
* Install the resolution for the platform that I'm currently running.
That way, when the other developers of my team using `jruby` install the `Gemfile`, they install a predictable, deterministic resolution.
Currently, the only way to get that behavior is to run:
```
$ bundle install
$ bundle lock --add-platform java
```
But there's no way to do it without getting a warning on the first `bundle install`, which annoys people because it makes you think you're doing something wrong.
If you only plan to use MRI, you shouldn't specify any jruby-specific gems in your Gemfile and write instead:
```ruby
source "https://rubygems.org"
gem "rails"
```
If on the other hand you only plan to use jruby, then you should not specify any `platform` option at all and write
```ruby
source "https://rubygems.org"
gem "rails"
gem "tzinfo-data"
```
So, to sum up, I think the range of platforms users expect to support can be guessed implicit from the Gemfile and the running platform. So we should resolve by default for all those platforms and don't warn about behavior that's most likely expected.
### What is your fix for the problem, implemented in this PR?
My fix is to do the right thing by default, and not warn users at all. That is:
* Resolve the gemfile and lock it for all platforms present in the Gemfile.
* Install gems for the current platform if requested.
### 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>
|
| | |
| |
| |
| | |
This reverts commit e93bce3b206895a46b9fb5889c5f908fd29ad554.
|
| | |
| |
| |
| | |
This reverts commit b5766564fb6ad9c74c3b87ad6b2965f3b9095d08.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7590: Prepend debug label to resolver's debug message r=deivid-rodriguez a=kou
### What was the end-user problem that led to this PR?
The problem was not a end-user problem. This was a developer problem.
If we have many debug messages (for example, I added many `pp [...]` to debug #7522), it's difficult to find resolver's debug messages.
### What was your diagnosis of the problem?
My diagnosis was no common keywords in resolver's debug message is a problem. If we have a common keyword, we can find resolver's debug messages from many debug messages easily.
### What is your fix for the problem, implemented in this PR?
My fix prepends `BUNDLER: ` to all resolver's debug messages. If we have the same label in all resolver's debug messages, we can find resolver's debug message easily. For example, we can use "/BUNDLER:" in less.
### Why did you choose this fix out of the possible options?
I chose this fix because `BUNDLER: ` will not conflict. Other candidate is `DEBUG: ` but it may be used by other library. If the keyword conflicts, it's not easy to find resolver's debug messages. `Bundler::Resolver: ` will be more safer but it may be long.
Co-authored-by: Sutou Kouhei <kou@clear-code.com>
|
| | |
| |
| |
| |
| |
| | |
If we have the same label in all resolver's debug messages, we can find
resolver's debug message easily. For example, we can use "/BUNDLER:"
in less. It's useful when we have many debug messages.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
In some dev builds, `RUBY_PATCHLEVEL` is `-1`, so the spec crashes
because of an ill-formed requirement.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These hashes are actually modified. For example, to exclude some
dependencies under jruby.
So they should not be frozen.
Without this, running `bin/rake spec:deps` from jruby crashes with:
```
rake aborted!
FrozenError: can't modify frozen Hash
/path/to/bundler/spec/support/rubygems_ext.rb:36:in `dev_setup'
/path/to/bundler/Rakefile:29:in `block in <main>'
/path/to/bundler/Rakefile:14:in `block in invoke'
/path/to/bundler/Rakefile:13:in `invoke'
/path/to/bundler/spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
/path/to/bundler/spec/support/rubygems_ext.rb:45:in `gem_load'
Tasks: TOP => spec:deps
(See full trace by running task with --trace)
```
|
| | |
| |
| |
| | |
It no longer works with jruby-jars 9.2.10.0.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7622: Fix config location edge case r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
<!-- Write a clear and complete description of the problem -->
The problem was that if `BUNDLE_APP_CONFIG` is set to an absolute path, and there's no Gemfile up in the directory hierarchy, bundler would end up using the default config location instead of the customized one.
### What is your fix for the problem, implemented in this PR?
My fix is to completely avoid bundler's root resolution for resolving the config path in this case, since `BUNDLE_APP_CONFIG` includes all the information we need to know.
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Fixes #7610.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If `BUNDLE_APP_CONFIG` is set to an absolute path, and there's no
Gemfile up in the directory hierarchy, bundler would end up using the
default config location instead of the customized one.
This commit fixes that.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7614: Workaround jruby issue r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
The problem is that if a Gemfile contains `:path` gem with a relative path, the bundler environment no longer works when the app is packaged as a `jar` with [warbler](https://github.com/jruby/warbler).
### What is your fix for the problem, implemented in this PR?
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Issue was introduced https://github.com/rubygems/bundler/commit/c7532ced89bbc8ddc7296c56391c1c3cc981c54a, since when `jruby` deals with urls of the form "uri:classloader", it has a weird inconsistency where `Pathname#expand_path` with an argument always returns `uri:classloader://` (double slash) as the canonical version of the path, while `Pathname#expand_path` without an argument always returns `uri:classloader/` (single slash) as the canonical version of it.
```
Pathname.new("uri:classloader://foo/bar").expand_path
# => <Pathname:uri:classloader:/foo/bar>
Pathname.new("uri:classloader:/foo/bar").expand_path
# => <Pathname:uri:classloader:/foo/bar>
Pathname.new("foo/bar").expand_path("uri:classloader://")
# => <Pathname:uri:classloader://foo/bar>
Pathname.new("foo/bar").expand_path("uri:classloader:/")
# => <Pathname:uri:classloader://foo/bar>
```
That makes `Pathname#relative_path_from` (introduced with the offending commit) explode because we end up passing to different "uri:classloader" kind of paths to it.
I believe this should be fixed in `jruby` be doing either or both of the following things:
* Make `Pathname#expand_path` return consistent versions of "uri:classpath" paths.
* Make `Pathname#relative_path_from` support different versions of "uri:classpath" paths, since they are both absolute paths after all.
But I'm workarounding the issue in `bundler` by adding an extra `expand_path` call at an appropriate place to make sure that the URLs we pass to `Pathname#relative_path_from` have a consistent shape.
Fixes #7598.
NOTE: We currently don't have the ability to run a full test suite for every PR on jruby because it's too slow (#4796 attempted to improve that but it was never completed), and it doesn't even fully pass (#7603). As an alternative, I'm adding some realworld bare tests to be run under jruby, just to make sure common tasks like this one work.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| | |
Get rid of escaping and splitting shell code repeatedly.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7597: Don't call Warn on LoadError r=deivid-rodriguez a=egiurleo
Related to #7192 and #7527. When trying to run bundler without OpenSSL, the resulting warning recommends recompiling Ruby, changing the Gemfile sources to http, and then gives an RVM-specific link that won't be helpful for everyone.
I think the error message is now specific enough to stand on its own and help people debug, so we should remove the warning entirely. (Open to other opinions, though.)
Co-authored-by: Emily Giurleo <e.m.giurleo@gmail.com>
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7600: Improve cache specs r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
I noticed that when running specs on Windows, sometime I got a `_gem` leftover folder in the root of the repo.
### What is your fix for the problem, implemented in this PR?
My fix is to run the particular spec creating this test folder in `tmp`, just like the rest of the specs.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | | |
Everything in this tests happens inside `tmp/` and `tmp/` is cleaned up
after each spec.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
So it runs in the isolated tmp as expected. Also, as it is written, this
spec would leave a leftover `_gem` folder in the root of the repo in
case it fails, since the root of the repo is obviously not cleaned up
after each test.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7527: Report original exception when failing to load openssl r=deivid-rodriguez a=p-mongo
### What was the end-user problem that led to this PR?
See #7192.
### What was your diagnosis of the problem?
Bundler discards `LoadError` class and message when reporting it.
### What is your fix for the problem, implemented in this PR?
Report class and message of the original exception when reporting `LoadError`.
Fixes #7192
Co-authored-by: Oleg Pudeyev <oleg@bsdpower.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Co-authored-by: Emily Giurleo <e.m.giurleo@gmail.com>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If our test code happens to run `Gem.configuration` before `ENV["HOME"]`
is changed for our tests, this test starts failing because the test
first writes to the global `~/.gemrc` file (not in `tmp/`), because
`Gem.config_file` has that value memoized. Then, however, the `bundle
install` subprocess infers `Gem.config_file` from the modified
`ENV["HOME"]` and tries to read `tmp/home/.gemrc`. However, that file
doesn't exist, so rubygems configuration is ignored and doesn't print an
error like the test expects.
The error looks like this:
```
Failures:
1) Bundler friendly errors with invalid YAML in .gemrc reports a relevant friendly error message
Failure/Error: expect(err).to include("Failed to load #{home(".gemrc")}")
expected "" to include "Failed to load /home/travis/build/rubygems/bundler/tmp/1/home/.gemrc"
Commands:
$ /home/travis/.rvm/rubies/ruby-2.6.5/bin/ruby -I/home/travis/build/rubygems/bundler/lib:/home/travis/build/rubygems/bundler/spec -rsupport/hax -rsupport/artifice/fail /home/travis/build/rubygems/bundler/exe/bundle install
Running `bundle install` with bundler 3.0.0
Found changes from the lockfile, re-resolving dependencies because the list of sources changed, the dependencies in your gemfile changed, you added a new platform to your gemfile
Fetching source index from file:///home/travis/build/rubygems/bundler/tmp/1/gems/remote1/
Resolving dependencies...
Using bundler 3.0.0
0: bundler (3.0.0) from /home/travis/build/rubygems/bundler/lib/bundler/source
Fetching rack 1.0.0
Installing rack 1.0.0
Rack's post install message
0: rack (1.0.0) from /home/travis/build/rubygems/bundler/tmp/1/bundled_app/.bundle/ruby/2.6.0/specifications/rack-1.0.0.gemspec
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Bundled gems are installed into `./.bundle`
Post-install message from rack:
Rack's post install message
# $? => 0
# ./spec/bundler/friendly_errors_spec.rb:27:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:76:in `block (2 levels) in <top (required)>'
# ./spec/support/rubygems_ext.rb:98:in `load'
# ./spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
# ./spec/support/rubygems_ext.rb:45:in `gem_load'
```
My fix is to make this test independent from the specific rubygems
configuration in the main test process.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7592: Fix running compact client updater spec in isolation r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
The problem is the following error when running tests:
```
$ bin/rspec ./spec/bundler/compact_index_client/updater_spec.rb:47
Randomized with seed 40401
/home/deivid/.rbenv/versions/2.7.0/lib/ruby/2.7.0/tmpdir.rb:81: warning: method redefined; discarding old mktmpdir
/home/deivid/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/rspec-mocks-3.9.1/lib/rspec/mocks/method_double.rb:63: warning: previous definition of mktmpdir was here
F
Retried examples: 0
Failures:
1) Bundler::CompactIndexClient::Updater when bundler doesn't have permissions on Dir.tmpdir Errno::EACCES is raised
Failure/Error:
expect do
updater.update(local_path, remote_path)
end.to raise_error(Bundler::PermissionError)
expected Bundler::PermissionError, got #<RSpec::Mocks::MockExpectationError: #<Double :fetcher> received unexpected message :call with (#<Double :remote_path>, {"Accept-Encoding"=>"gzip"})> with backtrace:
# ./spec/bundler/compact_index_client/updater_spec.rb:51:in `block (4 levels) in <top (required)>'
# ./spec/bundler/compact_index_client/updater_spec.rb:50:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:76:in `block (2 levels) in <top (required)>'
# ./spec/support/rubygems_ext.rb:98:in `load'
# ./spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
# ./spec/support/rubygems_ext.rb:45:in `gem_load'
# ./spec/bundler/compact_index_client/updater_spec.rb:50:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:76:in `block (2 levels) in <top (required)>'
# ./spec/support/rubygems_ext.rb:98:in `load'
# ./spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
# ./spec/support/rubygems_ext.rb:45:in `gem_load'
Finished in 0.24158 seconds (files took 0.21522 seconds to load)
1 example, 1 failure
Failed examples:
rspec ./spec/bundler/compact_index_client/updater_spec.rb:47 # Bundler::CompactIndexClient::Updater when bundler doesn't have permissions on Dir.tmpdir Errno::EACCES is raised
Randomized with seed 40401
```
### What is your fix for the problem, implemented in this PR?
My diagnosis was that it's the `Updater#initialize` method that requires `tmpdir` making `Dir.mktmpdir` available. In the offending spec, first we stub `Dir.mktmpdir`, and then we initialize the updater, requiring `tmpdir`, and "undoing the stub". That means the test no longer does what it's supposed to.
So, my fix is to early instantiate the update, so that by the time we stub `Dir.mktmpdir`, `tmpdir` has already been required, so the stub is not reverted.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In particular,
```
$ bin/rspec ./spec/bundler/compact_index_client/updater_spec.rb:47
Randomized with seed 40401
/home/deivid/.rbenv/versions/2.7.0/lib/ruby/2.7.0/tmpdir.rb:81: warning: method redefined; discarding old mktmpdir
/home/deivid/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/rspec-mocks-3.9.1/lib/rspec/mocks/method_double.rb:63: warning: previous definition of mktmpdir was here
F
Retried examples: 0
Failures:
1) Bundler::CompactIndexClient::Updater when bundler doesn't have permissions on Dir.tmpdir Errno::EACCES is raised
Failure/Error:
expect do
updater.update(local_path, remote_path)
end.to raise_error(Bundler::PermissionError)
expected Bundler::PermissionError, got #<RSpec::Mocks::MockExpectationError: #<Double :fetcher> received unexpected message :call with (#<Double :remote_path>, {"Accept-Encoding"=>"gzip"})> with backtrace:
# ./spec/bundler/compact_index_client/updater_spec.rb:51:in `block (4 levels) in <top (required)>'
# ./spec/bundler/compact_index_client/updater_spec.rb:50:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:76:in `block (2 levels) in <top (required)>'
# ./spec/support/rubygems_ext.rb:98:in `load'
# ./spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
# ./spec/support/rubygems_ext.rb:45:in `gem_load'
# ./spec/bundler/compact_index_client/updater_spec.rb:50:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:109:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:76:in `block (2 levels) in <top (required)>'
# ./spec/support/rubygems_ext.rb:98:in `load'
# ./spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
# ./spec/support/rubygems_ext.rb:45:in `gem_load'
Finished in 0.24158 seconds (files took 0.21522 seconds to load)
1 example, 1 failure
Failed examples:
rspec ./spec/bundler/compact_index_client/updater_spec.rb:47 # Bundler::CompactIndexClient::Updater when bundler doesn't have permissions on Dir.tmpdir Errno::EACCES is raised
Randomized with seed 40401
```
It's the `Updater#initialize` method that requires `tmpdir` making
`Dir.mktmpdir` available. In the offending spec, first we stub
`Dir.mktmpdir`, and then we initialize the updater, requiring `tmpdir`,
and "undoing the stub". That means the test no longer does what it's
supposed to.
So, my fix is to early instantiate the update, so that by the time we
stub `Dir.mktmpdir`, `tmpdir` has already been required, so the stub is
not reverted.
|
| |/ /
| |
| |
| |
| | |
DEBUG_RESOLVER is used in RubyGems too. So we can't enable it only for
Bundler.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7577: Update references to old repo location r=deivid-rodriguez a=duckinator
Related: #7572.
### What was the end-user problem that led to this PR?
A lot of things use the outdated `https://github.com/bundler/bundler` URL (and similarly for e.g. `bundler/bundler-site`).
### What is your fix for the problem, implemented in this PR?
My fix was to update the outdated URLs. :slightly_smiling_face:
### TODO
- [x] `bundler.gemspec`
- [x] `CHANGELOG.md` (Moved to its own PR, #7582)
- [x] `CODE_OF_CONDUCT.md`
- [x] `doc/`, excluding reference to now-dead `pullreview.com`
- [x] `doc/contributing/HOW_YOU_CAN_HELP.md` reference to long-dead `pullreview.com`
- [x] `.github/config.yml`
- [x] `lib/` (comments)
- [ ] `lib/` (functional changes)
- [ ] `man/`
- [x] `README.md`
- [x] `spec/` (comments, `skip` messages)
- [ ] `spec/` (functional changes)
- [ ] `task/release.rake`
Co-authored-by: Ellen Marie Dash <me@duckie.co>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
I'm not really sure why, but the rename syscall sometimes is raising
Errno::EXDEV under Windows. I figure using a copy will fix the issue,
and it stills reproduces the regression the test is meant to check for.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7559: Reactivate usused code for ruby version resolution r=deivid-rodriguez a=larskanis
The code was changed in commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 so that RubyVersion.system was no longer respected. This is reactivated now and specs are adjusted accordingly.
### What was the end-user problem that led to this PR?
Not known.
### What was your diagnosis of the problem?
I read the bundler source code and noticed this.
### What is your fix for the problem, implemented in this PR?
My fix re-adds the ruby version as it was before commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 , since it seems to be a mistake.
### Why did you choose this fix out of the possible options?
As a alternative I added #7558 that removes the code in question.
Co-authored-by: Lars Kanis <kanis@comcard.de>
|
| | |/ /
| | |
| | |
| | |
| | | |
The code was changed in commit 38b0e7ed64c3ca1c40f43c5aa9a1ead2f6cd7049 so that RubyVersion.system was no longer respected.
This is reactivated now and specs are adjusted accordingly.
|
| | | |
| | |
| | | |
Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Because some examples are failed:
rspec ./spec/cache/gems_spec.rb:236 # bundle cache when previously cached doesn't remove gems that are for another platform
rspec ./spec/commands/install_spec.rb:220 # bundle install with gem sources the simple case with a gem that installs multiple platforms installs gems for the local platform as first choice
rspec ./spec/commands/update_spec.rb:39 # bundle update with --all updates the entire bundle
rspec ./spec/commands/update_spec.rb:49 # bundle update with --all doesn't delete the Gemfile.lock file if something goes wrong
rspec ./spec/commands/update_spec.rb:104 # bundle update with a top level dependency unlocks all child dependencies that are unrelated to other locked dependencies
rspec ./spec/commands/update_spec.rb:115 # bundle update with an unknown dependency should inform the user
rspec ./spec/commands/update_spec.rb:119 # bundle update with an unknown dependency should suggest alternatives
rspec ./spec/commands/update_spec.rb:126 # bundle update with a child dependency should update the child dependency
rspec ./spec/commands/update_spec.rb:299 # bundle update in a frozen bundle should suggest different command when frozen is set globally
rspec ./spec/runtime/platform_spec.rb:60 # Bundler.setup with multi platform stuff will add the resolve for the current platform
|
| |/ /
| |
| |
| | |
This is a follow-up change of #7522.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We should use "Ruby\0" instead of "ruby\0".
|
| | | |
|
