| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7057: Review multiple sources deprecation r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I had not yet reviewed the deprecation about multiple global sources being present on a Gemfile, and thus the specs were skipped.
### What was your diagnosis of the problem?
My diagnosis was that we need to delay the removal of multiple sources support to bundler 3, so that we can show the deprecations in the 2.x series.
I also noticed that part of the deprecation message was inaccurate. In order to upgrade the warning to an error, you would also need to configure the `lockfile_uses_separate_rubygems_sources` setting. Otherwise you will get an error that these two settings depend on each other and can't be enabled separatedly.
### What is your fix for the problem, implemented in this PR?
My fix is to delay these feature flags to bundler 3 so that the deprecation specs pass. Also, since before giving this advice I'd like to study why we have two different settings that can't be enabled separately, and why the can't be merged to a single one, I have removed that part of the message for now.
### Why did you choose this fix out of the possible options?
I chose this fix because it keeps me moving with reviewing all the deprecations for bundler 3 breaking changes, and makes sure that the deprecations for this change of behavior are tested (and passing).
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, all specs would bundle a Gemfile from the "repo1" source by
default. Then, some list specs would end up using a "repo2" source. The
behavior when changing repo sources is changing with the
`disable_multisource` setting, but it is unrelated to the list command.
So, I refactored the list command specs to not change sources, and
extracted the behavior change about changing sources to a separate spec.
|
| | |
|
| | |
|
| |
| |
| |
| | |
And fix specs.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currenty one gets errors like
```
Failure/Error: lock_sources.to_set == replacement_sources.to_set
NoMethodError:
undefined method `to_set' for #<Array:0x0000560a01cd97c0>
Did you mean? to_s
```
|
| |
| |
| |
| |
| |
| | |
Move them to the file where all deprecations are tested. And test just
the simple case, since the deprecations logic should be the same for all
cases.
|
| |
| |
| |
| | |
Gemfile is not considered in this situation.
|
| |
| |
| |
| | |
`install_gemfile!` already runs that.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7110: Cleanup old rubies stuff r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that there was still some code specific for old rubies in our code base.
### 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>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The comment about this being for rubygems 1.8 compatibility seems wrong,
it was for ruby 1.8 compatibility, as can be seen by these docs:
https://ruby-doc.org/core-1.8.7/Module.html#method-i-instance_methods
https://ruby-doc.org/core-1.9.3/Module.html#method-i-instance_methods
|
| | |
| | |
| | |
| | | |
No longer provided by ruby since 1.8 times.|
|
| | |
| | |
| | |
| | | |
The specs needs that LOAD_PATH modification as of today to pass.
|
| | | |
|
| | |
| | |
| | |
| | | |
Stopped being used in 8b749ee85b04307135d368f05275d50e6cbf76a0.
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6951: Fix symlink spec on ruby 2.6 r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we were skipping this test on ruby 2.6. Skipping tests on old versions is not much of a problem, but doing it on the latest version is opening the door for regressions. So I want to fix it.
### What was your diagnosis of the problem?
My diagnosis was that since bundler is now a default gem, that bundler version is being activated by the spec, but since we are on a 2.0.1 locked bundle, the spec runs into a version mismatch error.
### What is your fix for the problem, implemented in this PR?
My fix is to enable the `Kernel.require` rubygems monkeypatch for this case (the `bundle` gem itself), that requires default gem files without activating the specific default version, and thus not forcing end users to use that. Since... that's exactly the problem here.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes sense to me.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In rubies where there's no default bundler gem, the original test
requiring that `bundler/setup` doesn't fail to load was correct. But in
rubies where there's a default bundler gem the bug would manifest in a
different way, by loading the incorrect default copy of bundler.
So we instead check that the copy of bundler that we load is the
(expected) symlinked one.
|
| |
| |
| |
| |
| | |
When running `bin/rspec spec/runtime/setup_spec.rb -e symlink`, I get an
"invalid byte sequence in US-ASCII" error. This commit fixes that.
|
| | |
|
| |
| |
| |
| |
| |
| | |
When running `bin/rspec spec/runtime/setup_spec.rb -e symlink`, you'll
get an "uninitialized constant `Tempfile`" error. This commit fixes
that.
|
| |
| |
| |
| |
| |
| | |
When running `bin/rspec spec/runtime/setup_spec.rb -e symlink`, you'll
get an "undefined method `mktmpdir' for Dir:Class" error. This commit
fixes that.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7104: Add missing method to rake file r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was any Rake task depending on the `:build_metadata` task is currently failing with ``NameError: undefined local variable or method `bundler_spec' for main:Object``. For example, the release or build tasks.
### What was your diagnosis of the problem?
My diagnosis was that I probably broke this during the development environment refactoring.
### What is your fix for the problem, implemented in this PR?
My fix is to add the missing method to the file that needs it.
### Why did you choose this fix out of the possible options?
I chose this fix because it works and it restores working tasks.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7105: Simplify deprecation specs r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was deprecation specs have become convoluted. The spawn many unnecessary subprocesses and do unnecessary work, and have complicated and redundant descriptions.
### What is your fix for the problem, implemented in this PR?
My fix is to reduce the nesting level of the specs, simplify descriptions, and refactor test setups so that each test only runs the bare minimum that it needs.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | | |
| | | |
| | | | |
For consistency with other specs.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
They not all need to create & install a Gemfile, so let's do only what's
needed. Also the spec descriptions are simpler when no so deeply nested.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7038: Strip unknown regexp option line from error format r=hsbt a=k0kubun
### What was the end-user problem that led to this PR?
On Gemfile syntax error like `gem 'foo', :path => /unquoted/string/syntax/error`, Ruby 2.7 will show strange error message like:
```
[!] There was an error parsing `Gemfile`: unknown regexp options - trg - ...foo', :path => /unquoted/string/syntax/error
... ^~~~~~~. Bundler cannot continue.
```
due to recent change in Ruby trunk https://github.com/ruby/ruby/commit/b6468b01f7288789ef2e9bf548d81cdadb8ef053. This caused Bundler's [CI failure on ruby/ruby repository](https://dev.azure.com/rubylang/ruby/_build/results?buildId=180&view=logs&jobId=b6208202-37e9-506d-3aed-7f8fc7b76c87&taskId=a8620f99-3e9e-5782-41a8-f55e2d53059e&lineStart=94&lineEnd=95&colStart=1&colEnd=1).
Bundler's Travis ruby-head has not failed yet because Travis ruby-head is still a little old. It will fail later and this is fixing the future failure.
### What was your diagnosis of the problem?
SyntaxError's message was changed to have an additional message indicating a position of an unknown regexp option like:
```
foo /bar/baz
^~~
```
or
```
...oooooooooooooooooooooo /bar/baz
... ^~~
```
### What is your fix for the problem, implemented in this PR?
My fix tries to strip the new message part because the error line is already shown in another part of `DSLError#to_s`.
### Why did you choose this fix out of the possible options?
To keep the best compatibility with older Bundler versions.
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
|
| | | | | |
|
|\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7106: Cache rubocop in travis-ci r=deivid-rodriguez a=colby-swandale
### What was the end-user problem that led to this PR?
We run rubocop on every build that goes through every file looking for any breaking rules. Currently this takes about ~30s to execute. We also have the linting step required to pass before any other steps are executed, so having this step execute as fast as possible is important to developers.
I think there is a small optimize we can make to the build time by caching rubocop between builds.
### What is your fix for the problem, implemented in this PR?
Have travis cache the results from rubocop between builds to speed up build times
Co-authored-by: Colby Swandale <me@colby.fyi>
|
| | | | | |
|
|\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7093: Merge lockfile spec files r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was current lockfile specs are hard to maintain.
### What was your diagnosis of the problem?
My diagnosis was that we were maintaining separate files per version for the lockfile specs. I imagine we did this because at some point the lockfiles were too different to make it worth maintaining a single file with some filters on the bundler version. I don't think this is the case anymore.
### What is your fix for the problem, implemented in this PR?
My fix is to merge both files.
### Why did you choose this fix out of the possible options?
I chose this fix because I think it simplifies maintenance and it gives a quick view of the differences in the lock file format across versions in a single place.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |_|/
| |/| | |
|