| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7007: Remove lockfile incompatibility created by the `lockfile_uses_separate_rubygems_sources` setting r=deivid-rodriguez a=deivid-rodriguez
This is more of a question PR, I created this patch to try it out and try to understand, not necessarily get it merged.
### What was the end-user problem that led to this PR?
The problem was that once we enable the `lockfile_uses_separate_rubygems_sources` setting, all lockfiles in the world will become incompatible with the previous version. Actually, not necessarily incompatible, but bundler will reorder the sections when the setting is enabled, that will generate churn lock file diffs, and _maybe_ some confusion / merge conflicts, and so on.
### What was your diagnosis of the problem?
My diagnosis was that maybe this is not necessary. I read over the issues where this setting was added and what I understood is that previously if a Gemfile specified multiple rubygems sources, they would all get merged together and that's dangerous because it's not deterministic from which source each gem will be picked up, and that could be maliciously exploited. So now each source gets its own separate section. However, how does that affect the ordering of the sections? I don't think it should affect it?
### What is your fix for the problem, implemented in this PR?
My fix is to change the `lock_sources` method so that both code branches (`lockfile_uses_separate_rubygems_sources == true`, and `lockfile_uses_separate_rubygems_sources == false`) result in the same ordering of the source sections.
### Why did you choose this fix out of the possible options?
I chose this fix because I _think_ it keeps the setting doing the same thing, but also keeps lock file compatibility.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| |
| | |
The `lockfile_uses_separate_rubygems_sources` was causing a lockfile
incompatibility but in my opinion, this incompatibility is not necessary
in the general case.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7090: Make sure spec fails if gems cannot be installed r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was if the installation if system gems failed during specs failed, that was being silently ignored.
### What was your diagnosis of the problem?
My diagnosis was that if this installation fails, the specs that use this helper are not probably testing what they should
### What is your fix for the problem, implemented in this PR?
My fix is to use the bang method instead.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ /
| |
| |
| |
| |
| |
| | |
The `realworld_system_gems` helper was failing to install these gems
under rubygems master, and because of that, the related spec was
actually passing, without actually checking for the regression it was
meant to check.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7080: Always pass the `--all` flag when needed r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs were still using `bundle update` to update all gems, which is deprecated.
### What is your fix for the problem, implemented in this PR?
My fix is to update all specs to use the new preferred command, namely, `bundle update --all`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7082: Complete some missing specs r=deivid-rodriguez a=deivid-rodriguez
This is a follow up to #7052.
### What was the end-user problem that led to this PR?
The problem was that the `Bundle.with_clean_env` & `Bundle.with_original_env` family was missing some deprecation specs, and also the specs were spread out across different files.
### What is your fix for the problem, implemented in this PR?
My fix is to add the missing specs, and centralize them in the deprecation specs file.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |/ / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6963: Allow to `bundle exec` default gems r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that since `irb` and others were moved to default gems, users cannot directly use them in a bundler context, unless they add it to their gemfiles. In my opinion, this completely defeats the purpose of default gems, and makes bundler degrade the user experience instead of making it better.
### What was your diagnosis of the problem?
My diagnosis was that when bundler replaces the set of gems known to rubygems, it restricts the world to what's in the Gemfile (or resolved from it), and that doesn't include default gems.
### What is your fix for the problem, implemented in this PR?
My fix is to also include the set of default gems, unless they are already included in the gemfile dependencies.
### Why did you choose this fix out of the possible options?
I chose this fix because it's reasonably simple and I think it shouldn't affect how other parts of bundler function.
Fixes #6929.
Fixes https://bugs.ruby-lang.org/issues/15503.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Even when they are not explicitly specified in the Gemfile.
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7026: Add missing `bundle info` feature, bug fix, and specs r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundler info GEM` did not have feature parity with `bundle show GEM`, and it should because it's the recommended alternative. Also, `bundle info bundler` was showing an incorrect path while `bundle show bundler` was correct.
### What was your diagnosis of the problem?
My diagnosis was that some code should be pulled from `bundle show`.
### What is your fix for the problem, implemented in this PR?
My fix is to port the missing feature, bug fix, and specs to `bundle info` from `bundle show`.
### Why did you choose this fix out of the possible options?
I chose this fix because it guarantees that the recommended alternative will work similarly to the current show command.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | | |
| | | |
| | | | |
Just exit.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The raise is using the name of the class on its message!
```
Could not find gem 'Bundler::CLI::Common'.
```
Since we've never received a WTF report about this, I'll assume this is
just dead code and remove it.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Just like `bundle show rails` did.
|
| | | |
| | | |
| | | |
| | | | |
Skip for now the functionality not currently supported in `bundle info`.
|
| | | |
| | | |
| | | |
| | | | |
To be just like how current `bundle show` is tested.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This case `bundle info rails` is already tested at the beginning of the
file. Plus, the description is misleading since no `--path` option is
given here.
|
| | | |
| | | |
| | | |
| | | | |
For consistency with `bundle show` specs.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7079: Remove `bundle config` deprecations from specs r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs still use the deprecated `bundle config interface`
### What is your fix for the problem, implemented in this PR?
My fix is to use the newer interface.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7070: Improve cross repo integration r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we had on `rubygems`, we're not testing bundler against the rubygems checkout of each PR, but against master. That is confusing because developers assume that the PRs tests will run against the PRs code, but this is currently not true.
### What was your diagnosis of the problem?
My diagnosis was that on rubygems we are [specifying `RGV=master`](https://github.com/rubygems/rubygems/blob/fa6e547330e97b417ed11f262d68d03c57abeeda/.travis.yml#L12) in our TravisCI matrix. And what `bundler` does with that is to clone rubygems master under `tmp/rubygems` and use that. Thus your rubygems PR is not really tested.
### What is your fix for the problem, implemented in this PR?
My fix is to rework the setup to accept an `RGV` environment variable when it contains. In that case, no git operations will be performed, and that path will be used directly and assumed to contain a rubygems checkout.
I also refactored a few things about the setup while at it.
### Why did you choose this fix out of the possible options?
There were existing tasks to test bundler against a rubygems checkout, but they were unused and they expected a `RG` environment variable instead. I decided to reuse these tasks, but make them pick up the `RGV` as long as it contains a valid path. I chose this fix because it works and it doesn't make the existing setup too different.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I don't plan to support running this binstub from outside of the root
folder.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Since it's meant for CI.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Delegate everything to `bin/with_rubygems` instead.
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
7073: Unskip passing spec r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I discovered by chance that one of the skipped specs seems to be passing.
### What was your diagnosis of the problem?
My diagnosis was that something has changed for the better that made this spec green.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the skip.
### Why did you choose this fix out of the possible options?
I chose this fix because it's good :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / / / |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
7074: Remove unnecessary test stuff r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that our test setup could be simpler.
### What was your diagnosis of the problem?
My diagnosis was that some lines installing test gem dependencies could be removed from the Rakefile, because the tests already detect this situation and auto-install test gems appropriately.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the lines. However, removing the lines led to a single test failure that can be explained becase `FileUtils` ends up being required too late, thus skipping one call to `Gem.clear_paths` done in the tests setup so that stuff memoized by `rubygems` is cleared and tests can assume is not loaded yet. The situation is very intricate but I tried to explain it in the commit message.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the test failure, but I also plan to propose to eliminate the `autoload` calls in rubygems that also contributed to this issue.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Tests automatically download and install the test gems they need if not
installed, so this should be unnecessary.
However, removing it create a single spec failure only reproducible on a
fresh clone (where the path where the test gems are installed,
`tmp/gems`, has not yet been populated.
The problem was that the code branch that installs the gems uses the
`FileUtils` constant. Accessing that constant makes [this autoload]
trigger the custom rubygems `require` behavior which will end up setting
and memoizing `gem_home` to the value it has at that point (when calling
`to_spec` on the selected default gem). But at that point,
`Gem.clear_paths` call has already happened, that means `gem_home` won't
be changed during the duration of the test because it's memoized.
This situation makes a specific test that updates `ENV["HOME"]` and
expects he path to the configuration file rubygems uses to be updated fail.
This could be fixed by removing the `FileUtils` autoload, or stop
memoizing `Gem.home`, but the simplest fix seemed to require `fileutils`
early, so that `Gem.home` is not memoized again after calling
`Gem.clear_paths`.
[this autoload]: https://github.com/rubygems/rubygems/blob/511a0f5105ca95b8e389bf477b6c7cf3e90be7d1/lib/rubygems/source.rb#L3
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
7078: Allow `update` to install when `--no-install` used r=colby-swandale a=deivid-rodriguez
Fixes #7077.
### What was the end-user problem that led to this PR?
The problem was #7077. When the `no_install` configuration is activated, this prevents `bundle update` from installing gems, but `no_install` is only meant to affect `bundle package`.
### What was your diagnosis of the problem?
My diagnosis was that `bundle update` needs to ignore this setting.
### What is your fix for the problem, implemented in this PR?
My fix is to the same `bundle install` does to fix this problem.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the most straightforward solution, although the handling of this flag could probably use some refactoring.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / / /
| | | | |
| | | | |
| | | | | |
The `--no-install` flag flag is only meant for `bundle package`.
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7035: Unify the certificates for rubygems.org to rubygems store. r=deivid-rodriguez a=hsbt
### What was the end-user problem that led to this PR?
The problem was the users have duplicated certificates in their boxes.
### What was your diagnosis of the problem?
I wonder why bundler has a certificates copy from rubygems. It raised up in the tracker of ruby core.
https://bugs.ruby-lang.org/issues/15384
### What is your fix for the problem, implemented in this PR?
I removed the duplicated certificates from bundler, and fallback to rubygems's one.
### Why did you choose this fix out of the possible options?
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* Removed CertificateManager and related rake tasks.
* Removed the certificates from bundler internal.
|
|\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7068: Bump vendored fileutils to 1.2.0 r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was we manually updated some code in the vendored fileutils instead of using a released version.
### What was your diagnosis of the problem?
My diagnosis was that we should use the recently released fileutils 1.2.0.
### What is your fix for the problem, implemented in this PR?
My fix is to vendor it through `bin/rake vendor:fileutils[v1.2.0]`.
### Why did you choose this fix out of the possible options?
I chose this fix because it properly upgrades the vendored code to match what's last released.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7036: Bump travis rubies r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that hacks create confusion, even if they include TODO notes.
### What was your diagnosis of the problem?
My diagnosis was that we can should upgrade to the latest ruby releases to reduce the number of hacks we need to maintain.
### What is your fix for the problem, implemented in this PR?
My fix is to upgrade rubies and remove hacks.
### Why did you choose this fix out of the possible options?
I chose this fix because it's a good change.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|