| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
The first prerelease of a bundler minor series is usually `.pre.1`, not
`.pre.0`.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7295: Changelog for first 2.1.0 pre-release r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I want to release a first pre-release of bundler 2.1.0, but I don't have a changelog for it.
### What was your diagnosis of the problem?
My diagnosis was that I needed to compile a changelog.
### What is your fix for the problem, implemented in this PR?
My fix is write the changelog.
### Why did you choose this fix out of the possible options?
I chose this fix because we used to have some automated change log handling, but I'm not sure how it work, so I instead just through each PR including user facing changes manually, with the aid of some helper tasks we have in our Rakefile.
This is still a WIP, because I might include some more PRs, and I also want to elaborate a bit on the deprecations that will get enabled, but it should be ready for an initial review.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| | |
This should be ready now.
|
|/
|
|
|
| |
It also includes an upgrading document with some explanations about the
new deprecations and how they map to breaking changes in bundler 3.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7307: Deprecate `--path` flag to `bundle check` (and related fixes) r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that this flag should also be deprecated for these commands in preparation for bundler no longer remembering CLI flags.
### What was your diagnosis of the problem?
My diagnosis was that, on bundler 3, the standard use case for `bundle check --path` will no longer work, namely:
```
$ bundle check --path .bundle
The following gems are missing
* rake (12.3.3)
Install missing gems with `bundle install`
$ bundle install
Fetching gem metadata from https://rubygems.org/.
Installing rake 12.3.3
Using bundler 2.1.0.pre.1
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Bundled gems are installed into `./.bundle`
```
In the case of `bundle cache --path`, it has never really work as I expect
So we should deprecate `bundle check --path` and instead use whatever path is configured.
The cache of `bundle cache --path` is not as clear. Currently it does remember the flag for subsequent `bundle install` runs, but it does not change the location where subsequent `bundle cache` or `bundle install` runs save their cache. So I'm not sure how the current behavior is useful.
### What is your fix for the problem, implemented in this PR?
My fix is, pending further discussion on what the expected behavior for `bundle cache` is, to only deprecate `bundle check --path`, and in the case of `bundle cache` I only fixed the option description to not say it remembers the option in bundler 3.
Finally, I added a minor change in the deprecation message to recommend `bundle config set path <path>` instead of `bundle config path <path>`, because the latter is deprecated.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the subset of all this that seemed clearly like the way to go.
Fixes #7300.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| | |
And skip them all for bundler 3.
|
| | |
|
| |
| |
| |
| | |
To not mention that the flag is remembered when it's not.
|
| | |
|
| |
| |
| |
| | |
It was suggested a deprecated command as a fix.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7329: Undo auto multiplatform r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that since #7215, more Gemfiles are going to fail resolution because of the current issues with multiplatform support, and that we'll be pushing current multiplatform problems into all users because bundler will resolve and lock all platforms included on a Gemfile by default.
### What was your diagnosis of the problem?
My diagnosis was that we probably need better multiplatform support before we start resolving all platforms by default.
### What is your fix for the problem, implemented in this PR?
My fix is to revert the relevant commits from #7215. I'll try to revisit in the future.
### Why did you choose this fix out of the possible options?
I chose this fix because it goes back to how things were before.
Closes #7315.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | | |
This reverts commit 3dc509e645abb497e4dc92a7c42be471ff87db0b.
|
| | |
| | |
| | |
| | | |
This reverts commit 00b095b98fe4bd44950beaf3bc9f1d91eac7b69e.
|
| | |
| | |
| | |
| | | |
This reverts commit 52c5a0eedec34b5d86464b3cf135dc2002486f1d.
|
|/ /
| |
| |
| | |
This reverts commit 3a2d2f025081755bdb38af660897e7b2f749a33a.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7324: Remove `:ruby_core` tag for ruby core r=hsbt a=hsbt
This pull request is backported from https://github.com/ruby/ruby/pull/2380
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* These seem to consistenly pass already
* Show actual command when running `make test-bundler`
Current the setup command that installs the necessary gems for testing
bundler was printed, but not the actual command that runs the tests.
That was a bit confusing.
* Borrow trick from setproctitle specs
* A title that long doesn't get set sometimes
No idea why, but the test doesn't need that the title is that long.
* Fix most gem helper spec ruby-core failures
* Fix the rest of the gem helper failures
* Fix version spec by improving the assertion
* Remove unnecessary `BUNDLE_RUBY` environment var
We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name
because bundler considers `BUNDLE_*` variables as settings.
* Rename `BUNDLE_GEM` to `GEM_COMMAND`
This is more descriptive I think, and also friendlier for bundler
because `BUNDLE_` env variables are interpreted by bundler as settings,
and this is not a bundler setting.
This fixes one bundler spec failure in config specs against ruby-core.
* Fix quality spec when run in core
Use the proper path helper.
* Fix dummy lib builder to never load default gems
If a dummy library is named as a default gem, when requiring the library
from its executable, the default gem would be loaded when running from
core, because in core all default gems share path with bundler, and thus
they are always in the $LOAD_PATH. We fix the issue by loading lib
relatively inside dummy lib executables.
* More exact assertions
Sometimes I have the problem that I do some "print debugging" inside
specs, and suddently the spec passes. This happens when the assertion is
too relaxed, and the things I print make it match, specially when they
are simple strings like "1.0" than can be easily be part of gem paths
that I print for debugging.
I fix this by making a more exact assertion.
* Detect the correct shebang when ENV["RUBY"] is set
* Relax assertion
So that the spec passes even if another paths containing "ext" are in
the load path. This works to fix a ruby-core issue, but it's a better
assertion in general. We just want to know that the extension path was
added.
* Use folder structure independent path helper
It should fix this spec for ruby-core.
* Fix the last failing spec on ruby-core
* Skip `bundle open <default_gem>` spec when no default gems
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7322: Fix comments and messages to refer to https url r=bronzdoc a=giraffate
### What was the end-user problem that led to this PR?
End-users experience 301 redirect, or unintentionally visit URL with http.
### What was your diagnosis of the problem?
Following are some examples using curl to explain this problem.
```
$ curl -I http://github.com/capistrano/bundler
HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: https://github.com/capistrano/bundler
```
```
$ curl -I http://guides.rubygems.org/gems-with-extensions/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Server: GitHub.com
Location: https://guides.rubygems.org/gems-with-extensions/
X-GitHub-Request-Id: 0A1A:1377:32938B:35C160:5D5D5A84
Content-Length: 162
Accept-Ranges: bytes
Date: Wed, 21 Aug 2019 14:51:49 GMT
Via: 1.1 varnish
Age: 0
Connection: keep-alive
X-Served-By: cache-tyo19949-TYO
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1566399109.014809,VS0,VE168
Vary: Accept-Encoding
X-Fastly-Request-ID: 9357ee98e56565f92489c8a4e03235ab60eeb27f
```
### What is your fix for the problem, implemented in this PR?
My fix is to replace http URLs with https URLs.
### Why did you choose this fix out of the possible options?
It's because this fix is simple and easy.
Co-authored-by: Takayuki Nakata <f.seasons017@gmail.com>
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7321: Don't (yet) enable parallelization in CI r=bronzdoc a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that unfortunately #7317 broken rubygems test suite. See https://github.com/rubygems/rubygems/pull/2888.
### What was your diagnosis of the problem?
My diagnosis was that it has some issues.
### What is your fix for the problem, implemented in this PR?
My fix is to not (yet) use it in CI, so we can keep using it locally and investigating these issues without interfering with our CI. In a while we reevaluate how it is working a consider enabling in CI.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ / /
| | |
| | |
| | | |
Since it still has issues.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7317: Parallelize test suite (Take 2) r=hsbt a=hsbt
### What was the end-user problem that led to this PR?
This branch reduced test time of bundler.
### What was your diagnosis of the problem?
#7232 has a conflict with the current master branch.
### What is your fix for the problem, implemented in this PR?
I picked a commit for parallelized tests from #7232
### Why did you choose this fix out of the possible options?
Fixed https://github.com/bundler/bundler/pull/7232
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7310: Freeze time to avoid failures at midnight r=deivid-rodriguez a=kazu9su
### What was the end-user problem that led to this PR?
The problem was it will potentially fail if tests are executed around midnight
### What was your diagnosis of the problem?
My diagnosis was it should freeze time when executing spec
### What is your fix for the problem, implemented in this PR?
My fix is mocking `Time.now` when executing `Bundler::BuildMetadata` specs
### Why did you choose this fix out of the possible options?
I chose this fix because it doesn't have effects on other specs.
Co-authored-by: lolwut <lol@wut.com>
|
| |/
| |
| |
| |
| |
| | |
Specify just a string
set @built_at as nil before testing
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7313: Fix a couple of typos r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was typos.
### What is your fix for the problem, implemented in this PR?
My fix is to correct typos.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7312: Remove old rubies stuff no longer needed r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that was still some code specific to old rubies we no longer support.
### What is your fix for the problem, implemented in this PR?
My fix is to remove that code.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | |
| | | |
Our current set of specs is the same for all supported rubies, and we
should keep it that way.
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7274: Fix more leaks to default copy of bundler r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that in some places, it was still possible to end up requiring files in a different copy of bundler (the default copy). I noticed this when I removed a rubygems monkeypatch from the test suite that was preventing the default copy of bundler from being activated when requiring files.
This thing:
https://github.com/bundler/bundler/blob/e1c518363641208429f397170354054b3d28effd/spec/support/hax.rb#L15-L20
### What was your diagnosis of the problem?
My diagnosis was that I should use relative requires wherever they were missing.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the rubygems hack, migrate the rest of the internal requires to be relative, and also introduce some hacks on our specs to make sure we never load the incorrect copy of bundler.
I think this PR should fix the issues in https://github.com/rubygems/rubygems/pull/2863.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The version we're vendoring actually relaxed this restriction back to
2.3.0+, so we can always use the vendored version.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead, make sure we always load the local copy of bundler during
specs, and never end up using the default copy.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If we use system bundler, when booting the "outermost" bundler process,
bundler will save the path to the system bundler in BUNDLE_BIN_PATH, and
use it again when booting the "innermost" bundler process (`bundle exec
echo foo`).
That means that second process will use the system bundler path again.
However, we have `-rsupport/hax` in RUBYOPT, so that file will load from
the local copy of bundler, and that file will load `bundler/version`
from the project (not from system), because -Ilib is in the LOAD_PATH.
That will end up causing redefinition errors because the same constant
will be loaded from two different locations.
In general, this is expected behavior, normally you will wrap the
process with `Bundler.with_original_env` to reset the environment.
However, the easiest fix here is to not use system bundler, because it's
not really necessary and thus doesn't help the readability of the spec.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7302: Bundler displays a duplicate gem entries warning even if gems only appear once per group r=hsbt a=davidstosik
### What was the end-user problem that led to this PR?
I have a Gemfile where some gems appear in two distinct groups. When I run Bundle, the following warning is displayed:
> Your Gemfile lists the gem #{gem} more than once.
> You should probably keep only one of them.
> Remove any duplicate entries and specify the gem **only once (per group)**.
> While it's not a problem now, it could cause errors if you change the version of one of them later.
Example Gemfile:
```rb
source "https://rubygems.org"
group :production do
end
group :development do
gem "rake"
end
group :ci, optional: true do
gem "rake"
end
```
### What was your diagnosis of the problem?
I think the message is misleading, because it shows even if all gems are specified **only once per group**.
### What is your fix for the problem, implemented in this PR?
I removed the _(per group)_ mention from the warning message in order to prevent confusion.
### Why did you choose this fix out of the possible options?
I chose this fix because it was the simplest way to bring your attention to the problem.
If Bundler's real intent is to allow the same gem to appear in multiple groups, as long as it does not appear more than once per group, then my suggestion is wrong, and instead, the logic around the warning message needs to be fixed.
Co-authored-by: David Stosik <david.stosik+git-noreply@gmail.com>
|
| | | |
| | | |
| | | |
| | | | |
once per group
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7309: Fix `bundle doctor` command r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundle doctor` crashes on very simple usages, like this:
````
$ bundle doctor
The Gemfile's dependencies are satisfied
--- ERROR REPORT TEMPLATE -------------------------------------------------------
# Error Report
## Questions
Please fill out answers to these questions, it'll help us figure out
why things are going wrong.
- **What did you do?**
I ran the command `/home/deivid/.rbenv/versions/2.6.3/bin/bundle doctor`
- **What did you expect to happen?**
I expected Bundler to...
- **What happened instead?**
Instead, what happened was...
- **Have you tried any solutions posted on similar issues in our issue tracker, stack overflow, or google?**
I tried...
- **Have you read our issues document, https://github.com/bundler/bundler/blob/master/doc/contributing/ISSUES.md?**
...
## Backtrace
```
Errno::ENOENT: No such file or directory - /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0/bundler
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/find.rb:43:in `block in find'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/find.rb:43:in `collect!'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/find.rb:43:in `find'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/doctor.rb:105:in `each'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/doctor.rb:105:in `check_home_permissions'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/doctor.rb:83:in `run'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:652:in `doctor'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:26:in `dispatch'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:17:in `start'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:30:in `block in <top (required)>'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:22:in `<top (required)>'
/home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `load'
/home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `<main>'
```
## Environment
```
Bundler 2.1.0.pre.1
Platforms ruby, x86_64-linux
Ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
Full Path /home/deivid/.rbenv/versions/2.6.3/bin/ruby
Config Dir /home/deivid/.rbenv/versions/2.6.3/etc
RubyGems 3.1.0.pre1
Gem Home /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0
Gem Path /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0
User Home /home/deivid
User Path /home/deivid/.gem/ruby/2.6.0
Bin Dir /home/deivid/Code/playground/bundler/chcek/.bundle/ruby/2.6.0/bin
Tools
Git 2.22.1
RVM not installed
rbenv rbenv 1.1.2
chruby not installed
```
## Bundler Build Metadata
```
Built At 2019-08-15
Git SHA 91f91a1ad
Released Version false
```
## Bundler settings
```
gem.test
Set for the current user (/home/deivid/.bundle/config): "rspec"
gem.mit
Set for the current user (/home/deivid/.bundle/config): true
gem.coc
Set for the current user (/home/deivid/.bundle/config): true
default_cli_command
Set for the current user (/home/deivid/.bundle/config): "install"
path_relative_to_cwd
Set for the current user (/home/deivid/.bundle/config): true
path
Set for your local app (/home/deivid/Code/playground/bundler/chcek/.bundle/config): ".bundle"
```
## Gemfile
### Gemfile
```ruby
source "https://rubygems.org"
gem "rake", "12.3.2"
gem "byebug", "~> 11.0"
```
### Gemfile.lock
```
GEM
remote: https://rubygems.org/
specs:
byebug (11.0.1)
rake (12.3.2)
PLATFORMS
ruby
DEPENDENCIES
byebug (~> 11.0)
rake (= 12.3.2)
BUNDLED WITH
2.1.0.pre.1
```
--- TEMPLATE END ----------------------------------------------------------------
Unfortunately, an unexpected error occurred, and Bundler cannot continue.
First, try this link to see if there are any existing issue reports for this error:
https://github.com/bundler/bundler/search?q=No+such+file+or+directory+-+%2Fhome%2Fdeivid%2FCode%2Fplayground%2Fbundler%2Fchcek%2F.bundle%2Fruby%2F2.6.0%2Fbundler&type=Issues
If there aren't any reports for this error yet, please create copy and paste the report template above into a new issue. Don't forget to anonymize any private data! The new issue form is located at:
https://github.com/bundler/bundler/issues/new
````
### What was your diagnosis of the problem?
My diagnosis was that `Bundler.home` is not the folder this command should use, because that folder is in reality the "home" for git gems and bundler plugins, not the home for the whole bundle. So it sometimes doesn't exist and the command crashes.
### What is your fix for the problem, implemented in this PR?
My fix is to use the proper "home".
### Why did you choose this fix out of the possible options?
I chose this fix because it's better than rescuing the error. It was an unexpected error, so we should fix it.
Fixes #6820
Closes #6824.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously `bundle doctor` would fail on any bundle that does not
include git gems or plugins. This is because the previously used
`Bundler.home` does not exist unless the bundle includes git gems or
plugins. For example, with `bundle config set path .bundle`, it points
to which does not exist unless this kind of gems exist in the Gemfile.
The name `Bundler.home` is really unfortunate, it should probably be
have more descriptive name, and be private. But for now I just want to
make `bundle doctor` usable.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7311: Use the latest rubygems 3.0.6 in CI r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that [rubygems 3.0.6 was released](https://blog.rubygems.org/2019/08/16/3.0.6-released.html), and we haven't yet tested against it.
### What is your fix for the problem, implemented in this PR?
My fix is to use the new rubygems in CI.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |_|/
| |/| | |
|