| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7006: Fix sticky options deprecation r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that deprecating sticky options is currently "useless" since we are removing the flags where the stickyness makes a difference at the same time. So, we don't help users adapt to (and understand) our changes.
### What was your diagnosis of the problem?
My diagnosis was that we should do this change in two steps, so that first users get a explanation about why we are removing the flags and what is the preferred alternative for them, and once nobody is no longer using these flags, we deprecate sticky options in general, since they are surprising and no longer useful, since we don't depend on them.
### What is your fix for the problem, implemented in this PR?
My fix is to:
* In bundler 2 (next release, 2.1 for example), print a deprecation message to warn about the removal of all the flags that currently depend on the options being remembered.
* In bundler 3, remove the options and deprecate remembering command line flags.
### Why did you choose this fix out of the possible options?
I chose this fix because it properly and gradually informs our users about the changes that we intend to make and why we intend to make them.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Under the previous code, once we stop remembering options, these flags
would be automatically removed without deprecation. Instead, first
deprecate the options in bundler 2, then remove them and stop
remembering them in bundler 3.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
The deprecations will lead to some "true positives" where users will
use `bundle config` and remove the flag, and some "false positives"
where users will be fine with the option not being remembered but still
want to use the flag on a per command basis.
Whatever the case, we need to tell users how to get rid of the warning
once they learn and get ready for the new behavior. Otherwise it's going
to get super annoying!
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7000: Git based sources and custom sources deprecation r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that our plan for deprecating using `git` instead of `https` for custom sources under the hood, and to deprecating those custom sources itself was unclear.
### What was your diagnosis of the problem?
My diagnosis was that we should give contradictory/confusing deprecation warnings to users, so we should do this is several steps.
### What is your fix for the problem, implemented in this PR?
My fix is to implement the following plan:
* In bundler 2 (next release, 2.1 for example), start using https by default for the custom sources (`:github`, `:gist`, `:bitbucket`), and deprecate setting the `github.https` setting to false.
* In bundler 3, make the setting `github.https` a noop, using `https` nevertheless, and go ahead and deprecate the sources.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the friendlier path I could think of for our users.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| |
| | |
Bundler 3.0 was incorrect according to the new plan of migrating to
https sources first, and then removing custom sources.
|
| | | |
|
| | |
| |
| |
| |
| | |
For now, warn only users that are opting out that the setting will be
removed in the future.
|
| | |
| |
| |
| | |
And thus its removal even further.
|
| | |
| |
| |
| | |
To make sure all cases are covered.
|
| | |
| |
| |
| | |
This allows us to get most of the DSL related deprecation specs passing.
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
Classic problem: comments do not get as curated as code, so they no
longer make sense. I prefer to remove them and try to keep the code
self-explaining and in good shape instead.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6999: Fix multiple gem files deprecation r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was the current message about deprecating `Gemfile` in favor of `gems.rb` was incorrect, and this I'm not sure when it was supposed to be displayed. Its corresponding test was also failing.
### What was your diagnosis of the problem?
My diagnosis was that the intention was not to deprecate Gemfile's for the time being, but only warn if the user opts in to `gems.rb` but does not remove the old `Gemfile`.
### What is your fix for the problem, implemented in this PR?
My fix is to properly detect the situation where both `Gemfile` and `gems.rb` files are present, and show proper messages guiding the user to properly make the switch.
### Why did you choose this fix out of the possible options?
I chose this fix because I think it works and doesn't take this migration too far, since the ecosystem is not yet ready for this at all.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous logic is unclear to me. It seemed to try to detect only
"multiple gemfile situations", but it was doing it incorrectly, I think.
The new message is printed _only_ if both gems.rb and Gemfile are
detected in the same project. And recommends sticking with gems.rb. But
we are not yet deprecating "Gemfile" other than that.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6985: Remove git subshelling from gemspec r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The initial problem was that the default bundler gemspec integrated in ruby-core was shipped nearly empty: https://bugs.ruby-lang.org/issues/15582. That caused issues in bundler: https://github.com/bundler/bundler/issues/6937
### What was your diagnosis of the problem?
I looked into ruby-core history, and still not fully sure how it happened but something I noticed is that bundler does not make this integration easy because ruby-core doesn't have a git environment available, so it needs to do a bit of juggling: https://github.com/ruby/ruby/blob/trunk/tool/rbinstall.rb#L802-L803. We could make things easier.
### What is your fix for the problem, implemented in this PR?
My fix is to stop subshelling to `git` from our own gemspec. I think we do this in the default generated gemspec so that newbie users don't accidentally ship generated files with their gems (although the current solution would still ship generated files that newbie users accidentally commit to source control :smile:). But we shouldn't consider ourselves newbies, so I think we can avoid that.
### Why did you choose this fix out of the possible options?
I chose this fix because it avoids shelling out to git inside the gemspec while still keeping some assurances about the correctness of the shipped set of files through a quality spec.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7009: Rubocop disabled by default r=colby-swandale a=deivid-rodriguez
Closes #7003.
### What was the end-user problem that led to this PR?
The problem was that the current rubocop config gets in the middle too much for my taste.
### What was your diagnosis of the problem?
My diagnosis was that we should enable one cop at a time instead of maintaining a hard too maintain, easily falling out of date `.rubocop_todo.yml` config.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the TODO file, and only keep enabled the cops that current have 0 offenses. We can progressively globally enable more cops as we see fit in the future.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows us to enforce _full_ consistency for specific rules, without getting in the middle at all otherwise.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
We keep the same set of rules that were previously enabled, but make
sure that we don't need to maintain a TODO file with exceptions, and
that upgrading rubocop doesn't silently include new rules without us
explicitly opting in.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7025: Bump rubygems in CI r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was not testing against the latest and greatest rubygems.
### What was your diagnosis of the problem?
My diagnosis was rubygems is outdated since the latest security releases.
### What is your fix for the problem, implemented in this PR?
My fix is to update the tested rubygems.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the only fix.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7024: Remove old 1.8.7 remanents r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we have some really legacy code in our specs.
### What was your diagnosis of the problem?
My diagnosis was that we forgot to remove/update these bits when dropping support.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the legacy code.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the only fix, really.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6728: Fallback to sequentially fetching specs on 429s r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem is that sometimes `bundler` is unable to resolve certain gemfiles. Specifically, sometimes it does not respect the `required_ruby_version` setting. This causes some people to assume that `bundler` will always try to install the latest version of any dependency, regardless of the ruby version being run, because as a matter of fact, this feature sometimes just doesn't work. See for example the discussion at https://github.com/rspec/rspec/issues/25.
The problem was consistently reproducible until a few minutes ago with the following `Gemfile` under `ruby 2.3.7`
```ruby
source "https://rubygems.org"
ruby "2.3.7"
gem "berkshelf", "= 6.3.1"
```
```
$ docker run -it --rm --volume $(pwd):/app ruby:2.3.7 sh -c "cd /app && rm -f Gemfile.lock && bundle install"
Fetching gem metadata from https://rubygems.org/.............
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies....
Fetching public_suffix 3.0.3
Installing public_suffix 3.0.3
Fetching addressable 2.5.2
Installing addressable 2.5.2
Fetching buff-extensions 2.0.0
Installing buff-extensions 2.0.0
Fetching hashie 3.6.0
Installing hashie 3.6.0
Fetching varia_model 0.6.0
Installing varia_model 0.6.0
Fetching buff-config 2.0.0
Installing buff-config 2.0.0
Using bundler 1.16.5
Fetching fuzzyurl 0.9.0
Installing fuzzyurl 0.9.0
Fetching tomlrb 1.2.7
Installing tomlrb 1.2.7
Fetching mixlib-config 2.2.13
Installing mixlib-config 2.2.13
Fetching mixlib-shellout 2.4.0
Installing mixlib-shellout 2.4.0
Fetching chef-config 14.5.33
Installing chef-config 14.5.33
Fetching libyajl2 1.2.0
Installing libyajl2 1.2.0 with native extensions
Fetching ffi-yajl 2.3.1
Installing ffi-yajl 2.3.1 with native extensions
Fetching mixlib-log 2.0.4
Installing mixlib-log 2.0.4
Fetching rack 2.0.5
Installing rack 2.0.5
Fetching uuidtools 2.1.5
Installing uuidtools 2.1.5
Fetching chef-zero 14.0.6
Installing chef-zero 14.0.6
Gem::RuntimeRequirementNotMetError: chef-zero requires Ruby version >= 2.4.0. The current ruby version is 2.3.0.
An error occurred while installing chef-zero (14.0.6), and Bundler cannot continue.
Make sure that `gem install chef-zero -v '14.0.6' --source 'https://rubygems.org/'` succeeds before bundling.
In Gemfile:
berkshelf was resolved to 6.3.1, which depends on
chef was resolved to 14.5.33, which depends on
chef-zero
```
Funny enough, I can no longer reproduce it at the moment, I guess it depends on the specific load conditions of the rubygems.org servers?
### What was your diagnosis of the problem?
My diagnosis was that sometimes our resolution falls back to the old dependency API that didn't implement the `required_ruby_version` setting. In particular, this happens because the new API returns `Net::HTTPTooManyRequests`, so `bundler` gives up and defaults to the old API.
### What is your fix for the problem, implemented in this PR?
My fix is to, instead of directly fall back to the old API when rate limiting happens, try first to fetch the dependencies sequentially instead of in parallel still from the new API, so that rate limit does not affect us.
### Why did you choose this fix out of the possible options?
I chose this fix because it was the only idea that came up. As a matter of fact, #6471 and #6639 were closed because there was nothing we could do, so it seems like it's the only idea so far :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
If the compact index returns TooManyRequests, take it easier by
requesting dependencies sequentially instead.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7020: Fix typo r=colby-swandale a=andrew
Co-authored-by: Andrew Nesbitt <andrewnez@gmail.com>
|
| |/ / / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6994: skip colorize examples when the environment was mswin or non tty. r=hsbt a=hsbt
### What was the end-user problem that led to this PR?
Fixes https://github.com/bundler/bundler/issues/6900
### What was your diagnosis of the problem?
The current bundler examples were not supported on mswin and non-tty environments.
### What is your fix for the problem, implemented in this PR?
I make to skip them when Thor detected unsupported environment.
### Why did you choose this fix out of the possible options?
Thor is vendoered now. It's easy to fix bundler's example directly.
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7016: Fix offenses for more cops r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that a few cops with exceptions in the TODO file have been bothering me recently when moving files around.
### What was your diagnosis of the problem?
My diagnosis was that we can just fix these offenses once and for all, or alternatively disable them inline, or moving them to the permanent config.
### What is your fix for the problem, implemented in this PR?
My fix is to:
* Auto-correct a few simple cops.
* Permanently disable `Style/GuardClause`, because I don't think it always leads to better code, and sometimes it forces artificial refactorings when making changes to methods, making the intention of the changes more obscure.
* Move `rescue Exception` disabling inline, so that when moving that code around, rubocop doesn't complain.
### Why did you choose this fix out of the possible options?
I chose this fix because this is my opinionated approach to this. :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Sometimes rubocop misunderstand semantics, and forces you to write code
that feels worse. I prefer to disable it.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7012: Adapt helper path regex to also work with Windows paths r=deivid-rodriguez a=janpio
### What was the end-user problem that led to this PR?
Some tests were failing on Windows with strange paths not existing.
### What was your diagnosis of the problem?
Turns out a regex in the helper for paths didn't fire on Windows paths as they start with something like `C:/`.
### What is your fix for the problem, implemented in this PR?
So I adapted the regex to also match Windows paths.
### Why did you choose this fix out of the possible options?
... which seemed like the right thing to do here.
---
Fixes 21 test failures on Windows.
closes #6892
Co-authored-by: Jan Piotrowski <piotrowski+git@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | | |
Co-Authored-By: janpio <piotrowski+github@gmail.com>
|
| | | | | |
|
