| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
7417: Fix bundler/inline warning: method redefined; discarding old root r=deivid-rodriguez a=fatkodima
Closes #6167
Co-authored-by: fatkodima <fatkodima123@gmail.com>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7416: Don't use insecure temporary directory as home directory r=deivid-rodriguez a=fatkodima
Closes #6501
Co-authored-by: fatkodima <fatkodima123@gmail.com>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7427: Pass `env` as a parameter to `sys_exec` r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that Windows has trouble with commands of the form `BUNDLE_FROZEN=true bundle install`.
### What was your diagnosis of the problem?
My diagnosis was that we should use `Open3.popen3` explicit `env` argument instead of passing a command line that has environment variables in the front.
### What is your fix for the problem, implemented in this PR?
My fix is to do just that. This is a follow up to #7011, but specifically for the `ruby` test helper. I expect this to fix some more Windows failures.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7426: Revert "I don't think we need this now" r=deivid-rodriguez a=deivid-rodriguez
This reverts commit 36816866581147ba7bd491a2a658ac35a2f03afe.
### What was the end-user problem that led to this PR?
The problem was that in #7401, after I got specs passing against a non-silenced by default UI, I started undoing workarounds that I thought were due to the silent by default UI.
### What was your diagnosis of the problem?
My diagnosis was that in the case I'm reverting here this is not actually fixed, [as the Azure Pipelines logs confirm](https://dev.azure.com/bundler/bundler/_build/results?buildId=2662&view=ms.vss-test-web.build-test-results-tab&runId=1003360&resultId=101526&paneView=debug).
### What is your fix for the problem, implemented in this PR?
My fix is to unrevert the specific commit that I shouldn't have reverted.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / /
| | |
| | |
| | | |
This reverts commit 36816866581147ba7bd491a2a658ac35a2f03afe.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7425: Properly avoid readline crashes when running specs on Windows r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that specs cannot be run on windows unless you add the ugly workaround currently included in the azure pipelines config.
### What was your diagnosis of the problem?
My diagnosis was that the `tmp/tmpdir` and `tmp/home` folder (which act as `ENV["HOME"]` and `ENV["TMPDIR"]` for our specs) are emptied in an `around(:each)` hook, but there's some stuff going before that and after `ENV["HOME"]` and `ENV["TMPDIR"]` are set (on a `before(:suite)` hook) that might require the folders they point to to exist.
This is the case of rb-readline, used on Windows:
https://github.com/ConnorAtherton/rb-readline/blob/9fba246073f78831b7c7129c76cc07d8476a8892/lib/rbreadline.rb#L1096
or any bundler's code that uses `Bundler.user_home`:
https://github.com/bundler/bundler/blob/f83412ae8cda9c933b8cf33ec2abfb78a408daab/lib/bundler.rb#L227
For example, running `rm -rf tmp/ && bin/rspec ./spec/other/major_deprecation_spec.rb:368` prints a warning about this that it's fixed by this PR:
```
$ rm -rf tmp/ && bin/rspec ./spec/other/major_deprecation_spec.rb:368
Randomized with seed 1955
(... stuff ...)
`/home/deivid/Code/bundler/tmp/1/home` is not a directory.
Bundler will use `/tmp/bundler/home/deivid' as your home directory temporarily.
.
Retried examples: 0
Finished in 5.26 seconds (files took 0.17927 seconds to load)
1 example, 0 failures
Randomized with seed 1955
```
### What is your fix for the problem, implemented in this PR?
My fix is to create the folders as soon as the environment variables are set.
### Why did you choose this fix out of the possible options?
I chose this fix because it's more general that a workaround living on a specific CI config.
Fixes #6902.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This also avoids the following warning when running specs on any
platform:
```
`/home/deivid/Code/bundler/tmp/1/home` is not a directory.
Bundler will use `/tmp/bundler/home/deivid' as your home directory temporarily
```
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7424: Drop unnecessary `tempfile` require r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The `tempfile` dependency was dropped in [1], but the require was left in there. This could cause gem conflicts because `tempfile` requires `tmpdir` which requires `fileutils`, which loads the default gem instead of our namespaced version, and that could cause fileutils version mismatches and code overriding warnings.
[1]: https://github.com/bundler/bundler/commit/4a37d66f3f222739178d798b30fb135f2429fe45
### What is your fix for the problem, implemented in this PR?
My fix is to drop the unnecessary require.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `tempfile` dependency was dropped in [1], but the require was left
in there. This could cause gem conflicts because `tempfile` requires
`tmpdir` which requires `fileutils`, which loads the default gem instead
of our namespaced version, and that could cause fileutils version
mismatches and code overriding warnings.
[1]: https://github.com/bundler/bundler/commit/4a37d66f3f222739178d798b30fb135f2429fe45
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7393: Make 'bundle add' cache newly added gems when needed r=deivid-rodriguez a=andrehjr
### What was the end-user problem that led to this PR?
The problem was that when calling `bundle add` with cache_all as true, I have to call an additional `bundle install` to vendor gems.
### What was your diagnosis of the problem?
My diagnosis was that a call to Bundler.load.cache was missing. For example Bundler::CLI::Update does the same after installing gems.
### What is your fix for the problem, implemented in this PR?
My fix was to call Bundler.load.cache when `Bundler.app_cache.exist? `
### Why did you choose this fix out of the possible options?
I chose this fix because it looks like this makes the behavior consistent with other commands.
I should also say that, as this is my first PR here, I'm not sure that this is the best solution, and it seems an easy fix for #7384.
Co-authored-by: André Luis Leal Cardoso Junior <andrehjr@gmail.com>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7394: Add inline RDoc documentation r=hsbt a=zverok
Since Bundler became part of the standard library, it renders in Ruby's docs. Unfortunately, what renders there... is not really helpful: https://docs.ruby-lang.org/en/master/Bundler.html
I've added rudimentary documentation for `Bundler` module and two of its most user-facing methods to solve this problem at least partially.
Co-authored-by: zverok <zverok.offline@gmail.com>
|
| | | | | | |
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7398: Remove unnecessary lines from `bundler/setup` r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
These lines in the `bundler/setup` file are not necessary.
### What was your diagnosis of the problem?
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.
### What is your fix for the problem, implemented in this PR?
My fix is to remove these lines to make the code easier to follow.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7402: Spec normalizations r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I saw some room for improvement in our specs and I couldn't help myself :)
### What is your fix for the problem, implemented in this PR?
Essentially, the idea of this PR is to avoid using `__FILE__` or other folder-structure specific constructs to look for files, and instead use our helpers ìn `spec/support/path.rb`. The idea is that the helpers in this file are aware that `bundler` specs can be run from ruby-core or the upstream repo, and the folder structure is different for both.
Also, the PR normalizes some naming, some duplicated helpers, and the way we require files from specs.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
For consistency with `spec_dir`.
|
| | | | |
| | | |
| | | |
| | | | |
Call the helper with the same name instead.
|
| | | | |
| | | |
| | | |
| | | | |
The `spec` name is too common inside specs for `Gem::Specification`'s.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7411: Try out specs against MRI 2.6 + Rubygems 3.0 r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that our Azure build was using outdated versions of ruby and rubygems.
### What was your diagnosis of the problem?
My diagnosis was that we should update them.
### What is your fix for the problem, implemented in this PR?
My fix is to update them. With the latest versions, failures go down to 319.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7399: Fix some realworld specs testing nothing r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that this helper was printing nothing to the standard output, so the specs in this file were just checking if lockfiles contained the empty string, which is obviously true. For example,
https://github.com/bundler/bundler/blob/e70643c1be3a4417bd537d7e63470265465e693e/spec/realworld/edgecases_spec.rb#L31
### What was your diagnosis of the problem?
My diagnosis was that the helper needs to actually print the extracted information about the resolved gem, so it can be checked that the lockfile is correct.
### What is your fix for the problem, implemented in this PR?
My fix adds the missing `puts`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This helper was printing nothing to the standard output, so the specs
were just checking if lockfiles contained the empty string, which is
obviously true.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 0a67ac4dc2bad753e33e11352e97f73c9c1ddeee.
And fixes deprecation warnings in another way not that the UI verbosity
is predictable.
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7410: November man pages r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that man pages are outdated after the month change.
Well, the problem actually is that I need to fix in a better way (like a monthly scheduled rebuild or something), but I keep just updating the man pages every month... :sweat_smile:
### What is your fix for the problem, implemented in this PR?
My fix to run `bin/rake man:build` and commit the result.
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
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7388: Fix help with command aliases r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the output of `bundle help install` and `bundle install --help` was inconstent with `bundle i --help`, and the same issue with all of the other command aliases.
### What was your diagnosis of the problem?
My diagnosis was that the command reformatting so that `bundle <cmd> --help` "redirects" to `bundle help <cmd>` was ignoring command aliases.
### What is your fix for the problem, implemented in this PR?
My fix is to make this logic aware of command aliases.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`.
|
