| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This deprecation will be a false positive in almost every case, so it
will be very annoying for users. I realized about this when being bitten
by the warning on our own specs on perfectly fine `bundle install` runs
(`bundle install --retry 3`).
Since we already have the deprecation in place about the options being
removed from `bundle install` and being turned into configuration
options, I think we can skip this warning altogether since the remaining
flags are very unlikely to cause any problems when they start being
"forgotten".
|
| | |/
| |
| |
| | |
Because the behavior is still there.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7040: Remove `RUBY_VERSION` leftovers r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that find old ruby compatibility code can confuse contributors into thinking those versions are still supported.
### What was your diagnosis of the problem?
My diagnosis was that we can remove this code, since we no longer support those versions.
### 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 :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7037: Test `bundle viz` command deprecation r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we were not printing any deprecation messages for `bundle viz`.
### What was your diagnosis of the problem?
My diagnosis was that we are removing `bundle viz` at the same time as deprecating it. Thus, the deprecations never actually show up.
### What is your fix for the problem, implemented in this PR?
My fix is to first deprecate the command on bundler 2, then remove it in bundler 3.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the most sensible approach to this removal.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7030: Remove `LessThanProc` r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the `LessThanProc` class we use for filtering specs is confusing, in my opinion. For example, if I tag a spec with `:bundler => "2"`, I would expect it to run only against bundler 2. However, that's not how it works, it instead runs against any bundler higher than or equal to 2.
### What was your diagnosis of the problem?
My diagnosis was that the `LessThanProc` class could be much simpler, and just check that the passed requirement matches the version the class was created with.
### What is your fix for the problem, implemented in this PR?
My fix is to simplify the `LessThanProc` class to only do requirement matching, and remove the "less than" functionality.
### Why did you choose this fix out of the possible options?
I chose this fix because in my opinion it's simpler to understand and less surprising.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7029: Make deprecation specs less messy r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that deprecation specs, even though they are now passing, are very brittle. This is because most of them create multiple gem files (`gems.rb` and `Gemfile`), and thus display deprecation messages by default about that.
### What was your diagnosis of the problem?
My diagnosis was that each deprecation should test its own message, instead of having the same deprecation printed by most specs.
### What is your fix for the problem, implemented in this PR?
My fix is to make the specs create a single gem file, except for the ones that test the deprecation about multiple gem files.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes the tests less brittle and do less unnecessary things.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
