Hacker News Reader

Comment by mildavw | Hacker News Reader

Survey: Do you depend on RubyGems for every deploy? Or do you have your own gem server? Or cache them at some point earlier in your pipeline?

We rely on RubyGems and had a meeting yesterday about changing that when one of the gems we use had a version just disappear.

View on HN

I was looking for a RubyGems proxy a couple of weeks ago but was unable to find anything suitable. What I would like to find is something similar to Artifactory for Maven. You include the proxy in your Gemfile and if it doesn't have the Gem it downloads it from RubyGems and caches it locally.

This type of proxy wouldn't help in this particular case but it would allow you to keep traffic to RubyGems.org down and also give you the ability to easily host private Gems.

I, too, would love something like this.

You're probably aware, but it's possible to host private gems in a simple static webserver. We have our CI server copy gems over and run a script that calls "gem generate_index -d /path/to/gems".

Completely featureless, of course. Lacks the newer rubygems.org api (so bundler is stuck downloading the whole index), and obsolete versions will stick around without manual intervention (which, if you have too many, is a pathological case for bundler's resolver).

If you use bundler, "bundle package" can help reduce or eliminate your dependency on external gem repositories. At least for deployments.

I generally try to follow the "vendor everything" philosophy: http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-a...

I couldn't get through this whole article due to the dude in the corner staring at me... :-/

Not that this line of discussion is particularly constructive, but I agree. I'm not sure why someone would think a giant head staring at the reader is a good idea, but it's not.

On a 27" monitor, it's almost like a child sized head right up in your face. I can only imagine it being even worse on bigger screens.

    document.getElementById('mugshot').remove()

We treated .gems like source tarballs (they can't even express non-Ruby dependencies, Gem::Specification#requirements are treated as comments), and only used rubygems.org for newer versions of our dependencies to be packaged as .rpms for test and production deployments. I found that to be much more sane than bypassing the system package manager and smuggling random crap onto dev servers, much less production.

Gems get yanked. Its a danger of this approach.

And stuff get yanked for good reasons.

Reply on news.ycombinator.com