| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The list command was still present (just aliased to `bundle show`), even
if the setting was set to false. So the setting was at least super
confusing if not just wrong.
It also led to misleading situations such as
```
$ bundle list --help
(...)
NAME
bundle-list - List all the gems in the bundle
SYNOPSIS
bundle list [--name-only] [--paths] [--without-group=GROUP] [--only-group=GROUP]
(...)
$ bundle list --only-group=development
Unknown switches '--only-group=development'
```
So, instead, I enable the new list command _always_ and remove the
`bundle list => bundle show` alias.
|
| |
|
|
|
| |
Inform about complete removal when `bundle show --outdated` and `bundle
show --verbose`.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7084: Remove command removal settings r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the `viz_command` and `console_command` settings are not meant to be something configured by users. These commands are going away, we don't want to support optionally keeping them.
### What was your diagnosis of the problem?
My diagnosis was that we are using settings for two different things:
* Different supported behaviors that are configurable by users.
* Feature flags that allow us developers to easily maintain a single branch of code and making breaking changes more easily, and users to opt-in/out of certain new features/changes.
The second case is valid but it's complicated because we need to commit to provide a proper life cycle for the setting:
* Allow opting in through the setting.
* Toggle the setting's default value.
* Deprecate the value for the setting enabling the old behavior.
* Deprecate the setting altogether making it a no-op.
* Finally removing the setting.
I plan to work on that, but I didn't start yet.
Instead, what we've been doing to workaround this is to try to not expose these settings to users by, for example, not documenting them.
However, in my opinion, in this particular case it's best to instead not provide a setting at all, and check for the bundler version directly for whether we should be providing the command. The only extra benefit of providing a feature flag, namely, allowing opting in early to the new behavior, is not necessary here because users can "opt in" anyways by simply not using the deprecated commands.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the settings and check for `Bundler.feature_flag.bundler_3_mode?` instead.
### Why did you choose this fix out of the possible options?
I chose this fix because it's simple and it makes it clear that keeping these commands and not something we want to support. They are going away for good.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This setting is not meant to be used by end users. The `console` command
is going away and we plan to fully remove the code once we only have to
maintain bundler 3 or higher versions. Adding a setting makes it look
like the presence of this command is something "configurable", but it's
not.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This setting is not meant to be used by end users. The `viz` command is
going away and we plan to fully remove the code once we only have to
maintain bundler 3 or higher versions. Adding a setting makes it look
like the presence of this command is something "configurable", but it's
not.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7088: Bump version to 2.1.0.beta1. r=colby-swandale a=hsbt
### What was the end-user problem that led to this PR?
When we released the new version, We got the test failure or an error with a version number like 2.0.0.
### What was your diagnosis of the problem?
We didn't test with new version number until release time.
### What is your fix for the problem, implemented in this PR?
I did bump to the minor version in the master branch.
### Why did you choose this fix out of the possible options?
We should develop with a new version number like 2.1.0.
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7091: Change info command spec to use `bundle info` instead of `bundle show` r=colby-swandale a=colby-swandale
### What was the end-user problem that led to this PR?
A test in the info command spec was using `bundle show` instead of `bundle info`.
This is causing specs in Bundler 3 to fail. See https://travis-ci.org/bundler/bundler/jobs/514507744
### What is your fix for the problem, implemented in this PR?
Change the test to use `bundle info` instead.
Co-authored-by: Colby Swandale <me@colby.fyi>
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7089: Normalize file URIs in spec's lockfiles r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that bumping bundler's version in #7088 made a lockfile spec fail.
### What was your diagnosis of the problem?
My diagnosis was that there was a combination of bugs that was making this spec pass, but the spec was incorrect.
### What is your fix for the problem, implemented in this PR?
My fix is to change the test version the spec uses to not hit https://github.com/rubygems/rubygems/issues/2595, and thus reproduce the failure. And then fix the spec that was incorrect because the lockfile written had different URLs (`file://localhost/<stuff>`) from the lockfile we were checking against (`file://<stuff>`), thus tricking `bundle install` into thinking something had changed, and thus making it rewrite it with an incorrect bundler version.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes #7088 pass and it reduces surprises.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change is simple but not easy to explain. What this test does is to
ensure that if bundle install doesn't change anything, then the bundler
version in the lockfile does not get rewritten.
Whereas this test was passing, the implementation was wrong, but two
bugs were "compesating for each other" and making it pass. The
explanation is the following:
Due to a regression in rubygems, in rubygems 3+ "2.0.0.0.a" is
considered higher than "2.0.0.dev". This changes the test because
bundler will never dowgrade the bundler version in a lockfile, so even
if the lockfile gets rewritten, it will still keep "2.0.0.0.a", since
it's considered higher.
However, if we change the test to use "2.0.0.a" instead of "2.0.0.dev",
then the test starts failing and shows the bug in the test.
The bug is that the lock file in the test is written with
"file://localhost" style URLs. However, the lockfile that would be
generated would contain "file://" style URLs. This would trick bundler
into thinking that something has been changed by `bundle install`, so it
will rewrite the lock file, use "2.0.0.dev" as the locked bundler
version, and cause the test to fail.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Get `have_lockfile` helper method actually used.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7007: Remove lockfile incompatibility created by the `lockfile_uses_separate_rubygems_sources` setting r=deivid-rodriguez a=deivid-rodriguez
This is more of a question PR, I created this patch to try it out and try to understand, not necessarily get it merged.
### What was the end-user problem that led to this PR?
The problem was that once we enable the `lockfile_uses_separate_rubygems_sources` setting, all lockfiles in the world will become incompatible with the previous version. Actually, not necessarily incompatible, but bundler will reorder the sections when the setting is enabled, that will generate churn lock file diffs, and _maybe_ some confusion / merge conflicts, and so on.
### What was your diagnosis of the problem?
My diagnosis was that maybe this is not necessary. I read over the issues where this setting was added and what I understood is that previously if a Gemfile specified multiple rubygems sources, they would all get merged together and that's dangerous because it's not deterministic from which source each gem will be picked up, and that could be maliciously exploited. So now each source gets its own separate section. However, how does that affect the ordering of the sections? I don't think it should affect it?
### What is your fix for the problem, implemented in this PR?
My fix is to change the `lock_sources` method so that both code branches (`lockfile_uses_separate_rubygems_sources == true`, and `lockfile_uses_separate_rubygems_sources == false`) result in the same ordering of the source sections.
### Why did you choose this fix out of the possible options?
I chose this fix because I _think_ it keeps the setting doing the same thing, but also keeps lock file compatibility.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `lockfile_uses_separate_rubygems_sources` was causing a lockfile
incompatibility but in my opinion, this incompatibility is not necessary
in the general case.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7090: Make sure spec fails if gems cannot be installed r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was if the installation if system gems failed during specs failed, that was being silently ignored.
### What was your diagnosis of the problem?
My diagnosis was that if this installation fails, the specs that use this helper are not probably testing what they should
### What is your fix for the problem, implemented in this PR?
My fix is to use the bang method instead.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `realworld_system_gems` helper was failing to install these gems
under rubygems master, and because of that, the related spec was
actually passing, without actually checking for the regression it was
meant to check.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7080: Always pass the `--all` flag when needed r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs were still using `bundle update` to update all gems, which is deprecated.
### What is your fix for the problem, implemented in this PR?
My fix is to update all specs to use the new preferred command, namely, `bundle update --all`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7082: Complete some missing specs r=deivid-rodriguez a=deivid-rodriguez
This is a follow up to #7052.
### What was the end-user problem that led to this PR?
The problem was that the `Bundle.with_clean_env` & `Bundle.with_original_env` family was missing some deprecation specs, and also the specs were spread out across different files.
### What is your fix for the problem, implemented in this PR?
My fix is to add the missing specs, and centralize them in the deprecation specs file.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | |
|
| | |/ / / |
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6963: Allow to `bundle exec` default gems r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that since `irb` and others were moved to default gems, users cannot directly use them in a bundler context, unless they add it to their gemfiles. In my opinion, this completely defeats the purpose of default gems, and makes bundler degrade the user experience instead of making it better.
### What was your diagnosis of the problem?
My diagnosis was that when bundler replaces the set of gems known to rubygems, it restricts the world to what's in the Gemfile (or resolved from it), and that doesn't include default gems.
### What is your fix for the problem, implemented in this PR?
My fix is to also include the set of default gems, unless they are already included in the gemfile dependencies.
### Why did you choose this fix out of the possible options?
I chose this fix because it's reasonably simple and I think it shouldn't affect how other parts of bundler function.
Fixes #6929.
Fixes https://bugs.ruby-lang.org/issues/15503.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Even when they are not explicitly specified in the Gemfile.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7026: Add missing `bundle info` feature, bug fix, and specs r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundler info GEM` did not have feature parity with `bundle show GEM`, and it should because it's the recommended alternative. Also, `bundle info bundler` was showing an incorrect path while `bundle show bundler` was correct.
### What was your diagnosis of the problem?
My diagnosis was that some code should be pulled from `bundle show`.
### What is your fix for the problem, implemented in this PR?
My fix is to port the missing feature, bug fix, and specs to `bundle info` from `bundle show`.
### Why did you choose this fix out of the possible options?
I chose this fix because it guarantees that the recommended alternative will work similarly to the current show command.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | | |
Just exit.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The raise is using the name of the class on its message!
```
Could not find gem 'Bundler::CLI::Common'.
```
Since we've never received a WTF report about this, I'll assume this is
just dead code and remove it.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Just like `bundle show rails` did.
|
| | | | |
| | | |
| | | |
| | | | |
Skip for now the functionality not currently supported in `bundle info`.
|
| | | | |
| | | |
| | | |
| | | | |
To be just like how current `bundle show` is tested.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This case `bundle info rails` is already tested at the beginning of the
file. Plus, the description is misleading since no `--path` option is
given here.
|
| | | | |
| | | |
| | | |
| | | | |
For consistency with `bundle show` specs.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7079: Remove `bundle config` deprecations from specs r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs still use the deprecated `bundle config interface`
### What is your fix for the problem, implemented in this PR?
My fix is to use the newer interface.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7070: Improve cross repo integration r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we had on `rubygems`, we're not testing bundler against the rubygems checkout of each PR, but against master. That is confusing because developers assume that the PRs tests will run against the PRs code, but this is currently not true.
### What was your diagnosis of the problem?
My diagnosis was that on rubygems we are [specifying `RGV=master`](https://github.com/rubygems/rubygems/blob/fa6e547330e97b417ed11f262d68d03c57abeeda/.travis.yml#L12) in our TravisCI matrix. And what `bundler` does with that is to clone rubygems master under `tmp/rubygems` and use that. Thus your rubygems PR is not really tested.
### What is your fix for the problem, implemented in this PR?
My fix is to rework the setup to accept an `RGV` environment variable when it contains. In that case, no git operations will be performed, and that path will be used directly and assumed to contain a rubygems checkout.
I also refactored a few things about the setup while at it.
### Why did you choose this fix out of the possible options?
There were existing tasks to test bundler against a rubygems checkout, but they were unused and they expected a `RG` environment variable instead. I decided to reuse these tasks, but make them pick up the `RGV` as long as it contains a valid path. I chose this fix because it works and it doesn't make the existing setup too different.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I don't plan to support running this binstub from outside of the root
folder.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Since it's meant for CI.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Delegate everything to `bin/with_rubygems` instead.
|
