summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Update for new bors merge commit messagesegiddins/new-bors-merge-commit-messageSamuel Giddins2018-10-021-2/+2
|
* Merge #6687Bundlerbot2018-09-301-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6687: Fix assignment in condition. r=colby-swandale a=voxik I am not sure what is the purpose of this code neither I have idea if the proposed fix is actually correct, but I am quite sure that the condition does not make sense, because the assignment takes priority and therefore the branch is never accessible. So I just take a guess and submitted this PR to open the discussion ;) Please note this was pointed out by Coverity scan of the Bundler code: ~~~ Error: DEADCODE (CWE-561): rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". Now the type of "nil && Bundler.rubygems().loaded_specs("bundler")" must be null. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: assignment: Assigning: "loaded_spec" = "nil && Bundler.rubygems().loaded_specs("bundler")". rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: possible_types: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the type of "loaded_spec" must be null. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: implied_false: "nil" implies that the truth value of "nil" must be false. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". The truth value of "nil && Bundler.rubygems().loaded_specs("bundler")" must be false. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: truth: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the truth value of "loaded_spec" must be false. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_condition: The condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))" cannot be true. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_line: Execution cannot reach the expression "idx << loaded_spec" inside this statement: "(loaded_spec = (nil && Bund...". # 20| s.loaded_from = File.expand_path("..", __FILE__) # 21| end # 22|-> if loaded_spec = nil && Bundler.rubygems.loaded_specs("bundler") # 23| idx << loaded_spec # this has to come after the fake gemspec, to override it # 24| elsif local_spec = Bundler.rubygems.find_name("bundler").find {|s| s.version.to_s == VERSION } ~~~ Co-authored-by: Vít Ondruch <vondruch@redhat.com>
| * Fix assignment in condition.Vít Ondruch2018-09-251-1/+1
| |
* | Merge #6708Bundlerbot2018-09-262-13/+47
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6708: Fix only_update_to_newer_versions regression r=greysteil a=theflow This is my attempt to fix #6529 ### What was the end-user problem that led to this PR? Running `bundle update` with `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS: "true"` resulted in a gem getting downgraded to a really old version in a certain edge case. Ironically it wouldn't get downgraded when `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS` was set to false. ### What was your diagnosis of the problem? My diagnosis was that https://github.com/bundler/bundler/commit/47256d20cb05ebc724ee67173094682153b6b4aa tried to solve the problem of still allowing manual downgrades in the Gemfile while `only_update_to_newer_versions` is true. But introduced a regression that prevented the `additional_base_requirements_for_resolve` method to work as intended: This is the relevant change from that commit that tries to avoid adding the `>=` requirement if the requirement in the Gemfile is different than the requirement in the lockfile (as far as I understand it): ```ruby next requirements if @locked_deps[name] != dependencies_by_name[name] ``` I identified two problems 1. `dependencies_by_name[name]` returns an array of `Bundler::Dependency`, where as `@locked_deps[name]` just returns a single `Bundler::Dependency`. Comparing the two will always be false. 1. `@locked_deps` is always empty in case of `bundle update`. See: https://github.com/bundler/bundler/blob/3d9e6167a7df9ca89a030dfe95c7cdff293e74a9/lib/bundler/definition.rb#L95 ### What is your fix for the problem, implemented in this PR? My fixes: 1. Make sure `dependencies_by_name` is a hash with `Bundler::Dependency` as values 1. Fetch the `@locked_gems.dependencies` again instead of using `@locked_deps` 1. The existing test worked for me with and without the `only_update_to_newer_versions` set to true, I replaced it with a reproduction of the edge case I was investigating (this is as minimal as I could make it) 1. I've added a test for the manual downgrading case. ### Why did you choose this fix out of the possible options? This is the only way I could make these cases work. It's possible there are other edge cases I don't understand. Co-authored-by: Florian Munz <surf@theflow.de>
| * | make `only_update_to_newer_versions` work correctly with `bundle update`Florian Munz2018-09-252-13/+47
|/ /
* | Merge #6707Bundlerbot2018-09-253-10/+27
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6707: Run more assertions in more cases r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? I noticed a couple of places where assertions were being excluded and they shouldn't: * One was introduced by me in #6702, where the specs added (and some already present) started being tested only on bundler 2.x. * The other one was introduced in f7414bcb17fe1bd67246021251b5f0527bd6afd1, where one assertion would be run only if a certain env variable was not set. I think it was because of a TravisCI environmental issue that now seems fixed. ### What was your diagnosis of the problem? My diagnosis was that none of these exclusions are necessary. ### What is your fix for the problem, implemented in this PR? My fix is to restore the excluded assertions to all environments and branches. ### Why did you choose this fix out of the possible options? I chose this fix because it seems best to avoid future problems. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Improve redownload specsmore_assertionsDavid Rodríguez2018-09-242-6/+26
| | | | | | | | | | | | So they are run on bundler 1.x too.
| * | Remove unnecessary assertion exclusionremove_unnecessary_assertion_exclusionDavid Rodríguez2018-09-241-4/+1
| | | | | | | | | | | | I think this was a bad fix and it's no longer necessary.
* | | Merge #6686Bundlerbot2018-09-251-5/+7
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6686: Output OpenSSL information only when OpenSSL is available. r=segiddins a=voxik It seems that only single OpenSSL availability check should be enough to output or not output the OpenSSL information. I split this into two commits, so you can cherry-pick, in case you want to be more cautious about the availability of specific constants, but since they were introduced in Ruby 1.8.0 (https://github.com/ruby/ruby/commit/78ff3833fb67c8005a9b851037e7), I would not bother. Please note that that this code was pointed out by Coverity scanner (although it is definitely not an error): ~~~ Error: FORWARD_NULL (CWE-476): rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:113: null_check: Calling "defined?(OpenSSL)" implies that "OpenSSL" might be null-like. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:114: property_access: Accessing a property of null-like value "OpenSSL". # 112| out << [" Bin Dir", Gem.bindir] # 113| out << ["OpenSSL"] if defined?(OpenSSL) # 114|-> out << [" Compiled", OpenSSL::OPENSSL_VERSION] if defined?(OpenSSL::OPENSSL_VERSION) # 115| out << [" Loaded", OpenSSL::OPENSSL_LIBRARY_VERSION] if defined?(OpenSSL::OPENSSL_LIBRARY_VERSION) # 116| out << [" Cert File", OpenSSL::X509::DEFAULT_CERT_FILE] if defined?(OpenSSL::X509::DEFAULT_CERT_FILE) ~~~ Co-authored-by: Vít Ondruch <vondruch@redhat.com>
| * | Output OpenSSL information only when OpenSSL is available.Vít Ondruch2018-09-061-5/+7
| |/
* | Merge #6316Bundlerbot2018-09-242-1/+48
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6316: Display reason to require sudo r=colby-swandale a=okkez This is useful for non-interactive installation with bundler. ### What was the end-user problem that led to this PR? https://github.com/treasure-data/omnibus-td-agent/issues/166 I could not notice that bundler needs sudo privilege from logs. So I checked bundler code. ### What was your diagnosis of the problem? Bundler does not show the reason to need sudo privilege. ### What is your fix for the problem, implemented in this PR? Display reason to require sudo. ### Why did you choose this fix out of the possible options? If bundler displays reason to require sudo, we can notice permission problems as soon as possible. Co-authored-by: Kenji Okimoto <okimoto@clear-code.com>
| * | Sort unwritable_filesKenji Okimoto2018-04-231-1/+1
| | | | | | | | | | | | Because Dir#[] will return unsorted results.
| * | Display unwritable files in each lineKenji Okimoto2018-04-232-4/+10
| | |
| * | Add backward compatibility code for Ruby 1.8.7Kenji Okimoto2018-04-231-2/+8
| | |
| * | Use 0o for octal literalsKenji Okimoto2018-04-231-1/+1
| | | | | | | | | | | | | | | | | | spec/bundler/bundler_spec.rb:251:25: C: Style/NumericLiteralPrefix: Use 0o for octal literals. FileUtils.chmod(0400, "tmp/vendor/bundle/unwritable.txt") ^^^^
| * | Add test for Bundler.requires_sudo?Kenji Okimoto2018-04-231-0/+31
| | |
| * | Scan files array only onceKenji Okimoto2018-04-231-2/+2
| | | | | | | | | | | | | | | In normal case, all elements in `files` are writable. So all elements in `files` are scanned.
| * | Use double quote instead of single quoteKenji Okimoto2018-04-231-1/+1
| | | | | | | | | | | | | | | | | | lib/bundler.rb:372:120: C: Style/StringLiteralsInInterpolation: Prefer double-quoted strings inside interpolations. Bundler.ui.warn "Following files may not be writable, so sudo is needed: #{unwritable_files.map(&:to_s).join(',')}" ^^^
| * | Display reason to require sudoKenji Okimoto2018-04-231-0/+4
| | | | | | | | | | | | This is useful for non-interactive installation with bundler.
* | | Merge #6706Bundlerbot2018-09-241-8/+3
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6706: Clean up some specs r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that some specs could be more readable and clean. ### What was your diagnosis of the problem? My diagnosis was that some stuff could be more explicit, some TODO's could be removed because they're already fixed, and there should not be typos. ### What is your fix for the problem, implemented in this PR? My fix is to make the obvious changes to fix what I diagnosed. ### Why did you choose this fix out of the possible options? I chose this fix because it makes the specs clear, in my opinion. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Fix typoclean_up_some_specsDavid Rodríguez2018-09-231-1/+1
| | | |
| * | | Fix TODO noteDavid Rodríguez2018-09-231-3/+0
| | | |
| * | | Remove unnecessary requireDavid Rodríguez2018-09-231-1/+1
| | | |
| * | | Remove unnecessary commentDavid Rodríguez2018-09-231-1/+0
| | | | | | | | | | | | | | | | | | | | There's nothing particular about this spec that needs a comment over the other specs in this same context.
| * | | Move require to a better place for readabilityDavid Rodríguez2018-09-231-2/+1
| | | | | | | | | | | | | | | | And because the other specs don't need it.
* | | | Merge #6702Bundlerbot2018-09-246-69/+132
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6702: Better `--force` to `--redownload` transition r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was. that, while trying to run `bundle install --force` today, I was getting the error `unknown switch --force` error, and I was not sure what was causing it and what I needed to do to fix it. Also, running `bundle install --help` would show `--force` as a supported option, so that would make things even more confusing. ### What was your diagnosis of the problem? My diagnosis was that: * A lot of removal/renaming of options in bundler 2 are artificially linked to the `forget_cli_options` switch. To me, those changes even though they are related (stopping rememebering cli options prompted us to actually remove some unnecessary ones), they are independent, so it's not straighforward to find out that it's the `forget_cli_options` setting causing this rename to be in place. * We should show a helpful deprecation message instead of a hard error, so the transition is easier for users. * We should update the commands help to document newer instead of deprecated options. * The `bundle update` command has an equivalent `--force` option that should be renamed too for sanity. ### What is your fix for the problem, implemented in this PR? My fix to the above problems is to: * Always keep the `--force` alias, independently of whether the `forget_cli_options` is set or not. * Show a deprecation message when `--force` is used in bundler 2, but still keep it working as before. * Update the commands help to use `--redownload`. * Make the equivalent changes to the `bundle update` ### Why did you choose this fix out of the possible options? I chose this fix because it seems like the more user friendly way going forward in my opinion. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Limit redownload specs to bundler 2better_force_to_redownload_transitionDavid Rodríguez2018-09-192-2/+2
| | | | |
| * | | | Make the equivalent change to `bundle update`David Rodríguez2018-09-183-3/+38
| | | | |
| * | | | Fix issue with initial implementationDavid Rodríguez2018-09-182-5/+15
| | | | |
| * | | | Document the supported optionDavid Rodríguez2018-09-181-2/+2
| | | | |
| * | | | Deprecate `bundle install --force`David Rodríguez2018-09-182-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of hard erroring, deprecate the `--force` flag on bundler 2 to better teach users about the replacement. Before: $ bundle install --force Unknown switches '--force' After: $ bundle install --force [DEPRECATED FOR 2.0] The `--force` option has been renamed to `--redownload` Could not locate Gemfile # or whatever the expected behavior for --redownload is
| * | | | Convert redownload/force specs to shared specsDavid Rodríguez2018-09-181-39/+47
| | | | |
| * | | | Rename spec file to use the preferred option nameDavid Rodríguez2018-09-181-0/+0
| | | | |
* | | | | Merge #6694Bundlerbot2018-09-232-23/+6
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6694: Fix local spec failure r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that bundler specs won't pass on my system. One of the two failures I was getting is the spec added by #6502. ### What was your diagnosis of the problem? My diagnosis was that my system has a similar setup as TravisCI (Linux with a ruby version manager on top), but I don't set the `TRAVIS` environment variable to run the tests. This means some trickery used in the specs to get them green on TravisCI is not applied to my local run, so specs failed. ### What is your fix for the problem, implemented in this PR? My fix is to make this spec green independently from whether it's run on TravisCI or not. My changes also make this spec not delete any files from the rubygems installation where the specs are running. In https://github.com/bundler/bundler/pull/6502#issuecomment-403713916 @indirect said that the files being deleted here are put in there by `RVM`. However, I don't think that's accurate, it's `gem update --system` putting these files in there. So if these files should not be there, we should not put them there in the first place instead of deleting them during bundler's specs. ### Why did you choose this fix out of the possible options? I chose this fix because the alternative would be to set the `TRAVIS` environment variable before running the specs locally, but that would mean that `bundler`'s specs would delete files from my global `rubygems` installation, which seems... no good. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Friendlier solution for a problematic specfix_local_spec_failureDavid Rodríguez2018-09-172-13/+5
| | | | |
| * | | | Move common stuff to inside letDavid Rodríguez2018-09-171-3/+3
| | | | |
| * | | | Modify env only in subprocessDavid Rodríguez2018-09-171-3/+1
| | | | |
| * | | | Improve specDavid Rodríguez2018-09-171-8/+1
| |/ / / | | | | | | | | | | | | There's an option to explicitly not pass lib to the LOAD_PATH.
* | | | Merge #6703Bundlerbot2018-09-192-1/+11
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6703: Switch from Homu to Bors mergebots r=colby-swandale a=indirect ### What was the end-user problem that led to this PR? Our existing @bundlerbot mergebot is run by [bundlerbot-homu](https://github.com/bundler/bundlerbot-homu), which is a fork of japaric/homu-on-heroku, which is a fork of servo/homu, which is a fork of barosl/homu. Sadly, most of those forks are now unmaintained, including ours. Also, Homu sets up a list of users who are allowed to approve PRs with a list in a file on an env var, when it probably should just read the list of github users that have the permission to merge. So the end-user problem is: unmaintained mergebot, very inconvenient to update team members. ### What was your diagnosis of the problem? My diagnosis is that we should migrate from a Homu-based mergebot to a bors-ng-based mergebot. Bors-ng lives at [bors-ng/bors-ng](https://github.com/bors-ng/bors-ng), and has a website at [bors.tech](https://bors.tech). Bors-ng is actively maintained, easy to deploy to Heroku, doesn't lose repo and PR state when the webapp is restarted, and uses GitHub permissions to determine who can approve PRs for merging. ### What is your fix for the problem, implemented in this PR? My fix for this problem was to fork bors-ng to the @bundler organization, modify bors-ng to respond to `@bundlerbot r+` instead of responding to `bors r+`, and change the configuration files below to support using bors instead of homu. The bors-ng repo has already accepted our patch, and we maybe don't even need to keep the forked repo anymore. The new mergebot lives at https://bundlerbot-bors.herokuapp.com, and has the exact same issue-comment interface as the previous mergebot. ### Why did you choose this fix out of the possible options? I chose this fix because it lets us keep the exact same mergebot interface that we have today, while easing the maintenance burden both on updating end-user permissions and on updating the app over time, since we can simply pull and deploy the latest from `bors-ng/bors-ng` without maintaining our own specialized fork. Co-authored-by: Andre Arko <andre@arko.net>
| * | | | wait up to 4 hours for staging pushes to buildAndre Arko2018-09-191-0/+2
| | | | |
| * | | | tell bors to use Travis to testindirect/homu-to-borsAndre Arko2018-09-191-0/+4
| | | | |
| * | | | let's see if the other format parsesAndre Arko2018-09-191-1/+3
| | | | |
| * | | | configure bors instead of homuAndre Arko2018-09-182-1/+3
| | | | |
* | | | | merge v1.16.5Colby Swandale2018-09-193-2/+18
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 1-16-stable: Version 1.16.5 with changelog scope TruffleRuby platform specs to be RubyGems >= 2.1.0 Auto merge of #6689 - bundler:colby/fix-bundler-load-error, r=colby-swandale Auto merge of #6695 - bundler:segiddins/6684-gvp-prefer-non-pres, r=colby-swandale Auto merge of #6693 - eregon:truffleruby, r=colby-swandale Auto merge of #6692 - eregon:simplify-autoload-require-deprecate, r=segiddins Auto merge of #6688 - voxik:check-search, r=colby-swandale Auto merge of #6682 - bundler:bundle_env_formatting, r=colby-swandale Auto merge of #6675 - MaxLap:master, r=greysteil Auto merge of #6669 - ChrisBr:fix_dep_proxy, r=segiddins Auto merge of #6664 - greysteil:avoid-printing-git-error, r=colby-swandale
| * | | | | Version 1.16.5 with changelogv1.16.5Colby Swandale2018-09-182-1/+17
| | | | | |
| * | | | | scope TruffleRuby platform specs to be RubyGems >= 2.1.0Colby Swandale2018-09-182-2/+2
| | | | | |
| * | | | | Auto merge of #6689 - bundler:colby/fix-bundler-load-error, r=colby-swandaleThe Bundler Bot2018-09-142-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix loadError occurring in nested bundle exec calls ### What was the end-user problem that led to this PR? There is a LoadError occurring in Bundler when an application has its Gemfile installed with `--path`, and the user has a recent version of RubyGems that installs a version of Bundler as a default gem. If the user has some code that they're running with `bundle exec` (like a test suite) that is shelling out and executing `bundle exec` again, the user will receive an error saying that Bundler could not be loaded. /home/travis/.rvm/gems/ruby-2.5.1/bin/bundle:23:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-2.5.1/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/exe/bundle (LoadError) The problem that's happening is that when we run `bundle exec`, Bundler will set the Ruby environment to add the path of the current version of Bundler into the `LOAD_PATH` and also require `bundler/setup`. RUBYOPT=-rbundler/setup RUBYLIB=/usr/local/bundle/gems/bundler-1.16.4/lib This will have Ruby load the lib directory of the version of Bundler the user installed, but it's been loaded with the Gemspec from the default gem version of Bundler that RubyGems installed. This gemspec is being loaded because RubyGems has a copy of the Bundler gemspec sitting in the default gems. And because we changed `GEM_HOME` when the user ran Bundler with `bundle install --path`, RubyGems just figures that seeing this is only Bundler gemspec it can find, then it should activate it but then `RUBYLIB` comes into play and just overrules RubyGems to load the newer Bundler src. This is ultimately what's giving us the weird load path that doesn't exist. ![mind blown](https://thumbs.gfycat.com/BlankScarceAfricanporcupine-size_restricted.gif) ### What was your diagnosis of the problem? See #6537 and #6629 ### What is your fix for the problem, implemented in this PR? When we set the `BUNDLE_BIN_PATH` env var inside bundler, check that the file exists. If it doesn't, we will just set it to the bundle executable file. ### Why did you choose this fix out of the possible options? This seems to be the solution that patches the LoadError issue without having to heavily refactor code or make the existing code more complicated. (cherry picked from commit 8c31a61037e2d526affb13d4fe07035e18266947)
| * | | | | Auto merge of #6695 - bundler:segiddins/6684-gvp-prefer-non-pres, ↵The Bundler Bot2018-09-144-5/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r=colby-swandale [GemVersionPromoter] Prefer non-pre-release versions ### What was the end-user problem that led to this PR? The problem was `bundle update --patch` could cause a prerelease to be resolved, when it shouldn't have been. Closes #6684. ### What was your diagnosis of the problem? My diagnosis was the resolver moved pre's to be first when no pre requirement was specified, but then the GVP did its own sorting. ### What is your fix for the problem, implemented in this PR? My fix was to re-implement that "pre's go first unless they were explicitly requested" logic in the GVP. ### Why did you choose this fix out of the possible options? I chose this fix because it allows the GVP to properly sort versions, making it entirely correct without dependence upon the resolver. (cherry picked from commit 87f49b2dc000b38776e6a73924e63ec090d53062)
| * | | | | Auto merge of #6693 - eregon:truffleruby, r=colby-swandaleThe Bundler Bot2018-09-1410-14/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for TruffleRuby Hello, This PR adds support for TruffleRuby in Bundler. I searched for `rbx` and `jruby` (case-insensitive) through the codebase to find all places which need changes and where tests use specific Ruby implementations. So hopefully this PR is complete, but please tell me if I missed something. I'd also like to test TruffleRuby in Bundler's CI, but will do this as a separate PR, as we first need the next release of TruffleRuby so that it includes the fix for https://github.com/oracle/truffleruby/issues/1413. (cherry picked from commit 368d7594adbdf83032719011d7608545faf2d942)
| * | | | | Auto merge of #6692 - eregon:simplify-autoload-require-deprecate, r=segiddinsThe Bundler Bot2018-09-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check that Bundler::Deprecate is not an autoload constant * Otherwise, it should be defined by this file. * The issue is bundler/deprecate.rb checks `defined? Bundler::Deprecate` and this would normally return true since an autoload is defined for that constant. But since the autoload file is #require-d explicitly (by bundler/psyched_yaml and bundler/shared_helpers), MRI makes it undefined to save this pattern. This however requires a complex autoload implementation and is confusing to debug, so let's simplify. * Related to https://github.com/bundler/bundler/issues/6163 and https://github.com/rubinius/rubinius/issues/3769. ### What was the end-user problem that led to this PR? Bundler fails in TruffleRuby without this change. We plan to fix this case in TruffleRuby, but since at least 2 Ruby implementations did not expect such a corner case, we should make the code simpler since it's easy enough in this case. ### What was your diagnosis of the problem? See above. ### Why did you choose this fix out of the possible options? It's simple and does not break if an extra `require "bundler/deprecate"` is later added in the codebase. (cherry picked from commit 02af3c2def7ea1e16ad7df4842d35f4bb568ad29)
View Lorry Controller Status