| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7072: Review `bundle show` deprecation r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was there was some work to do regarding the deprecation of `bundle show` and the `bundle list` introduction.
### What was your diagnosis of the problem?
* The command should error out in bundler 3 and was still there.
* The command would print erroneous deprecation messages for the `--verbose` and `--outdated` flags. These flags to `bundle show` are undocumented and will be removed in bundler 3.
* The `bundle list` help would show the help for the new `list` command that lists groups of (or all) gems in the Gemfile, but its implementation would just be an alias to `bundle show`.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the command in bundler 3, to show a different deprecation message when `--outdated` or `--verbose` are used to inform about their removal without replacement, and the inconditionally introduce the new list command without any feature flag.
### Why did you choose this fix out of the possible options?
I chose this fix because:
* The `--outdated` and `--verbse` options are undocumented, so nobody should be using them. Still, I give a correct deprecation message for any users they might have used them.
* The `list` command was super confusing because it was an alias to `show` but that was not documented anywhere. So, I consider find to introduce the new `bundle list` now to match the documentation.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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`.
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7102: Remove explicitly loading thread library r=hsbt a=hsbt
### What is your fix for the problem, implemented in this PR?
It's provided by an embedded module in the modern Ruby.
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
|
| |/ /
| |
| |
| | |
in the modern Ruby.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7023: Shellsplit build config r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was #6940. Build configurations with multiple whitepaced parameter are no longer properly handled.
### What was your diagnosis of the problem?
My diagnosis was not mine, was @jeremy's: Since [shellscaping / shelljoining build arguments to the rubygems gem installer](https://github.com/bundler/bundler/issues/6940), these are no longer properly passed
### What is your fix for the problem, implemented in this PR?
My fix is not mine, it's @jeremy's: shellsplit settings before passing them.
### Why did you choose this fix out of the possible options?
I chose this fix because it works and it sounds like the proper followup to https://github.com/rubygems/rubygems/pull/2441.
Fixes #6940.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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`.
|
