00:07 <tmoore> I think the ship has already sailed with Bundler in any case... adding it now would break backwards compatibility. Maybe in 2.0.

00:16 <zenspider> tmoore: I don't think it'd break backwards compatibility. you'd simply not see those gems next time around and a `bundle` would fix that

00:16 <zenspider> on the isolate side, you'd just run your code and next time through it'd resolve the unmet dependencies

00:45 <tmoore> hmm yeah maybe so

00:48 <zenspider> I'm also thinking about releasing this as a gem plugin... so ppl can opt-in

00:48 <Radar> What's the site that Bundler uses for its metrics? Pretty graphs and whatnot?

00:49 <Radar> librato!

14:49 <apeiros> hi there. under what circumstances would a plain `bundle` modify the Gemfile.lock? I was under the impression that `bundle` alone should use the lock file, but not change it. no?

15:42 <apeiros> sorry, forgot to tell when I had to commute

15:42 <apeiros> any reply to my question in the meantime?

15:42 <dwradcliffe> apeiros: bundle == bundle install

15:48 <apeiros> dwradcliffe: yes. which shouldn't change the lockfile either. bundle update should. or am I mistaken?

18:16 <indirect> apeiros: you're mistaken. bundle install has updated the lockfile since 1.0

18:16 <indirect> (roughly four years ago)

18:16 <indirect> if you explicitly want to raise an exception rather than change the lockfile, use --deployment mode

18:17 <apeiros> indirect: and in which situations does it do that?

18:18 <indirect> apeiros: I don't understand the question... situations where you run bundle install with --deployment

18:18 <apeiros> indirect: I mean in what situations would a `bundle install` modify the lockfile?

18:19 <indirect> any situation where the Gemfile has changed in any way

18:19 <apeiros> it certainly is the exception as I'm using bundler since before 1.0 and it happened for the first time for me

18:19 <apeiros> indirect: ok, gemfile did not change

18:19 <indirect> oh

18:19 <indirect> you upgraded bundler and it removed credentials from the lock?

18:19 <apeiros> no, I cloned a repository and did a fresh bundle install

18:20 <apeiros> I'm not at work anymore, but iirc it added a line to the lockfile

18:20 <indirect> they probably checked in a gemfile and a lock that don't match

18:20 <indirect> there's nothing that stops that

18:20 <apeiros> containing a variant of the ffi gem (again, iirc)

18:20 <indirect> or platform changed

18:21 <indirect> installing on jruby with a lock generated on mri can change the lockfile

18:21 <apeiros> we all use osx, same version too

18:21 <apeiros> the mismatching gemfile and lockfile is possible, though it'd surprise me

18:21 <indirect> I mean, that's fine, but doesn't mean it's a bug

18:21 <indirect> when you get access to the gemfile and lock again, go ahead and follow the steps at http://bit.ly/bundler-issues and file a ticket

18:21 <indirect> then I can tell you exactly why

18:45 <apeiros> I will try to verify/refute gemfile/lock mismatch first, and then look further. thank you!

23:15 <mib_mib> hi all - having some trouble - in my gemfile on production i have gem 'some-gem', '>=0.1.2", git: 'http://github.com/myrepo/mygem.git', and 0.1.2 is installed on the server in /my/repo/vendor/bundle/ruby/1.9.1/bundler/gems/mygem-commithash -- i have updated the code in git and want to force update install of the newest version (0.1.15), so i do bundle update --source mygem, , but this command fails with 'Could not find myrepo-0.1.12

23:16 <mib_mib> It seems its still looking for the old version - why would this be?

23:38 <mib_mib> why are gems that have a git: attribute in my gemfile installed to vendor/bundle/ruby/1.9.1/bundler/gems instead of just vendor/bundle/ruby/1.9.1/gems folder?