<ddd>
my bad I was looking at the wrong repo (been working on several)
<ddd>
i have the Gemfile set to determine jruby or not and install appropriate gems. I've been using jruby but switched to MRI ruby. Was building against MRI, JRuby, and rbx. rbx keeps puking. Here's another one: https://travis-ci.org/dtf-gems/dtf/jobs/14586425
<ddd>
brixen: ignore the hacky crappy code :) its a near and dear project i'm using to develop my skills. obviously in need of more work hehe
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Paul_G_ has joined #bundler
dwradcliffe has quit [Ping timeout: 246 seconds]
Paul_G has quit [Ping timeout: 246 seconds]
dwradcliffe has joined #bundler
patcon has quit [Remote host closed the connection]
patcon has joined #bundler
patcon has quit [Ping timeout: 252 seconds]
jfoy has quit [Quit: jfoy]
havenwood has quit [Remote host closed the connection]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<retro|cz>
indirect, hello, are you around? I'm facing an issue with bundler and gemspec, but I'm not sure if it's bundler issue, so I don't want to mess issue tracker with that without confirmation.
<retro|cz>
It's problem with pre versions. Bundler can't find mongoid 4.0.0.alpha1 with gemspec's `spec.add_dependency "mongoid", '~> 4.0.0'` but `spec.add_dependency "mongoid", '> 3'` works.
ddd has quit [Ping timeout: 240 seconds]
<retro|cz>
maybe ckrailo or lmarburger can decide ^
robbyoconnor has quit [Read error: Operation timed out]
rjhunter has quit [Remote host closed the connection]
rjhunter has joined #bundler
chouhoulis has joined #bundler
samphippen has joined #bundler
samphippen has quit [Read error: Connection reset by peer]
chouhoulis has quit [Remote host closed the connection]
chouhoulis has joined #bundler
chouhoul_ has joined #bundler
chouhoul_ has quit [Remote host closed the connection]
<whack>
This particular project is supported under multiple versions of ruby.
<whack>
(like many ruby projects) ;)
<Radar>
Right... I deal with that in my projects too. I don't understand how the multiple rubies are competing?
<whack>
'bundle install' under 1.9.3 makes Gemfile.lock. 'bundle install' next under JRuby 1.7.8 modifies the Gemfile.lock (because it'll get the -java deps, etc)
<Radar>
Oh, right.
<whack>
which causes, among other annoyances, merge conflicts when patches get sent around since 'best practice' seems to be recommending putting the .lock file into revision control
<Radar>
I think the difference between you and me is that I don't treat the Gemfile.lock as a fixed point in time... The Gemfile specifies the dependencies and then the Gemfile.lock can be wiped away whenever
<Radar>
i.e. I should be able to run "bundle update" fearlessly on the project and have it still work
<whack>
Radar: no difference there. Just want to avoid 1) extra time spent regenerating the .lock and 2) merge conflicts and other pains with managing Gemfile.lock in git
<Radar>
whack: Can't you just ignore Gemfile.lock in Git?
<Radar>
I don't think there's a clean solution to this other than that.
<whack>
probably, though I don't remember what parts of bundler refuse to work if Gemfile.lock doesn't exist
<Radar>
I think none of it. Seems to work just fine here.
<Radar>
"bundle install --local" can speed up the generation of that, assuming that the machine already has the right dependencies installed
<Radar>
alias ta='bundle check || (echo "Trying to bundle locally..." && rm -f Gemfile.lock && bundle install --local) || (echo "Bundling using remote sources..." && bundle update)'