| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7100: Prefer `require_relative` for internal requires r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundler` seems to, in some very rare cases, leak to the copy of itself installed as a default gem. I have been able to reproduce this only for stuff that we have already fixed. For example: https://github.com/bundler/bundler/pull/6502. However, I have the gut feeling that this can still happen under some conditions, because sometimes we still get reports from people using bundler 2, and getting the error "You must user Bundler 2 or greater with this Gemfile".
### What was your diagnosis of the problem?
My diagnosis was that somehow, due to the complicated LOAD_PATH manipulation bundler does, we may endup requiring bundler files in another copy of bundler.
### What is your fix for the problem, implemented in this PR?
My fix is not really a fix, although it _might_ prevent the potential issue from happening. As @colby-swandale would say, we should fix the real culprit instead. However, I think using `require_relative` is a better practice anyways, because it makes it clear that you are requiring "internal" files and not files from some dependencies. And it should also be faster because it does not search the LOAD_PATH. And it skips the rubygems monkeypatches to `require`, which seems also good.
### Why did you choose this fix out of the possible options?
I chose this fix because I think it's a good practice.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| |
| |
| |
| | |
So that the spec can be run in isolation.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Due to the way rubygems monkey-patched require interacts with default
gems, and given that bundler is a default gem, and that bundler
manipulates the LOAD_PATH in very intricated ways, we can reduce the
risk of "leaking" to a different copy of `bundler` by using
`require_relative` for internal requires.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7115: Allow local install on jruby r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bin/rake install:local` fails on jruby.
### What was your diagnosis of the problem?
My diagnosis was that the `ronn` gem does not support `jruby`. Since the `install:local` task builds docs on the fly, the task crashes.
### What is your fix for the problem, implemented in this PR?
My fix is to make the `man:build` task a noop on jruby, so that `bin/rake install:local` can be run on jruby, so jruby users can easily try out bundler's master.
### Why did you choose this fix out of the possible options?
I chose this fix because it sounds like a good workaround.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | | |
So that `rake install:local` at least works.
|
| | |
| | |
| | |
| | |
| | | |
The ronn gem is needed for building man pages, that's already guarded.
The `release` task is irrelevant.
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7122: Remove standard output from `with_rubygems` r=deivid-rodriguez a=deivid-rodriguez
This PR might be very specific to my setup, but it would certainly help me.
### What was the end-user problem that led to this PR?
The problem was that sometimes I don't find out early about rubocop issues, so I have to push extra commits to fix them, and that means time and CI resources.
### What was your diagnosis of the problem?
My diagnosis was that:
* I run rubocop automatically on save from `vim using [ale](https://github.com/w0rp/ale).
* I set `ENV["RGV"] = master`, so that I always run the latest rubygems.
Because of setting `ENV["RGV"]`, the `with_rubygems` script is run everytime a binstub is loaded (including `rubocop`). This script prints some git information to the standard output. Since ALE expects a very specific output from `rubocop`, the fact that the `with_rubygems` script prints stuff to the standard output means that ALE no longer works, and I don't get to early fix style issues.
### What is your fix for the problem, implemented in this PR?
My fix is to make the `with_rubygems` script be silent.
### Why did you choose this fix out of the possible options?
I could've removed loading the `with_rubygems` script from the `rubocop` binstub, but I chose this fix because other subcommands in the script already seemed to try to be silent, like the `--quiet` flag passed to `git checkout`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7120: Fix spec calling incorrect helper r=deivid-rodriguez a=deivid-rodriguez
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was the subprocess spawed by one spec was crashing, but that was not making the spec fail.
### What was your diagnosis of the problem?
My diagnosis was that since the spec was checking for a failure status of the subprocess, that was not specific enough to detect the particular bug in this spec (it was calling `clean_system`, removed from bundler 3, instead of `unbundled_system`).
### What is your fix for the problem, implemented in this PR?
My fix is to restore the previous strategy for these specs, namely, check for a more specific status than 0
or 1.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The spec was crashing on bundler 3, but since the spec was checking for
a failure status for the subprocess, it was actually passing.
So, as part of this change, I make helper specs more resilient again.
These specs were previously checking for a more specific status than 0
or 1, but I removed that at some point. Now I see how it was useful, so
I'm restoring it.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7043: Remove old rubygems compatibility code r=bronzdoc a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I was unsure where I needed to add the compatibility layer to #6963, and it took me a bit to scan through the compatibility file and figure it out.
### What was your diagnosis of the problem?
My diagnosis was that all this compatibility code is unused but makes this file harder to understand and scan through.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the code.
### Why did you choose this fix out of the possible options?
I chose this fix because we can do it, I think.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | | |
The `full_gem_path` writer has been there since rubygems 2.2
|
| | |
| | |
| | |
| | | |
The `source` method has been there since rubygems 2.1.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7128: Backport to workaround from ruby core. r=deivid-rodriguez a=hsbt
### What was the end-user problem that led to this PR?
The current master branch couldn't invoke with the ruby core repository.
### What was your diagnosis of the problem?
1. We need to add explicitly declare `rspec` in spec_helper.rb
2. Some examples were failed on ruby core repository.
### What is your fix for the problem, implemented in this PR?
1. simply added.
2. update the `ruby_repo` labels for skipping to run.
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6730: Print errors to stderr by default, and remove configuration option r=greysteil a=greysteil
### What was the end-user problem that led to this PR?
The problem was #6729 - Bundler unexpectedly outputs error and warning messages to STDOUT.
### What was your diagnosis of the problem?
My diagnosis was that whilst very minorly breaking, this is essentially a bug fix, and should be considered for inclusion for Bundler 2.0 even if very few other breaking changes are.
### What is your fix for the problem, implemented in this PR?
My fix was so switch output for warning and error messages to STDERR, and remove the configuration option (as is redundant once the setup is flipped - anyone wanting to redirect those message to STDOUT could do so in their shell).
### Why did you choose this fix out of the possible options?
I chose this fix because I think the new behaviour is what everyone would expect, and we should get it out from behind its feature switch sooner rather than later.
Alternatively, we might want to keep the Bundler 2.0 release "purer" by only dropping Ruby versions in it - that's totally fine too, but I figured we should have the code to discus #6729, rather than doing it in abstract.
Co-authored-by: Grey Baker <greysteil@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
| |/| |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7075: Convert binstub conflict deprecation to a warning r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that this specific deprecation I don't think it makes sense as a deprecation.
### What was your diagnosis of the problem?
My diagnosis was that nothing is changing in bundler so that this needs to be a deprecation. This is just a potentially undesired situation that can be caused by gems shipping executables conflicting with the executables of other gems, and that can be fixed by using project specific binstubs.
### What is your fix for the problem, implemented in this PR?
My fix is to change this deprecation message to a warning, and to get it tested.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes sense to me. With this, we can start printing this warning now without thinking of a deprecation path because I don't think we're changing anything here, really.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
And test it.
I don't think it makes sense as a deprecation, since nothing is
changing, and there's no alternative. This is a potentially undesired
situation caused by gems shipping executables conflicting with the
executables of other gems. `bundle exec` is fine in general, this is
just a potentially undesired situation that can be fixed by using
project specific binstubs.
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7113: Make `init_gems_rb` a regular setting r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we have a feature flag to change the file name of the file where gems are defined from `Gemfile` to `gems.rb`, and it is unclear whether we will actually do this, and when.
### What was your diagnosis of the problem?
My diagnosis was that a feature flag is not a good fit here. It's perfectly fine to configure this and allow users to use `gems.rb` by default for their gems, but we don't know when/if we will actually change the default so a plain setting feels better than a feature flag.
### What is your fix for the problem, implemented in this PR?
My fix is to convert the `init_gems_rb` feature flag into a plain setting.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I think it's nice that users can configure this and start using
`gems.rb`. But there's no need to make this a feature flag and change
its default value. Let's keep generating Gemfile's by default until we
are ready, if we ever are.
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7112: Remove `prefer_gems_rb` setting r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we currently have a feature flag and setting, `prefer_gems_rb`, that currently does very very little, and it's not worth the maintenance cost in my opinion.
### What was your diagnosis of the problem?
My diagnosis was that the only situation where this setting makes a difference at the moment is when a project has both a `Gemfile` _and_ a `gems.rb` file. In that case, if `prefer_gems_rb` is enabled, the warning will tell the user to remove the `Gemfile` because it's being ignored, whereas if not enabled, it will tell the user to remove the `gems.rb` file because it's being ignored.
I think this setting might've made sense when we actually planned to really deprecate Gemfile's in the short term. Since I think we're not planning to deprecate Gemfile's at the moment, I think it's better to remove the setting.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the setting and keep supporting both names. In the weird case of both types being found in the same project, always prefer `gems.rb` and tell the user to remove the `Gemfile`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In my opinion, it's overkill to provide a setting for how little this
setting was doing. Both types of Gemfile are supported and work
regardless of this setting. The only difference this setting would make
is the warning message one would get when having _both_ types of
Gemfiles in the same project.
I changed things so that gems.rb is always looked up first, and the
warning message in case you have both always tells you to remove Gemfile
and Gemfile.lock.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6957: Move on to bundler 3 r=indirect a=colby-swandale
This PR contains the merge of `2-0-stable` to `master`
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | |
| | |
| | | |
* Drop bundler 1 stuff from tests.
* Move all feature flags to bundler 3 (like they are in 2-0-stable) and
get them tested.
|