| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Try to fix failure at https://github.com/ruby/ruby/runs/207580232#step:10:382
```
undefined method `name' for "Gemfile.lock":String
/home/runner/work/ruby/ruby/lib/bundler/resolver/spec_group.rb:65:in `eql?'
```
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7340: Fix bundle clean issue r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundle clean` is crashing under some conditions.
### What was your diagnosis of the problem?
My diagnosis was that sometimes (when the bundle includes git sourced gems with extensions), it assumes that some paths exist, but they don't.
### What is your fix for the problem, implemented in this PR?
My fix is to ignore those paths.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the issue.
Fixes #7338.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| |
| | |
It would crash when git gems with extensions were included in the
bundle, but excluded through `BUNDLE_WITHOUT`.
|
| |/
|
|
|
| |
There are more issues than this, but hopefully this is enough
to get make test-bundler passing in CI.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
| |
| |
| | |
To not mention that the flag is remembered when it's not.
|
| | | |
|
| | |
| |
| |
| | |
It was suggested a deprecated command as a fix.
|
| | |
| |
| |
| | |
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
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | | |
|
| | |_|/
|/| | |
|
| |/ / |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7301: Track changes from ruby core master r=hsbt a=hsbt
### What was the end-user problem that led to this PR?
I'm going to merge https://github.com/bundler/bundler/pull/7274. But the ruby-core source has some of the changes for bundler source.
### What was your diagnosis of the problem?
### What is your fix for the problem, implemented in this PR?
ruby core team fixed them:
* Removed circular require warning at `shared_helper.rb`
* Support test at GitHub Actions, It helps that bundler will migrate Actions from Azure Pipelines too.
* Fixed broken examples at ruby core repository
### Why did you choose this fix out of the possible options?
Co-authored-by: ohbarye <over.rye@gmail.com>
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
Co-authored-by: Yusuke Endoh <mame@ruby-lang.org>
|
| | |
| |
| |
| | |
Because it causes circular require.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7263: Add `--[no-]git` option to `bundle gem` r=simi a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that while reproducing #7262, I actually wanted a single git repo, and every subgem source controlled under a single git repository. However, this cannot be done by default.
### What was your diagnosis of the problem?
My diagnosis was that we could add a `--no-git` option to `bundle gem`, so that git repository initialization is skipped. I think this can be specially useful for monorepos.
### What is your fix for the problem, implemented in this PR?
My fix is to implement the flag.
### Why did you choose this fix out of the possible options?
I chose this fix because it's quite simple, and it solves my request.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| |
| | |
I think using `--no-git` can be useful when creating gems inside
monorepos.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously under some circunstances (met during some specs), bundler
would print deprecations to a separate UI different from "bundler's UI".
This UI would not be captured by the specs, and thus would be printed to
screen during the specs.
This commit fixes that by making sure all deprecation messages always go
through bundler's UI.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7264: Consistent lockfiles r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that when a Gemfile would specify path sources with paths starting with "./", the generated lockfile would be inconsistent on `bundle install` and `bundle update`.
### What was your diagnosis of the problem?
My diagnosis was that when running `bundle update`, the bundle would be unlocked, and bundler would order the path sources according to the path present in the Gemfile ("./aaa" for example). On the other hand, when running `bundle install`, bundler would read the relative paths from the lockfile, where they are normalized ("aaa" for example).
### What is your fix for the problem, implemented in this PR?
My fix is to normalize relative paths when creating the source list, so that "aaa" is always used over "./aaa".
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem and it's backwards compatible (as in, it doesn't break any specs that assert for specific lockfiles).
Fixes #7262.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
When Gemfile would specify path sources as relative paths starting with
"./", the lockfile would have inconsistent order on `bundle install` and
`bundle update`.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
* RUBY_ENGINE and RUBY_ENGINE_VERSION are defined on every modern Ruby.
* There is no such constant as TRUFFLERUBY_VERSION or RBX_VERSION.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7267: Use RbConfig::CONFIG directly instead of Gem::ConfigMap. r=deivid-rodriguez a=hsbt
### What was the end-user problem that led to this PR?
When we try to remove `Gem::ConfigMap` on rubygems repository, It breaks the bundler examples.
https://github.com/rubygems/rubygems/pull/2848#issuecomment-515726585
### What was your diagnosis of the problem?
Gem::ConfigMap is compatibility code for the old Ruby like 1.8/1.9.
### What is your fix for the problem, implemented in this PR?
Use RbConfig instead of `Gem::ConfigMap` directly. It was always provided after the Ruby 2.x.
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Gem::ConfigMap is compatibility code for the old Ruby like 1.8/1.9.
|
| | |_|/
|/| |
| | |
| | |
| | | |
And reenable exclusion because the bug why we added them has been fixed.
See https://github.com/rubocop-hq/rubocop/issues/6861.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7123: Refactors to `bundle outdated` r=deivid-rodriguez a=ryanfox1985
### What was the end-user problem that led to this PR?
Code in `bundle outdated` code be simpler and more readable.
### What is your fix for the problem, implemented in this PR?
My fix is to refactor the command.
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To indicate that it can raise.
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It's the only usage of the `options_include_groups` attribute and its
name suggests a boolean, so it fits better now.
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
