| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bundler no longer needs to be in the `$LOAD_PATH` once a version of
itself has been loaded.
In any case, the `Metadata` source takes care of adding `bundler` to the
index:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/source/metadata.rb#L13-L30
and then that spec is added to the resolution here:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/definition.rb#L180-L184
And from the resulting set of specs, the `$LOAD_PATH` is setup:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler/runtime.rb#L25-L38
So `bundler` will be present in the `$LOAD_PATH` anyways, and the lines
being removed here will never be useful.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7404: Support multiple groups for --without-group and --only-group options … r=deivid-rodriguez a=fatkodima
This is a reworked version of #6939
It accepts multiple groups for `--without-group` and `--only-group`.
Closes #6939
Co-authored-by: fatkodima <fatkodima123@gmail.com>
|
| |
| |
| |
| | |
bundler list command
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7401: Stop silencing output by default r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that bundler defaults to a silent UI:
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/lib/bundler.rb#L66-L68
In my opinion, this isn't a good behavior for a CLI tool, and forces us to override it in many many different places. It has also caused several issues, for example, https://github.com/bundler/bundler/issues/3710 where `bundle list` was printing nothing.
The [solution to that issues](https://github.com/bundler/bundler/pull/3707) led us to add yet more places where we override the default UI, and @indirect [predicting that having to unset the UI everytime we want it to not be silent](https://github.com/bundler/bundler/pull/3707#issuecomment-108646127) would cause many headaches.
Well, yeah... I've lost a lot of time trying to figure out why UI was silent sometimes, and normal another times, why some specs printed warnings and some didn't. In particular, see my series of "big fail PRs" fighting against bundler's UI: https://github.com/bundler/bundler/pull/7284, https://github.com/bundler/bundler/pull/7294, https://github.com/bundler/bundler/pull/7305, https://github.com/bundler/bundler/pull/7362.
Another series of issues/PRs probably related to this is issue https://github.com/bundler/bundler/issues/6900, where the output would use a different UI on different environments. We had a lot of trouble to reliably fix it (https://github.com/bundler/bundler/pull/6994, https://github.com/bundler/bundler/pull/7002, https://github.com/bundler/bundler/issues/7253).
I also run into these issues again when trying out the `RUBYGEMS_GEMDEPS` environment variable that enables `bundler/setup` from rubygems.
### What was your diagnosis of the problem?
My diagnosis was that we shouldn't silence UI by default.
### What is your fix for the problem, implemented in this PR?
My fix is to, instead of silencing and then overriding the default shell at many places, don't silence it by default and instead make it silent when needed. By doing this, I managed to get 100% of our specs green, so I'm pretty confident that the output is still the same (or if it's not, it's probably because some output/errors where being unintentionally swallowed).
Now specs should pass, but they print a bunch of output to the screen. You can see error messages, hard crashes, success messages... Some of them might be showing actual issues with either the code or tests, so I plan to go through each of them and review them. I can do that in this PR or separately, no strong opinion.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7376: bundle info prints gem metadata r=deivid-rodriguez a=orien
### What was the end-user problem that led to this PR?
Rubygems has supported [gemspec metadata](https://guides.rubygems.org/specification-reference/#metadata) since version 2.0. I think it'd be great to display this information in response to the `bundle info <gem>` command.
### What is your fix for the problem, implemented in this PR?
Added a check for `metadata`, outputting this extra information if it has been included with the gem release. For example:
```
> bundle info rspec-mocks
* rspec-mocks (3.8.1)
Summary: rspec-mocks-3.8.1
Homepage: https://github.com/rspec/rspec-mocks
Documentation: https://rspec.info/documentation/
Source Code: https://github.com/rspec/rspec-mocks
Changelog: https://github.com/rspec/rspec-mocks/blob/v3.8.1/Changelog.md
Bug Tracker: https://github.com/rspec/rspec-mocks/issues
Mailing List: https://groups.google.com/forum/#!forum/rspec
Path: /opt/asdf/installs/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/rspec-mocks-3.8.1
```
For better readability, we could align the values. However, this would mean a change to the existing info property lines (`Summary`, `Homepage`, `Path` and `Default`). Which would potentially break existing scripts that are coupled to the precise output.
Co-authored-by: Orien Madgwick <_@orien.io>
|
| | |
| | |
| | |
| | |
| | | |
We can rely on it always being available since in our gemspec we set:
required_rubygems_version >= 2.5.2
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This provides more information about the gem to developers. For example:
bundle info rspec-mocks
* rspec-mocks (3.8.1)
Summary: rspec-mocks-3.8.1
Homepage: https://github.com/rspec/rspec-mocks
Documentation: https://rspec.info/documentation/
Source Code: https://github.com/rspec/rspec-mocks
Changelog: https://github.com/rspec/rspec-mocks/blob/v3.8.1/Changelog.md
Bug Tracker: https://github.com/rspec/rspec-mocks/issues
Mailing List: https://groups.google.com/forum/#!forum/rspec
Path: /opt/asdf/installs/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/rspec-mocks-3.8.1
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When using the `-h` flag with command aliases, bundler was showing a
default help page instead of our manual, so that for example, `bundle
help install` and `bundle install --help` output would be inconstent
with `bundle i --help`.
This commit fixes that.
|
| | |
| | |
| | |
| | | |
Since they were already consider aliases for `bundle help`.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Use a string when defining a single alias.
|
| |/
|/|
| |
| | |
To be consistent with the one above it.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7389: Wrap up `bundle cache` migration to current `bundle package` r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that after https://github.com/bundler/bundler/pull/7249, we added the current `bundle package` functionality to the current `bundle cache` command, so that these commands are now aliases of each other.
The initial plan was to do this in a more careful manner but we concluded that this was only _adding_ functionality to `bundle cache`, so not backwards incompatible.
We still need to wrap up the original plan, where `bundle cache` is the preferred command.
### What is your fix for the problem, implemented in this PR?
My fix is to migrate docs, tests and help text to use `bundle cache`, and to remove duplicated specs for `bundle cache` and `bundle package`, since they are testing the exact same code.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use the preferred `bundle cache` everywhere, but leave package as an
alias.
Remove duplicated tests.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This PR suppresses the following `Warning: no department given for MutableConstant`.
```console
% cd path/to/bundler
% bundle exec rubocop -v
0.75.1
% bundle exec rubocop --parallel
(snip)
/Users/koic/src/github.com/bundler/bundler/lib/bundler/gem_helpers.rb:
Warning: no department given for MutableConstant. Run `rubocop -a --only
Migration/DepartmentName` to fix.
```
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7385: Remove taint usage on Ruby 2.7+ r=hsbt a=jeremyevans
### What was the end-user problem that led to this PR?
Ruby 2.7 is deprecating taint support.
See https://bugs.ruby-lang.org/issues/16131 for details.
### What was your diagnosis of the problem?
Bundler still uses `untaint` in a few places, which will cause deprecation warnings on Ruby 2.7.
### What is your fix for the problem, implemented in this PR?
`s/\.untaint/.tap{|x| x.untaint if RUBY_VERSION < "2.7" }/g`
### Why did you choose this fix out of the possible options?
It seemed simplest.
Co-authored-by: Jeremy Evans <code@jeremyevans.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ruby 2.7 deprecates taint and it no longer has an effect.
This attempts to leave the behavior the same on older
Ruby versions, but avoid the use of untaint on Ruby 2.7+.
See https://bugs.ruby-lang.org/issues/16131 for details.
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7379: Switch to double quotes to match rest of file r=deivid-rodriguez a=jonathanhefner
### What was your diagnosis of the problem?
It is common to prefer double quotes, unless single quotes are needed. It is also generally preferred to use a consistent quote style (whether double quotes or single quotes).
### What is your fix for the problem, implemented in this PR?
Switch the anomalous single quotes to double quotes.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
`--parseable` checks `Bundler.ui.debug?` instead of look at the option
directly.
|
| | |
| | |
| | |
| | |
| | | |
All the other screen output and checks for `--parseable` are doing
inline, so let's do it here too.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
The "Latest" version may also be installed, so I think it's more
accurate to use "Locked" here.
|
| | | |
|
| | |
| | |
| | |
| | | |
I don't think it adds much to the output?
|
| | |
| | |
| | |
| | |
| | | |
The output feels a bit cleaner because there's more space, and the term
is more clear in my opinion.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
The list part doesn't add much and it's very implementation dependent.
|
| | |
| | |
| | |
| | |
| | | |
With this, if we rename the hash, we don't have to change the
indentation of every entry to keep it consistent.
|
| | | |
|
|/ / |
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7368: Bump version to latest pre-release r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I forgot to merge the version increase back to master after release.
### What is your fix for the problem, implemented in this PR?
My fix is to bump it.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| | |
Forgot to merge the version increase back to master after release.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7361: Add caller information to some deprecation messages r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some deprecations mention usage of deprecated methods, but include no information about where the deprecated method is being called.
### What was your diagnosis of the problem?
My diagnosis was that we should include this information with this kind of deprecation messages, to make migration easier.
### What is your fix for the problem, implemented in this PR?
My fix is to add an optional argument to the `major_deprecation` method, to print the location of the deprecated caller.
### Why did you choose this fix out of the possible options?
I chose this fix because it required little code changes.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| | |
Some deprecations would be fixed more easily if they included the
location where the deprecated method was called.
|
| | |
|