patcon has quit [Remote host closed the connection]
patcon has joined #bundler
patcon_ has joined #bundler
patcon has quit [Read error: Connection reset by peer]
JordanFaust_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rjhunter has joined #bundler
rjhunter has quit [Ping timeout: 264 seconds]
patcon_ has quit [Remote host closed the connection]
rjhunter has joined #bundler
patcon has joined #bundler
patcon has quit [Ping timeout: 265 seconds]
rjhunter has quit [Ping timeout: 265 seconds]
rjhunter has joined #bundler
rjhunter has quit [Ping timeout: 240 seconds]
cwebber has joined #bundler
cwebber has quit [Client Quit]
rjhunter has joined #bundler
rjhunter has quit [Ping timeout: 264 seconds]
samphippen has joined #bundler
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rjhunter has joined #bundler
rjhunter has quit [Ping timeout: 264 seconds]
robbyoconnor has joined #bundler
samphippen has joined #bundler
JordanFaust_ has joined #bundler
retro|cz has joined #bundler
JordanFaust_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
samphippen has joined #bundler
rjhunter has joined #bundler
rjhunter has quit [Ping timeout: 272 seconds]
rjhunter has joined #bundler
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
robbyoconnor has quit [Ping timeout: 264 seconds]
Who has joined #bundler
rjhunter has quit [Remote host closed the connection]
Who has quit [Ping timeout: 245 seconds]
Who has joined #bundler
cwebber has joined #bundler
samphippen has joined #bundler
patcon has joined #bundler
rjhunter has joined #bundler
rjhunter has quit [Ping timeout: 246 seconds]
Who has quit [Ping timeout: 272 seconds]
Who has joined #bundler
patcon has quit [Remote host closed the connection]
patcon has joined #bundler
patcon has quit [Ping timeout: 240 seconds]
Who has left #bundler [#bundler]
patcon has joined #bundler
akerl has quit [Ping timeout: 245 seconds]
ddd has quit [Quit: for system reboot to new kernel]
patcon has quit [Ping timeout: 272 seconds]
hone has joined #bundler
patcon has joined #bundler
retro|cz has quit [Ping timeout: 264 seconds]
ddd has joined #bundler
jrochkind has joined #bundler
<jrochkind>
hey, can anyone explain bundler version release plans? I _think_ 1.3.5 is the latest non-prerelease version, right?
<jrochkind>
I'm confused that I'm seeing 1.4 and 1.5 pre-releases, but no 1.4 finals.
havenwood has joined #bundler
akerl has joined #bundler
ckrailo has quit [Ping timeout: 252 seconds]
ckrailo has joined #bundler
patcon has quit [Remote host closed the connection]
patcon has joined #bundler
patcon has quit [Ping timeout: 248 seconds]
<ckrailo>
jrochkind: 1.4 got aborted :)
<jrochkind>
okay, there will never be a 1.4? Cool. Suggest you add that to the FAQ! thanks!
<ckrailo>
some critical additions were needed and it’d break semver to add them under 1.4 after an RC, so it was aborted.
<jrochkind>
but 1.5 is next (which would still break semver if it had backwards compat, right?), right?
<jrochkind>
or is 1.5 aborted too, and 2.0 will be next!
<ckrailo>
well, secondary versions are theoretically backwards compatible
<ckrailo>
primary versions are where you can break backwards compat
<ckrailo>
:)
<jrochkind>
so 1.5 is expected next, and is expected to be fully backwards compat complying with semver?
<ckrailo>
that’s the goal, yup
<jrochkind>
cool, thanks. suggest adding it an FAQ somewhere. which I guess is http://bundler.io/v1.5/faq.html if you start at bundler.io and click on 'view FAQs'
<jrochkind>
i was having bundler issues, and went to make sure I had the latest stable bundler installed, and got confused trying to figure it out.
<ckrailo>
ah
<ckrailo>
good idea
<jrochkind>
Incidentally, I think I found a bundler bug, but I'm def not going to be able to isolate it — but I could give you a (possibly complicated) Gemfile that reproduces it, if someone wants it.
<jrochkind>
I found a workaround for my needs — had to remove a dependency from gemfile, bundle update, then add it back and bundle update again — which definitey seems to strongly suggest it's a bundler bug, as I don't think that should ever work to do that!
<jrochkind>
bundler was saying there were conflicting dependencies — but there weren't. But it's a complicated gemfile involving some :github dependencies, which I suspect is involved in the bug.
<ckrailo>
uhhhh, one sec. i might be wrong about stuff, i think 1.5 came out (i’ve been AFK for a bit, heh)
<jrochkind>
yeah, I'm confused about that one — the bundler docs are 1.5, but according to rubygems there appear to be only rc's for 1.5. I guess it's release is imminent? https://rubygems.org/gems/bundler
<jrochkind>
i guess I should try an rc and see if the bug is still there before reproducing. if it does, do you want it, even if all I have is a Gemfile and a descirption of somethign that doesn't seem right?
<ckrailo>
hmmm that’s embarrassing
<ckrailo>
i should pay more attention
<ckrailo>
(reading up some logs right now)
<ckrailo>
okay
<ckrailo>
looks like 1.5.rc1 is when the docs came out
<ckrailo>
should be really final’d really soonish?
<ckrailo>
jrochkind: so the dependency resolution algorithm got some TLC… wouldn’t hurt to try out 1.5.rc1 if you want to test
<ckrailo>
and i agree about the docs being confusing, sorry about that. :)
<ckrailo>
if it’s still an issue, it’d be super to open up a github issue and together we can figure out why. esp if it’s something that can be narrowed down where we can add a test for it.
patcon has joined #bundler
<jrochkind>
okay, if I repro in 1.5.rc1, i'll open the github issue. I can attach a Gemfile that reproduces. I honestly don't have a lot of time to get into the guts of bundler myself, but I can give you a complicated Gemfile that reproduces.
patcon has quit [Remote host closed the connection]
patcon has joined #bundler
<ckrailo>
sweet. we might ask you to try out a thing or two (which should be quicker that digging into the guts yourself). :)
<jrochkind>
yep, still repro's on 1.5.rc1.
<jrochkind>
i'll see if I can make the Gemfile smaller and still reproduce, ti's a monster right now.
<jrochkind>
ha, yep, repro'd with only 3 things in the gemfile one of them rails, two of them :github
<jrochkind>
report on the github issues, yes?
<ckrailo>
yes please
<ckrailo>
are the github bits open?
<ckrailo>
seems like that’d be important :)
<jrochkind>
yup. you can install the gemfile.
<jrochkind>
at least, if it wasn't for an apparent bundler bug you could, and you can using a couple workarounds i will document.
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<jacobat>
How come "bundle install" is slow when all it needs to do is install a gem? Say when someone has updated the Gemfile.lock and I run "bundle install"? slow == 1m44s
<jacobat>
Every line of "Using [gem]" takes .5 second
<dwradcliffe_>
jacobat: it's not just installing gems
<dwradcliffe_>
jacobat: it's resolving dependencies between them
<jacobat>
dwradcliffe_: Isn't the lockfile the result of dependency resolution? Why would it need to do it again?
jfoy has joined #bundler
<ddd>
because it verifies those dependencies and versions
<ddd>
not to mention building the list of gems and specific versions to get for its download list (parsing the data out)
<ckrailo>
jacobat: dwradcliffe_: ddd is correct. when you change the Gemfile, you can no longer be sure that the old graph is still the most accurate, up-to-date graph. so the tool will reach out to the sources and rebuild the dependency graph.
<ckrailo>
jacobat: what version of ruby are you rockin'
<ckrailo>
errrr
<ckrailo>
sorry!
<ckrailo>
jrochkind: what version of ruby are you rockin’?
<ckrailo>
jrochkind: found an easy workaround if you dont need rails 4 compat :P
<jacobat>
ckrailo: I'm not sure I understand. I have not changed the Gemfile. A coworker has updated a gem and updated Gemfile.lock. After that point I assume dependencies are resolved.
<jrochkind>
I am using ruby 1.9.3.
<jrochkind>
I found a couple workarounds myself, that I mentioned in the ticket, but more workarounds are always nice, sure. But I'm doing okay at hte moment as far as getting my work done, I was just reporting what seemed to be a bundler bug, cool?
<jrochkind>
it is a bundler bug, right?
chouhoulis has quit [Ping timeout: 272 seconds]
<ddd>
actually its your co-worker short circuiting the expected way of doing it. you don't update a gem and then modify the lock, you have the version in the Gemfile and update the bundle letting bundler do the work
<ddd>
backdooring bundler via Gemfile.lock isn't a bundler bug, its a co-worker bug
<jrochkind>
if you check Gemfile.lock into the repo (which is often a good idea), then every time you make a change to the Gemfile, you should regenerate Gemfile.lock and then commit both new Gemfile and new Gemfile.lock (that's correct, right, bundler folks?). Is that your all's workflow, jacobat?
<ddd>
yes
<jacobat>
jrochkind: I have a Gemfile.lock
<jacobat>
jrochkind: Even if I do "bundle install ; gem uninstall [somegem] ; bundle install" the second bundle install will run for more than a minute
<ddd>
thats the correct way. that allows you to run bundle install, which checks the Gemfile for the gems, the lock file for what versions were installed last time the command was run and then bundler will verify it all
<ddd>
jacobat: that could be affected by everything from --ri --rdoc being enabled, slow network connections to the gem server(s), local processes blocking so bundler has to wait, bunch of things. can you gist a verbose trace so folks can see what's going on?
<jacobat>
ddd: "bundle install --verbose"?
<ddd>
yes (iirc --verbose is positional)
<ddd>
bundle --verbose install
<jacobat>
It's doing 2 http requests for each gem (one redirect, one succesful)
<jacobat>
So it's downloading gemspecs again even though they're already downloaded
<ddd>
because gemspecs can change
<ddd>
the redirs are because the gem servers are actually in a cluster, so its redirecting to one of the servers in the pool
<jacobat>
That explains it
<jacobat>
Sure
<ddd>
adds time for sure, but necessary to the technology
<dwradcliffe_>
redirs shouldn't add much time
<ddd>
its only ms, however yeah they all add up
<jacobat>
It's a lot of ms from across the pond
<ddd>
dwradcliffe_: true
<ddd>
jacobat: thats more because of your routing, not a bundler issue
<ddd>
some countries got crazy routing like south africa
<jacobat>
I don't think Denmark has crazy routing, but it takes a while to get a http request to the US and back
<jacobat>
Pipelined HTTP might make it faster - or multiple requests at once
havenwood has quit [Remote host closed the connection]
<jacobat>
I wonder how big the full gem index is... if it would be possible to have a local cache - including checksums on gemspecs
<ddd>
you'd have to have some backend scheduled runner that would look for invalidated specs/checksums and update accordingly
<jacobat>
Rubygems could just publish a delta to the full index
<ddd>
i could have sworn that was done, but something broke during development so it got placed on hold.
<jacobat>
Of course "just" is probably not that easy with all the platforms needing to be supported
<ddd>
don't hold me to the fire on that, just working off a faulty past memory
<jacobat>
:)
<ddd>
iirc it was for exctly that reason. so many platforms, so many gems constantly being changed (everytime someone submits x.y.z.a) and the turnaround time across all the servers to be updated
<jacobat>
I believe FreeBSD ports has a nice binary delta mechanism for distributing updated to their index
<ddd>
debian does something similar on releases, but they've also made it clear to wait several hours after a release announcement because its automated release. plus the time shift (so pkg A was updated for the release, but say a security update for that new release was just pushed too, so now you have 2 updates to wait for)
<ddd>
pita :)
samphippen has joined #bundler
<ddd>
and open to *lots* of failure points especially if say 4 or 5 servers go offline independently, then come back. now they have to update, and yoiu get routed to one because its closer for your IP pool, etc
<ddd>
not saying thats your issue here (thought we solved the actual reason you were suffering) but i'm sure you can see where it'd create havok for even the best laid plans
<ddd>
oops. gotta go. dogs are at door whining and i prefer my carpets not be yellow :)
<brixen>
indirect: :( :( :( I thought "tomorrow" meant wednesday
<indirect>
brixen: errr... I did mean wedensday?
<brixen>
indirect: oh good!
<indirect>
what happened? haha
<indirect>
I'm PST
<indirect>
so I meant 12:30PM PST on Dec 4 :P
<brixen>
indirect: terrence just pinged me asking how the meeting went
<indirect>
oh lols
<brixen>
so I thought I missed it!
<brixen>
heh
<brixen>
dammit terrence
<brixen>
gave me heart attack
<brixen>
ok, chat tomorrow!
<indirect>
sounds good!
<indirect>
later
<brixen>
later!
chouhoulis has joined #bundler
ixti has joined #bundler
chouhoulis has quit [Remote host closed the connection]
whack has left #bundler [#bundler]
JordanFaust_ has joined #bundler
JordanFaust_ has quit [Client Quit]
havenwood has joined #bundler
<ddd>
brixen: got a sec?
<brixen>
ddd: what's up?
<ddd>
i didn't see an Issue filed (might have been a bad search, idk) but I'm experiencing problems with 2.2 and therubyracer. 2.2 keeps telling me it doesn't like the adapter specification