<mrphs>
I'm confident git:// doesn't use SSL. and https://github... does.
<mrphs>
git@github is ssh but https is faster than ssh. so there's that too.
* mrphs
goes to read the comments on the pr
woollyams has quit [Ping timeout: 252 seconds]
houhoulis has quit [Remote host closed the connection]
<pipework>
mrphs: It's not backwards compatible, so you'll have to wait until another breaking change release, a major version increment.
jaimef has quit [Excess Flood]
<mrphs>
would you help me understand what do you mean by backwards compatible?
<mrphs>
what does it break?
<mrphs>
pipework: ^
<pipework>
mrphs: Did you read the pull request comments?
<mrphs>
yes
<mrphs>
I also read #2569 and #1820
<mrphs>
I've never seen a firewall block github https connection.
<mrphs>
maybe in china or iran where everything is blocked :P
indirect has quit [Ping timeout: 246 seconds]
indirect has joined #bundler
jaimef has joined #bundler
<indirect>
mrphs: I'm not talking about a network firewall, I'm talking about datacenter production deployment firewalls :\
<indirect>
I seriously would like this to be the default
<indirect>
but I've promised that Bundler will not break existing gemfiles in new releases, period
<pipework>
mrphs: It's a technical violation of 'backwards compatible change' at least. It'll wait because indirect is a good person
<indirect>
so I can't do that
<indirect>
if zero people had reported that the change broke their gemfile, I wouldn't have reverted it in the first place :(
<pipework>
indirect: Where's the adventure in your life? Needs more yolo. (sorry)
<indirect>
lollll
<indirect>
rubygems has more yolo than I need
<indirect>
Bundler with no yolo is fine with me
woollyams has joined #bundler
<pipework>
I'm doing my ginger best to get rubygems.org running on ruby 2.1. It's probably the most boring thing I've done this year.
<mrphs>
okay, I've a question: does your ruby need to have openssl to be able to clone https://github...? I guess not, that's git job and you already have it installed. right? or maybe I'm making a terrible mistake here.
<mrphs>
and sorry if I'm asking ignorant questions, or if I'm being persistent. I don't know ruby/gem much. but I understand firewalls and encryption.
<pipework>
mrphs: Well, in terms of software versioning, it's a change that breaks existing functionality, regardless of how transparent it's perceived to be. indirect seems to have a lot of context on trying your suggestion and found that it wasn't a drop-in change that didn't cause problems So he's putting it off until later. I think you're just curious about why it
<pipework>
wasn't a drop-in change that didn't break things though, is that right?
<mrphs>
yep
<mrphs>
maybe that'd convince me, if you could share a case scenario where things may break w/ this change, not only I'd make less noise, I'd also learn something here.
<pipework>
mrphs: I think your noise is appreciated, but the timing could be better, if I might speak for a group I don't really belong to.
<indirect>
pipework: ruby 2.1 ships with rubygems 2.2, which means it breaks backwards compatibility with C extensions and isn't able to install rspec3 or metric_fu via `gem install`. :\
<indirect>
mrphs: ruby doesn't need openssl to clone https urls, but if openssl isn't compiled in to ruby, chances seem good it's not compiled into git either?
<pipework>
indirect: Screw you man, I just laughed out loud and woke my SO.
<indirect>
I didn't personally observe gemfiles breaking
<indirect>
pipework: lol. did I mention it also breaks compat with ruby 1.8?
<indirect>
(officially 1.8 is still supported, but it doesn't work)
<pipework>
indirect: rubygems 2.2, or ruby 2.1?
<pipework>
Because for the latter I spent probably 15 minutes laughing while having a conniption fit simultaneously. It was a very confusing quarter hour.
<indirect>
mrphs: I've already released your patch, and people reported it not working specifically because of that patch. I reverting made it work again. I don't know how to make it clearer than that without doing a ton of work myself to figure out the precise technical details, and I don't have time to find them right now, sorry
<indirect>
pipework: rubygems 2.2 breaks compat with ruby 1.8
<indirect>
as well as being unable to install some gems
retro|cz has joined #bundler
<indirect>
as well as moving C exts to a new location and not looking in the old one
<indirect>
so all exts installed by rubygems 2.1 and bundler are ignored by 2.2
<pipework>
indirect: It's like semver never even happened.
<indirect>
it didn't
<indirect>
rubygems doesn't do semver
<pipework>
Clearly.
<indirect>
according to a ticket in the bundler tracker, rubygems is going to drop runtime-recompilation of missing extensions in a bugfix release
<indirect>
full breaking compat on the c exts
<indirect>
er, fully breaking
<pipework>
indirect: I didn't even know it did that. :s
<indirect>
so keep an eye out for 2.2.4 or 5!
<indirect>
that's how it's "backwards compatible" with 2.1 and bundler
<indirect>
it tries to build new exts at require-time if they aren't present in the new location
<indirect>
instead of falling back to the old location. or copying them from the old location.
<indirect>
where they are, you know, already built. successfully.
<indirect>
and as you might guess
<indirect>
require-time compilation has... issues
<indirect>
which is why they're going to disable it!
<indirect>
helpfully
<indirect>
to fix the bug of exts that don't compile
<indirect>
then you'll just get a require error
<pipework>
indirect: If you need a shoulder to cry/laugh/rage on, I'm here, but I'll have you know that you're bringing me down man.
<indirect>
as a testament to the new close ties between the rubygems and bundler team, rubygems is waiting until bundler knows to build the exts into the new location before that bugfix release that breaks backwards compat 100%
<pipework>
indirect: How does one recompile the extensions otherwise?
<pipework>
Please forgive my ignorance.
<indirect>
gem pristine
<indirect>
--all presumably
<pipework>
oh.
<indirect>
at least then you have control over the build environment
<indirect>
which is usually how you were able to build in the first place
<pipework>
That'll take me... (carry the three, multiplied by the force of a falling macbook from 13 stories...) forever.
<indirect>
I assume you could manually copy the files
<indirect>
if you figure out the directories in question
<indirect>
I wonder if bundler should just create symlinks
<indirect>
lol
<indirect>
I haven't "fixed compatibility" yet
<indirect>
incidentally, you probably wouldn't believe the amount of shit bundler gets for not working with the latest rubygems
<indirect>
no matter what they change in a minor or bugfix
<indirect>
lolsigh
<mrphs>
indirect: Okay, I'll move it to bundler 2 branch. And I'm sorry for bugging you about this, but is there any ticket for those complains? I'd like to do more investigation on this issue...
<mrphs>
indirect: and for the record, I'm confident git has been supporting ssl for a very very long time now.
<pipework>
indirect: If I were half as clever as I'd like to be, I'd lend some kind of help, but I'm somewhat daunted by bundler, though I fiddle with my own clone.
<pipework>
mrphs: Git has, the git protocol hasn't.
angerman has joined #bundler
<pipework>
mrphs: He's said he doesn't really have the data to explain the situation as well. You might peruse the closed issues on github.
<indirect>
mrphs: ruby likewise has supported ssl for a very long time. but anytime bundler requires that openssl be present, tons of people file reports that it has stopped working with their ruby, because it's not compiled in
<indirect>
pipework: fwiw, we have put a lot of work into making it easy to get started working on bundler
<indirect>
pipework: you can fix typos in the docs and we'll be super excited ;)
<pipework>
indirect: Even though I seemingly know what I'm doing, large projects are intimidating and no one seems to like pairing to get people introduced and comfortable.
<pipework>
indirect: I'm always happy to contribute documentation, especially the non-wiki kind.
<indirect>
mrphs: thanks, that sounds good. I think it's already changed there? but it may not be merged
<indirect>
pipework: if it helps, the bundler contributing doc explicitly offers to schedule pairing times with new contributors, and I've done that successfully with a handful of current bundler contributors so far :)
<indirect>
pipework: we have a fancy website: bundler.io
<pipework>
indirect: Oh yeah? I'll give that a read and see if I can snag some time to get familiar with bundler through pairing.
<pipework>
Quite the fancy thing.
patcon has joined #bundler
<indirect>
:D
<pipework>
indirect: Whoa, I'm allowed to refactor code as the sole thing I do in pull requests? :D
<indirect>
:D
<indirect>
make it less horrible, the specs pass,
<pipework>
I'm pretty used to that, plus refactoring is super fun. Not to be a bother and take more of your time, but I'm rather passionate and people say I'm more than proficient in testing, would that be at all useful? I love refactoring tests as well as teasing them apart or writing them. I just love tests.
patcon has quit [Ping timeout: 264 seconds]
<pipework>
indirect: ^
mrphs has left #bundler [#bundler]
<indirect>
pipework: that would be awesome
<indirect>
our tests are super sad
<indirect>
because they've been around for years and mostly just superficially upgraded to rspec3
<indirect>
and they are almost all integration tests
<indirect>
which makes the suite slow, albeit reliable
<pipework>
indirect: I shall put my efforts into the tests first and refactoring when I get the tests merged, as I trust the bundler team to have better understanding as to whether the tests I write are reasonable. This is super exciting!
havenwood has quit [Remote host closed the connection]
havenwood has joined #bundler
havenwood has quit [Ping timeout: 264 seconds]
flowerha_ has quit [Remote host closed the connection]
davidcollom_ is now known as davidcollom
<pipework>
indirect: I have a stupid question.
<pipework>
Why are bundler's methods not scoped at all?
<pipework>
Or at least, why are they not scoped more tightly?
<indirect>
pipework: which methods, and scoped how?
<indirect>
heh
<pipework>
indirect: Like 'gem' at least. It's available everywhere, and I wasn't sure if that was something that was desired, or how it came about.
<pipework>
I'd imagine that perhaps constraining it to Gemfiles which are read in and evaluated within an instance_eval of some class that has those methods implemented wasn't sufficient?
<pipework>
indirect: While still making any 'api' methods available in a mixin that could be mixed into whatever scope to maintain backwards compatibility until a time may present itself where it could be optional but not default.
<indirect>
pipework: oh, you mean the Gemfile DSL?
<indirect>
it's evaled directly inside an instance of Bundler::DSL
<pipework>
indirect: Yeah. Sorry, I don't know the extent of what's available.
<indirect>
so they're not scoped because it should be as easy to declare gems in your app as it was using rubygems
<pipework>
indirect: Ah, so I suppose I should track down what #gem is everywhere else?
<indirect>
which actually creates a kernel method named #gem
<pipework>
Oh I see.
<indirect>
sooo we actually scoped it all the way down to only the Gemfile
<pipework>
Oh that's good! I was super confused for a bit, but didn't poke hard enough to figure that out, sorry.
<indirect>
whereas there are gems (rails -_-) that just call `gem 'pg', '~> whatever'` directly before they do stuff
<indirect>
haha no worries
<pipework>
yeah, that's what I see a lot of and it made me think, "surely those bundler bruvs reign things in better than that."
angerman has quit [Read error: Connection reset by peer]
angerman has joined #bundler
havenwood has joined #bundler
angerman has quit [Read error: Connection reset by peer]
angerman has joined #bundler
lele` has joined #bundler
lele` is now known as lele
angerman has quit [Read error: Connection reset by peer]
woollyams has quit [Ping timeout: 252 seconds]
woollyams has joined #bundler
angerman has joined #bundler
angerman has quit [Read error: Connection reset by peer]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
samphippen has joined #bundler
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
robbyoconnor has quit [Ping timeout: 246 seconds]
havenwood has quit [Remote host closed the connection]
havenwood has joined #bundler
havenwood has quit [Ping timeout: 342 seconds]
omegahm has quit [Ping timeout: 264 seconds]
<lele>
Hello, I might use some help with this: http://hastebin.com/mikaqemetu.vhdl . Is this even supposed to work, or am I failing to understand something fundamental?
<tmoore>
I think that's a bug
<lele>
There was an issue about something related, but it was closed long ago
<lele>
sure, just wanted to be sure it wasn't a PEBKAC. Anyways, even running package -all N times, doesn't change the outcome.
angerman has joined #bundler
havenwood has joined #bundler
<tmoore>
oh hmm
<tmoore>
well maybe the behaviour changed in 1.5
havenwood has quit [Ping timeout: 245 seconds]
lele has quit [Ping timeout: 245 seconds]
lele has joined #bundler
robbyoconnor has joined #bundler
ohwhoa has joined #bundler
robbyoconnor has quit [Ping timeout: 244 seconds]
robbyoconnor has joined #bundler
havenwood has joined #bundler
havenwood has quit [Ping timeout: 272 seconds]
lele has quit [Ping timeout: 246 seconds]
angerman has quit [Write error: Connection reset by peer]
lele has joined #bundler
havenwood has joined #bundler
lele has quit [Ping timeout: 246 seconds]
havenwood has quit [Ping timeout: 272 seconds]
omegahm has joined #bundler
samphippen has joined #bundler
lele has joined #bundler
ixti has quit [Ping timeout: 272 seconds]
davidcollom is now known as davidcollom_afk
angerman has joined #bundler
davidcollom_afk is now known as davidcollom
cha1tanya has quit [Ping timeout: 246 seconds]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ohwhoa has quit [Quit: woah!]
havenwood has joined #bundler
robbyoconnor has quit [Ping timeout: 272 seconds]
angerman has quit [Read error: Connection reset by peer]
havenwood has quit [Ping timeout: 246 seconds]
angerman has joined #bundler
samphippen has joined #bundler
davidcollom is now known as davidcollom_afk
davidcollom_afk is now known as davidcollom_afk_
axl_ has joined #bundler
havenwood has joined #bundler
angerman has quit [Read error: Connection reset by peer]
havenwood has quit [Ping timeout: 264 seconds]
davidcollom_afk_ is now known as davidcollom
angerman has joined #bundler
ixti has joined #bundler
angerman has quit [Read error: Connection reset by peer]
lele has quit [Ping timeout: 246 seconds]
angerman has joined #bundler
davidcollom is now known as davidcollom_
cha1tanya has joined #bundler
angerman has quit [Read error: Connection reset by peer]
angerman has joined #bundler
axl_ has quit [Quit: axl_]
havenwood has joined #bundler
havenwood has quit [Ping timeout: 246 seconds]
havenwood has joined #bundler
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
angerman has quit [Read error: Connection reset by peer]
davidcollom_ is now known as davidcollom
angerman has joined #bundler
axl_ has joined #bundler
robbyoconnor has joined #bundler
samphippen has joined #bundler
mjc__ is now known as mjc_
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
axl_ has quit [Read error: Connection reset by peer]
davidcollom is now known as davidcollom_
mfoo has joined #bundler
axl_ has joined #bundler
cwebber has joined #bundler
davidcollom_ is now known as davidcollom
axl_ has quit [Ping timeout: 246 seconds]
robbyoconnor has quit [Ping timeout: 272 seconds]
havenwood has quit [Remote host closed the connection]
havenwood has joined #bundler
<mfoo>
Hi, does anybody have a good solution to using a different gem server in production to development? Development machines cannot access the production gemserver and production servers have no outgoing internet access. (dwradcliffe you might recall we had a chat about this in early December)
<dwradcliffe>
mfoo: I vaguely remember :)
<mfoo>
iirc we pretty much settled on conditional evaluation in the Gemfile
<mfoo>
I was wondering if anything changed
havenwood has quit [Ping timeout: 244 seconds]
havenwood has joined #bundler
samphippen has joined #bundler
angerman has quit [Read error: Connection reset by peer]
angerman has joined #bundler
patcon has joined #bundler
<dwradcliffe>
mfoo: not that I'm aware of, but seems like indirect was working on something for that so maybe it's been released by now?
<mfoo>
ah, the bundle config mirror setting
<dwradcliffe>
ah yes, that's it
<dwradcliffe>
will that work for what you need?
<mfoo>
it's likely, I just need to find some documentation or the source for it
patcon has quit [Remote host closed the connection]
<mfoo>
yep, looks like I can just drop $app/.bundle/config in with puppet
<mfoo>
indirect, dwradcliffe cheers
<mfoo>
I did some grepping of the chat logs from a while back but didn't see that ^
robbyoconnor has joined #bundler
axl_ has joined #bundler
patcon has joined #bundler
axl_ has quit [Quit: axl_]
davidcollom is now known as davidcollom_
axl_ has joined #bundler
angerman has quit [Quit: Gone]
Jeff_D has joined #bundler
<Jeff_D>
When building a Gem, how can I specify a dependency in the .gemspec that needs to be pulled from another source (in this case, rails-assets.org)?
<ddd>
iirc oyu can specify it if it uses git
<Jeff_D>
ddd: what I want to do is name a gem in the .gemspec file that needs to be pulled from a source *other than* rubygems.org (in this case, rails-assets.org). If I have rails-assets.org in the Gemfile and I add s.add_dependency 'rails-assets-sugar' to the .gemspec, `rake build` fails, saying it can't find the `rails-assets-sugar` gem in any of its sources.
<ddd>
i don't believe you can. lookoing through the docs and seeing absolutely nothing. You can add it to the Gemfile and have it work but it *must* be a git repo for the external
<Jeff_D>
well, that sucks with an absolutely perfect vacuum. Thanks very much for trying.
<Jeff_D>
so people who use private repos like Gemfury are SOL as well, it seems. That's bad
<dwradcliffe>
Jeff_D: you should still be able to list the requirements in the .gemspec
<dwradcliffe>
We do that for all our internal gems
patcon has quit [Read error: Connection reset by peer]
<Jeff_D>
dwradcliffe: by specifying a URL to the Git repo, you mean?
patcon has joined #bundler
patcon has quit [Remote host closed the connection]
<ddd>
the Gemfile will contain the location info, but the gemspec itself can not. you list the dep oin the gemspec, and the Gemfile fulfils the location info
<dwradcliffe>
the end user Gemfile must contain the source/server, while the gemspec contains the gem name/version requirement
<ddd>
right
<dwradcliffe>
so Jeff_D, you can list the requirements, and instruct users to add the source to their Gemfile
<ddd>
and don't think I'm saying run a private gem server. I gave the URL so you can see what I was talking about
<Jeff_D>
dwradcliffe: ack! Now I understand… this is going to take more brain cells to solve thank I can muster at 2.10 AM. It looks like I'm going to have to do that; instruct users to add magic to their Gemfile to cover for not being able to specify what we really need in the .gemspec. Ick. But now I've an answer, at least
<ddd>
he wouldn't have to tell them to do that. he can list the dep in the gemspec, and the location info for the dep in the Gemfile. the Gemfile will be read, the gem name pulled and its location data, and when it hits the 'gemspec' call it will fulfil the dep using the data at the location specified in the Gemfile
<dwradcliffe>
gem install doesn't look at the gem's source Gemfile
<ddd>
no but he's using bundler, and bundler does. you don't need bundler at all if all you're doing is writing a gem
<Jeff_D>
really??
<ddd>
write your gemspec by hand and gem build
<ddd>
gem help build
<ddd>
but again, you can NOT specify a separate location in the gemspec. you would HAVE to do that in the Gemfile which then, of course, requires bundler
<Jeff_D>
right, so I'm back to bundler anyway.
<dwradcliffe>
ddd: only in the Gemfile of the end user
<ddd>
or in the Gemfile included in the gem itself, then letting the end user build using your specified data. :shrug:
robbyoconnor has quit [Ping timeout: 264 seconds]
omegahm has quit [Excess Flood]
<dwradcliffe>
how do you reference a Gemfile from a gemspec? I must be missing something
<Jeff_D>
OK, now maybe(!) I'm confused here, but that johnpwood.net post talks about using different sources from an app, where you've published your Gems to that other source. But what if those Gems have dependencies on other Gems not in rubygems.org? That's where I'm falling over
<ddd>
no no, its reversed. you add the Gemfile using .add_file and put 'gemspec' as the last line in the Gemfile. the gem, when built, would then include the Gemfile and they could then build with bundler
ohcibi has quit [Excess Flood]
<dwradcliffe>
only from that project. if you're including the gem from another project it only looks at the gemspec, not the Gemfile that's inside the gem (right?)
<ddd>
jeff_d you would have to list the dep yourself, and include the location data in the Gemfile. you're doing a 'non-standard' thing. so you would basically have to use bundler in order to use Gemfile to specify the location for those other dependency gems which bundler would use when it encountered the dep in the gemspec.
<Jeff_D>
Got it, guys; thanks!!!
<ddd>
its sort of a round robin
<ddd>
gem by itself can't do what you want
<Jeff_D>
the key was to add BOTH a 'source' directive and a 'gem' entry in the Gemfile *before* the `gem spec` directive. Then all is well
axl_ has quit [Ping timeout: 279 seconds]
<ddd>
right, which is why i was telling you to put the gemspec directive as the last line
<dwradcliffe>
Jeff_D: is your code public? (I'm curious)
retro_ has joined #bundler
<Jeff_D>
This is of a throwaway POC demo at the moment; I'm putting up a Gist now