Bundler 1.15.0 having issues with omniauth gems #5696
Comments
|
This looks like an issue with |
|
I kind of thought the same thing at first, but then I saw this, which confused me even more really: I can take I'm not sure how to run rails without using bundler. |
|
We started seeing this issue immediately upon upgrading from 1.14.6 to 1.15.0 (and still with 1.15.1). Wondering if maybe it's related the the optimizations you guys did with |
|
Its definitely possible we broke things, if y'all wanted to help us speed up looking into the issue, narrowing down the reproduction would be super helpful since thats a massive gemfile |
|
I was able to put together a repro that is more minimal than the Gemfile above. Note that if you remove the repro.sh: #!/bin/bash
mkdir -p /tmp/bundler
cd /tmp/bundler
gem update bundler
gem install rails -v 4.2.5.1
bundle env
# Bundler 1.15.1
# Rubygems 2.6.12
# Ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-darwin16]
# Git 2.13.0
# Platform x86_64-darwin-16
rails new bundler_test
cd bundler_test
cat > Gemfile <<EOF
source 'https://rubygems.org'
gem 'rails', '4.2.5.1'
gem 'sprockets', '2.12.3'
gem 'sprockets-rails', '2.2.4'
gem 'sass-rails', '~> 5.0'
gem 'uglifier', '>= 1.3.0'
gem 'coffee-rails', '~> 4.1.0'
gem 'jquery-rails'
gem 'jquery-ui-rails'
gem 'jbuilder', '~> 2.0'
gem 'rake', '< 11.0'
gem 'omniauth'
gem 'omniauth-oauth2'
gem 'omniauth-cas', git: 'https://github.com/CruGlobal/omniauth-cas'
gem 'oa-openid'
EOF
bundle update
# Expected behavior: rails starts
# Observed behavior: crash with error backtrace
rails s |
|
Thanks! So 50e899d broke this, I'll make a PR with a fix shortly (it seems some gems are relying upon the ordering of |
This is required for backwards compatibility, see issue #5696 for an example
|
Great, I'm glad you were able to figure out what was going on. :) |
[SpecSet] Sort by name in #tsort Closes #5696 This is required for backwards compatibility, see issue #5696 for an example. The issue is that previous versions of bundler would have the load path in one (correct) order, and master has them in another (correct) order. So some projects depend on the load path ordering when multiple gems have the same requirable file. - [x] Test case
[SpecSet] Sort by name in #tsort Closes #5696 This is required for backwards compatibility, see issue #5696 for an example. The issue is that previous versions of bundler would have the load path in one (correct) order, and master has them in another (correct) order. So some projects depend on the load path ordering when multiple gems have the same requirable file. - [x] Test case (cherry picked from commit e32353b) # Conflicts: # spec/runtime/setup_spec.rb
I'm honestly not sure if this is a bundler issue or something with my rails app, since it's only happening in one of my rails apps, but rails apps with similar configurations are working fine.
Questions
Please fill out answers to these questions, it'll help us figure out why things are going wrong.
Updated to bundler 1.15.0.
The rails app to run normally, and travis and jenkins to be able to build the app like normal.
The rails app fails to start locally, and travis and jenkins builds fail.
I tried downgrading to v1.14.6, which worked as expected.
Yes.
Backtrace
Environment
Environment
Bundler settings
Gemfile
Gemfile
Gemfile.lock
The text was updated successfully, but these errors were encountered: