| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
bundler:seg-release-patch-change-version-after-checkout, r=segiddins
[Rakefile] In a patch release, change version after checkout
### What was the end-user problem that led to this PR?
The problem was changes to the versions file on the `master` branch would cause checkout to fail
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=segiddins
[RuboCop] Enable Layout/EmptyLineAfterMagicComment cop
This PR makes cosmetic changes. Layout/EmptyLineAfterMagicComment cop is enabled by default in RuboCop as well.
https://github.com/bbatsov/rubocop/blob/v0.49.1/config/enabled.yml#L203-L206
This PR executed the following command to the source codes.
```console
% rubocop -a --only Layout/EmptyLineAfterMagicComment
```
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Adding process lock for bundle install operations
### What was the end-user problem that led to this PR?
As per #5851 multiple concurrent bundle installs would cause failures when compiling
### What was your diagnosis of the problem?
As described in #5851 a sample project was created demonstrating the issue when running a docker-compose solution of 2 containers using a gem cache volume
### What is your fix for the problem, implemented in this PR?
The fix is to implement an installation process lock so that only one process can execute an install at one time
### Why did you choose this fix out of the possible options?
I chose this fix because it was discussed in #5851 as a possible solution
|
| | |\ \ \
| | | | |
| | | | |
| | | | | |
add-process-lock
|
| | | | | |
| | | | |
| | | | |
| | | | | |
as it seems Ruby 1.8.7 does not unlock on closing of the file
|
| | | | | |
| | | | |
| | | | |
| | | | | |
multiple concurrent bundle install operations fail to complete
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Change deprecation from `bundle list` to `bundle show`
### What was the end-user problem that led to this PR?
I understand that `bundle show` will be removed in Bundler 2.0, not `bundle list`.
https://github.com/bundler/rfcs/pull/6/files#r125875779
In the current message, there is a possibility of misleading the command which will be removed in Bundler 2.0.
### What was your diagnosis of the problem?
I think that it is better to display `bundle show` instead of `bundle list` in the deprecated warning.
### What is your fix for the problem, implemented in this PR?
Change the deprecated warning from `bundle list` to `bundle show`.
### Why did you choose this fix out of the possible options?
I thought that changing the console message was a simple and effective change to the end user.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[2.0] Use deployment instead of frozen as a setting on Bundler 2
### What was the end-user problem that led to this PR?
The problem was bundler had a `--deployment` flag, a `--frozen` flag and a `frozen` setting. All frozen meant was the lockfile couldn't change, whereas `--deployment` meant the full "deployment experience". This was confusing.
Closes https://github.com/bundler/bundler/issues/4619.
### What was your diagnosis of the problem?
My diagnosis was we want to get rid of the `--frozen` setting and add a new `deployment` setting that will be used by default on Bundler 2.
### What is your fix for the problem, implemented in this PR?
My fix adds the deployment setting, and updates the myriad places we use `Bundler.settings[:frozen]` to take it into account, along with fixing the behavior when `bundle config deployment true` is used instead of the command line switches.
|
| | | | | | | |
|
| | | | | | | |
|
| |/ / / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add some unit tests for lockfile parsing
### What was the end-user problem that led to this PR?
The problem was the lockfile parser was missing some robustness unit tests.
### What is your fix for the problem, implemented in this PR?
My fix was to add test coverage!
|
| |/ / / / / |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
[ParallelInstaller] Show require tree when a gem fails to install due to corrupted lockfile
### What was the end-user problem that led to this PR?
The problem was that when installation failed due to a corrupted lockfile or checksum mis-match, we wouldn't show the reason that gem was being installed in the first place, as we would when other errors happened.
See https://github.com/bundler/bundler/issues/5846
### What was your diagnosis of the problem?
My diagnosis was we needed to show that requirement tree whenever installation fails, regardless of the reason for the failure.
### What is your fix for the problem, implemented in this PR?
My fix rescues hard installation errors and re-raises with the tree appended.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
corrupted lockfile
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use https for the opensource.org link in README template, which you'r…
…e redirected to anyway
I'm skipping the questions because this is a one character documentation fix.
|
| | | |/ / /
| |/| | |
| | | | |
| | | | | |
redirected to anyway
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Limit specs to rack-test < 0.7.0 for Ruby 1.8.7 compatibility
### What was the end-user problem that led to this PR?
The problem was the specs were broken by the release of `rack-test 0.7.0`.
### What was your diagnosis of the problem?
My diagnosis was `rack-test` has intentionally dropped 1.8.7 support, though we didn't catch that immediately because they didn't put a `required_ruby_version` in their gemspec.
### What is your fix for the problem, implemented in this PR?
My fix pins us to older versions of the gem.
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Make Bundler.setup not make Kernel#gem public in Bundler 2
### What was the end-user problem that led to this PR?
The problem was Bundler 1 accidentally made `Kernel#gem` public, even though RubyGems declares it as private. Oops. We tried to make it private in 1.13, it broke stuff, so we added in a hack to keep it public.
### What was your diagnosis of the problem?
My diagnosis was we could delete that hack in 2.0.
### What is your fix for the problem, implemented in this PR?
My fix implements a feature flag that skips making `Kernel#gem` public, and adds regression tests for `gem` or `require` accidentally being made public.
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Avoid Range Not Satisfiable errors during normal request flow
### What was the end-user problem that led to this PR?
Previously, Bundler was requesting partial response ranges for the Rubygems compact index that could be empty. Since Rubygems was [ignoring the `ETag` header](https://github.com/rubygems/rubygems.org/pull/1652) for these requests, empty ranges would occur whenever the versions index (for instance) hadn't been modified since the version Bundler currently had cached. When this happened, Rubygems would respond with a 416 (Range Not Satisfiable). Bundler would treat this as a `Bundler::HTTPError`, and fall back to using `Fetcher::Dependency` for dependency info. Sadly, that meant metadata about what Ruby version each dependency required was no-longer checked, and updates for gems which should be limited by the system Ruby version were failing.
Closes #5373.
### What was your diagnosis of the problem?
See above
### What is your fix for the problem, implemented in this PR?
This PR updates the range Bundler requests from Rubygems to ensure it's always satisfiable. It does that but requesting all bytes from (and including) the final byte in the Bundler cache, rather than all bytes after (and not including) it.
### Why did you choose this fix out of the possible options?
An alternative fix would be to catch the 416 responses and retry the index lookup in those cases, asking for a full response. That would mean an extra request in all of those cases, though - this method keeps the number of calls to Rubygems down.
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Improve logging in default gem activation specs
### What was the end-user problem that led to this PR?
The problem was those specs were failing on CI and I couldn't figure out why.
### What was your diagnosis of the problem?
My diagnosis was we needed the hack loaded before all bundler code.
### What is your fix for the problem, implemented in this PR?
My fix gets the hack loaded in via an `-r` switch set in `RUBYOPT`
### Why did you choose this fix out of the possible options?
I chose this fix because it will make spec failures more informative.
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[Inline] Work when BUNDLE_BIN is set
### What was the end-user problem that led to this PR?
The problem was that `bundler/inline` would fail when `$BUNDLE_BIN` was set.
Closes #5847.
### What was your diagnosis of the problem?
My diagnosis was we needed to skip installing binstubs when doing an inline install.
### What is your fix for the problem, implemented in this PR?
My fix sets a temporary setting for `:inline` and skips installing binstubs when that's true.
### Why did you choose this fix out of the possible options?
I chose this fix because it was minimally intrusive.
|
| |/ / / / / |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
r=segiddins
Tweak gemspec template when using Ruby 2.x
### What was the end-user problem that led to this PR?
There are unnecessary magic comment for currently maintained Ruby 2.2, 2.3, and 2.4.
### What was your diagnosis of the problem?
The default script encoding from Ruby 2.0 is UTF-8.
https://bugs.ruby-lang.org/issues/6679
Ruby 1.9 is EOL, so I think that there is not much Gem to start developed using it.
### What is your fix for the problem, implemented in this PR?
This PR removes magic comment when starting Gem development (i.e. `bundle gem`) with Ruby 2.0 or higher version.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
r=segiddins
Capitalize the description lines in Bundler 2
This PR is a small patch.
### What was the end-user problem that led to this PR?
I made the following changes locally to the code of the master branch and tried Bundler 2.0.
```diff
% git diff
diff --git a/lib/bundler/version.rb b/lib/bundler/version.rb
index dad4a88a2..386782023 100644
--- a/lib/bundler/version.rb
+++ b/lib/bundler/version.rb
@@ -7,7 +7,7 @@ module Bundler
# We're doing this because we might write tests that deal
# with other versions of bundler and we are unsure how to
# handle this better.
- VERSION = "1.15.1" unless defined?(::Bundler::VERSION)
+ VERSION = "2.0.0.dev" unless defined?(::Bundler::VERSION)
def self.overwrite_loaded_gem_version
begin
```
Here is the result of running the `bundle` command.
```console
% bundle
Bundler version 2.0.0.dev
Commands:
bundle add GEM VERSION # Add gem to Gemfile and run bundle install
bundle binstubs GEM [OPTIONS] # Install the binstubs of the listed gem
bundle cache [OPTIONS] # Locks and then caches all of the gems into vendor/cache
bundle check [OPTIONS] # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems
bundle clean [OPTIONS] # Cleans up unused gems in your bundler directory
bundle config NAME [VALUE] # retrieve or set a configuration value
bundle doctor [OPTIONS] # Checks the bundle for common problems
bundle env # Print information about the environment Bundler is running under
bundle exec [OPTIONS] # Run the command in context of the bundle
bundle gem GEM [OPTIONS] # Creates a skeleton for creating a rubygem
bundle help [COMMAND] # Describe available commands or one specific command
bundle help [COMMAND] # Describe subcommands or one specific subcommand
bundle info GEM [OPTIONS] # Show information for the given gem
bundle init [OPTIONS] # Generates a Gemfile into the current working directory
bundle inject GEM VERSION # Add the named gem, with version requirements, to the resolved Gemfile
bundle install PLUGINS # Install the plugin from the source
bundle install [OPTIONS] # Install the current environment to the system
bundle issue # Learn how to report an issue in Bundler
bundle licenses # Prints the license of all gems in the bundle
bundle lock # Creates a lockfile without installing
bundle open GEM # Opens the source directory of the given bundled gem
bundle outdated GEM [OPTIONS] # list installed gems with newer versions available
bundle platform [OPTIONS] # Displays platform compatibility information
bundle plugin SUBCOMMAND ...ARGS # manage the bundler plugins
bundle pristine [GEMS...] # Restores installed gems to pristine condition from files located in the gem cache. Gem installed from a git reposito...
bundle show GEM [OPTIONS] # Shows all gems that are part of the bundle, or the path to a given gem
bundle update [OPTIONS] # update the current environment
bundle version # Prints the bundler's version information
bundle viz [OPTIONS] # Generates a visual dependency graph
Options:
[--no-color] # Disable colorization in output
-r, [--retry=NUM] # Specify the number of times you wish to attempt network commands
-V, [--verbose], [--no-verbose] # Enable verbose output mode
```
The beginning of the description lines are not unified with capitalized.
### What was your diagnosis of the problem?
It is the same as above.
### What is your fix for the problem, implemented in this PR?
Unify the beginning of the description lines with capitalized.
```console
% bundle
Bundler version 2.0.0.dev
Commands:
bundle add GEM VERSION # Add gem to Gemfile and run bundle install
bundle binstubs GEM [OPTIONS] # Install the binstubs of the listed gem
bundle cache [OPTIONS] # Locks and then caches all of the gems into vendor/cache
bundle check [OPTIONS] # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems
bundle clean [OPTIONS] # Cleans up unused gems in your bundler directory
bundle config NAME [VALUE] # Retrieve or set a configuration value
bundle doctor [OPTIONS] # Checks the bundle for common problems
bundle env # Print information about the environment Bundler is running under
bundle exec [OPTIONS] # Run the command in context of the bundle
bundle gem GEM [OPTIONS] # Creates a skeleton for creating a rubygem
bundle help [COMMAND] # Describe available commands or one specific command
bundle help [COMMAND] # Describe subcommands or one specific subcommand
bundle info GEM [OPTIONS] # Show information for the given gem
bundle init [OPTIONS] # Generates a Gemfile into the current working directory
bundle inject GEM VERSION # Add the named gem, with version requirements, to the resolved Gemfile
bundle install PLUGINS # Install the plugin from the source
bundle install [OPTIONS] # Install the current environment to the system
bundle issue # Learn how to report an issue in Bundler
bundle licenses # Prints the license of all gems in the bundle
bundle lock # Creates a lockfile without installing
bundle open GEM # Opens the source directory of the given bundled gem
bundle outdated GEM [OPTIONS] # List installed gems with newer versions available
bundle platform [OPTIONS] # Displays platform compatibility information
bundle plugin SUBCOMMAND ...ARGS # Manage the bundler plugins
bundle pristine [GEMS...] # Restores installed gems to pristine condition from files located in the gem cache. Gem installed from a git reposito...
bundle show GEM [OPTIONS] # Shows all gems that are part of the bundle, or the path to a given gem
bundle update [OPTIONS] # Update the current environment
bundle version # Prints the bundler's version information
bundle viz [OPTIONS] # Generates a visual dependency graph
Options:
[--no-color] # Disable colorization in output
-r, [--retry=NUM] # Specify the number of times you wish to attempt network commands
-V, [--verbose], [--no-verbose] # Enable verbose output mode
```
Thanks.
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Sort all documented settings in the bundle-config man page
### What was the end-user problem that led to this PR?
The problem was we kept on adding new settings to the end of the list, making it completely unordered.
### What was your diagnosis of the problem?
My diagnosis was we should order the list.
### What is your fix for the problem, implemented in this PR?
My fix orders the list and tests that it is indeed ordered.
### Why did you choose this fix out of the possible options?
I chose this fix because I could write a little script to do it.
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
r=segiddins
Compare sources using source's root
### What was the end-user problem that led to this PR?
Given a setup where:
1. A project's Gemfile makes use of another project's Gemfile and the `eval_gemfile` method to share the dependencies. Something like:
```ruby
# project_plugin's Gemfile
eval_gemfile(File.expand_path("../../main_project/Gemfile", __FILE__))
```
2. The main project includes a path gem in it that is nested in the main project:
```ruby
# main_project's Gemfile
gem "foo_gem", :path => "vendor/foo_gem"
```
3. A `bundle install` is followed by a `bundle install --deployment`, the second of which triggers a comparison of the `lockfile.sources` and the `Bundler.definition`
A error will occur when comparing the specs, saying the the "foo_gem" source has been deleted:
```console
$ bundle install
...
$ bundle install --deployment
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
the gemspecs for path gems changed
You have deleted from the Gemfile:
* source: source at `../main_project/vendor/foo_gem`
```
### What was your diagnosis of the problem?
(extracted from the commit message)
When doing the following:
expand(other.original_path)
inside a `Bundler::Source::Path` instance, the `@root_path` from the instance that is having `eq?` called on it, the the `other` instance's `root_path`. This, in obscure cases, can cause a bug when you are doing an nested eval_gemfile or other calls when comparing the lockfile's locked path sources to the `Bundler.definition`'s path sources.
### What is your fix for the problem, implemented in this PR?
Use a new public method, `Bundler::Source::Path#expanded_original_path`, in the `eq?` method instead of using's the instance's `#expand` method.
### Why did you choose this fix out of the possible options?
(extracted from the commit message)
Creating the `expanded_original_path` method allows a public interface to be made available (and doesn't mess with any exiting functionality) that allows comparing the source path of one `Source::Path`'s `expand_path` to another, where each uses their own `root_path` to resolve their full path, instead of sharing the base one and causing edge case bugs
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When doing the following:
expand(other.original_path)
inside a Bundler::Source::Path instance, the `@root_path` from the
instance that is having eql? called on it, the other instance's
root_path. This, in obscure cases, can cause a bug when you are doing an
nested eval_gemfile or other calls when comparing the lockfile's locked
path sources to the Bundler.definition's path sources.
Creating the expanded_original_path method allows a public interface to
be made available (and doesn't mess with any exiting functionality) that
allows comparing the source path of one Source::Path's expand_path to
another, where each uses their own root_path to resolve their full path,
instead of sharing the base one and causing edge case bugs
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
[2.0] Enable specific_platform by default on 2.0
### What was the end-user problem that led to this PR?
The problem was that Bundler has somewhat suspect handling of multi-platform gems. We'd assume that different platform versions of gems were generally interchangeable, so if Bundler resolved to the "ruby" platform gem we'd just blindly try to swap in the gem for the local platform, which could lead to issues (say if the sets of dependencies were different).
### Was was your diagnosis of the problem?
My diagnosis was that we needed to stop only working with the notion of "generic" platforms, which mapped everything to (basically) either java, pure ruby, and windows, and instead keep track of the actual platforms a bundle was being used on, and resolve for those specific platforms.
### What is your fix for the problem, implemented in this PR?
My fix enables the changes made in https://github.com/bundler/bundler/pull/4836 by default on Bundler 2.
### Why did you choose this fix out of the possible options?
I chose this fix because it means Bundler will default to more correct platforms semantics out of the box.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Also ensure the resolver processes specs in the correct order for error messages
|
| | | | | | | | |
|
| |/ / / / / / |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
[RemoteSpecification] Fail gracefully when deps is an array of array of string
Instead of containing Gem::Dependency objects
### What was the end-user problem that led to this PR?
The problem was some gems have invalid gemspecs served by RubyGems.org. See https://github.com/bundler/bundler/issues/5797.
### Was was your diagnosis of the problem?
My diagnosis was (very old) some gemspecs can have `s.dependencies = [["name", "req"]]` instead of `s.dependencies = [Gem::Dependency.new("name", "req")]`.
### What is your fix for the problem, implemented in this PR?
My fix coerces the invalid dependencies to an array of dependency objects so we can fail more gracefully during installation, without spitting out the error template.
Closes #5797.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows resolution to finish, and falls back upon existing error messages.
|
| | | |_|/ / /
| |/| | | |
| | | | | |
| | | | | | |
string insted of containing Gem::Dependency objects
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Use the Package command for `bundle cache` on Bundler 2
### What was the end-user problem that led to this PR?
The problem was the current `bundle cache` is obsolete.
### Was was your diagnosis of the problem?
My diagnosis was we want `bundle package` to be `bundle cache`, but can't change the `cache` behavior due to backwards compatibility.
### What is your fix for the problem, implemented in this PR?
My fix is to redirect `bundle cache` to `bundle package` on Bundler 2.
### Why did you choose this fix out of the possible options?
I chose this fix because it implements https://github.com/bundler/bundler/pull/4008 without breaking the current `bundle cache` command on master.
|
| | |/ / / / / |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
r=segiddins
remove forbidden chars in cassettes pathname
### What was the end-user problem that led to this PR?
Users running Micorsoft Windows are currently unable to clone to Bundler project due to a forbidden character in the folder path:
`spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/api/v1/dependencies?gems=bundler'`
The `?` being the forbidden character.
See #5828
### What is your fix for the problem, implemented in this PR?
Replaced the forbidden character in the folder name with a `-` and updated the VCR spec helper to replace any forbidden character with a `-` in the filename function.
### Why did you choose this fix out of the possible options?
This was the most simple approach to fix the issue.
|
