| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Even when they are not explicitly specified in the Gemfile.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| | |
To avoid activation of the `etc` gem.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
MRI 2.5.4 now regressed and suffers from the same issue as 2.6.2 :S
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7059: Make `bundle clean` clean git extension directories r=hsbt a=dylanahsmith
Fixes #7058
This PR fixes it by adding the native extension directories for git gems to the ones for non-git gems. This is used to get the unused extension directories (`stale_extension_dirs = extension_dirs - spec_extension_paths`) which was already excluding extension directories for git gems.
Co-authored-by: Dylan Thacker-Smith <dylan.smith@shopify.com>
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7052: Introduce `original_system`, `original_exec`, `unbundled_system`, and `unbundled_exec` r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the `clean_system` and `clean_exec` would print deprecation messages, but there was not alternative for them.
### What was your diagnosis of the problem?
My diagnosis was that the helpers are using deprecated behavior and that we should provide non deprecated alternatives.
### What is your fix for the problem, implemented in this PR?
My fix is to introduce `original_system`, `original_exec`, `unbundled_system`, and `unbundled_exec` for consistency with the rest of the helpers, and deprecate `clean_system` and `clean_exec`.
### Why did you choose this fix out of the possible options?
I chose this fix because while maybe not super pretty names, they offer an alternative consistent with the other helpers.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | |
| | | |
Because the previous helpers, `clean_exec` and `clean_system`, use
deprecated behavior and thus should be deprecated too.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7067: Tweaking vendoring r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we were not using the latest versions of some of our vendored dependencies.
### What was your diagnosis of the problem?
My diagnosis was that we should upgrade them.
### What is your fix for the problem, implemented in this PR?
My fix is to upgrade them using `automatiek`, and add a few tweaks to our vendoring setup.
### Why did you choose this fix out of the possible options?
I chose this fix because.... I didn't really considered other options.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Make it consistent with how we do it for `ronn`, and give better
messages for installing `automatiek` if missing.
|
|/ / / |
|
|\ \ \
| |_|/
|/| | |
Fix circular require warnings
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7055: Revert the RSpec format in CI back to dots r=colby-swandale a=colby-swandale
### What was the end-user problem that led to this PR?
#7017 introduced made a change that sets the RSpec format to `documentation` in CI. I'm against this change because it now takes _a lot_ more time to scroll to the build errors, and makes the build log have too much information. Maintainers care much more about the failing specs and their errors than the test descriptions in CI.
### What is your fix for the problem, implemented in this PR?
Explicitly set the RSpec format to `progress` in CI.
Co-authored-by: Colby Swandale <me@colby.fyi>
|
|/ / |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7017: Development environment cleanup r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was making changes in the development setup was brittle and led to hard to debug errors. For example, the ones in #6980. Also, it was hard to reproduce exactly what's going on in the current CI environment. Which is useful to setup other CI, or run the specs under a docker image.
### What was your diagnosis of the problem?
My diagnosis was that we can simplify a lot of this stuff.
### What is your fix for the problem, implemented in this PR?
My fix is... a lot of simplifications, but the most important ones being:
* Now each binstub activates only its own dependency, not every development dependency. That means a contributor can perfectly work on manual pages installing only `rake` and `ronn` without having to install all development dependencies. Same with styling (`rubocop`), or with specs (`rspec`).
* Error messages are better now.
* The rake tasks for each main `Rakefile` section (man / spec / vendor) have been extracted to their own files.
* Rake tasks now shell out to the proper binstub, so gem activation is only needed there.
### Why did you choose this fix out of the possible options?
I chose this fix because it simplifies a lot the development environment in my opinion. Also, specs now pass under a docker image!
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Previously having another gem with a `ronn` executable would silently
work and fail later with a cryptic error. Now we activate the proper
version, and give a proper error if it fails.
|
| |
| |
| |
| | |
No .rb files in there.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Since the RSpec task now uses the RSpec binstub, we can rely on all the
dance done in there.
|
| | |
|
| | |
|
| |
| |
| |
| | |
We shell out to the binstub so we no longer need the activation dance.
|
| | |
|
| | |
|
| |
| |
| |
| | |
We shell out to the binstubs, so we don't need any activation dance.
|
| | |
|
| |
| |
| |
| |
| | |
This is already done from the spec helper right before the beginning of
the test suite.
|
|/
|
|
|
| |
We are inside the RSpec helper file, so RSpec must be already activated
at this point.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7045: Review old `bundle config` interface deprecation r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the `bundle config` command interface changes needed a few tweaks.
### What was your diagnosis of the problem?
My diagnosis was that:
* `bundle config` deprecation was not getting enabled until bundler 3.
* `bundle config` documentation was incorrect about `unset` not supporting `--global` or `--local`.
* `bundle config` deprecation didn't give actionable suggestions.
### What is your fix for the problem, implemented in this PR?
My fix is to move the version to deprecate the old interface to `bundler 2`, to fix the documentation, and to improve the deprecation messages to give actionable suggestions.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes `bundle config` better.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| |
| |
| |
| | |
They are actually compatible.
|
| |
| |
| |
| | |
And add specs for it.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7044: Unskip `--binstubs` flag deprecation r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some deprecation specs were still skipped.
### What was your diagnosis of the problem?
My diagnosis was that I should get all of them passing.
### What is your fix for the problem, implemented in this PR?
My fix is to uncomment the spec and get it passing. The only fix was to include the full deprecation message so that it matches the assertion.
### Why did you choose this fix out of the possible options?
I could've regexp-matched the existing message but I preferred to use the full message in the assertion instead. I chose this fix because although it makes it more brittle since changing the message _will_ break the test, having the whole messages inside the deprecation specs makes it easier to get a quick view and understand the stuff that we are deprecating and the quality of the existing deprecation messages.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7049: Remove mustache dep r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem is that I just can't find where this development dependency is used. Furthermore, I can't find where it was used in the past :S
### What was your diagnosis of the problem?
My diagnosis was that maybe it's never been used?
### What is your fix for the problem, implemented in this PR?
My fix is to remove the dependency.
### Why did you choose this fix out of the possible options?
I chose this fix because the less dependency, the better.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7047: Remove remembered options deprecation message r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that this deprecation message is almost always a false positive. I realized about this when being bitten by this deprecation message during on our own specs (see https://travis-ci.org/bundler/bundler/builds/506776354 for example).
### What was your diagnosis of the problem?
My diagnosis was that people running things like `bundle install --retry 3` will be annoyed by this deprecation message, because they're not doing anything wrong, really. They have the option to set the flag permanently through configuration, but passing it per command is fine too. The fact that the flag will no longer be remembered is unlikely to cause any problems in my opinion.
### What is your fix for the problem, implemented in this PR?
My fix is to remove this message altogether. We already print deprecation messages for the flags that we are removing because they only are guaranteed to work when remembering options (`--with`, `--without`, and friends). For the rest of the flags not being removed from `bundle install`, printing a deprecation message is just annoying since users are not doing anything wrong by using them.
### Why did you choose this fix out of the possible options?
I chose this fix because we shouldn't overwhelm users with deprecation messages unless we really need to.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|