How to not rely on Rubygems.org for deployment | Hacker News Reader

How to not rely on Rubygems.org for deployment

words.steveklabnik.com

46 pointssteveklabnik17 comments

bundle install has several other useful options too. My favorites:

--local will prevent rubygems.org from being contacted, and will only use previously cached gems

--standalone will package all dependencies into ./bundle, so that you can copy and run it on a server that doesn't even have Bundler

[1] http://gembundler.com/v1.2/bundle_install.html

Steve, could you maybe expand a little bit on your reasons for not wanting to have the gems cached in your repo? Have you run into practical issues (deployment speed, etc.) or is it more of a philosophical thing?

Philosophical, mostly. Any non-philosophical justification I could give you would really be me just porting over my philosophical justification and pretending it's objective.

Example: "I don't want to wait forever while I transfer the extra 38mb over the network." (That's the size of a vendor/bundle for a new Rails app.) I have never actually compared transfer speed in each instance, so that'd just be a backport. ;)

That said, as far as philosophical objections go:

1. Checking in generated files is not best-practice. This feels the same to me.

2. I do a lot of development:

    $ ls src | wc -l
         107

Not all of those are Ruby projects, mind you, but I'm a member of 25 GitHub organizations and have ~100 repos on my personal account. That's a LOT of duplicate gem data.

3. Updating gem files in the repo obscures diffs. If I'm working on a feature branch, and I have 3 commits, and one of them is updating 3 gems, I have a few dozen or hundred files changed. I just want to see my changes, dammit! I guess this one can be construed as practical.

Thanks, those are all fair points.

The reason I went with "vendor everything" several years ago was that I had to make some changes to a legacy codebase and discovered that one of the gems it depended on was no longer available. It wasn't the end of the world to refactor around it, but it motivated me to find a way to ensure I would always have a local copy of all the dependencies for each app.

Someone in the comments of the rubygems.org story yesterday mentioned using a submodule for vendor/cache which seems like an interesting idea to me. That could at least partially address #3.

Thanks for this post Steve. We're not too far from deployment and the recent issues have us slightly wigged out.

On the plus side, we can make the security revs before going live.

Any time. Everyone's a bit testy right now. I can barely stand about half of my Twitter feed.

In addition (and i think this is actually more important) you could use a rubygems.org proxy cache (similar to http://blog.sprout-technology.com/setting-up-rubygems-proxy-...)

Title is somewhat false, since you still rely on rubygems for deployment. It's just that you cache bundled gems and don't have to hit rubygems unless really needed.

Also noteworthy: described bundler usage is the default behavior of capistrano bundler recipe.

> Title is somewhat false, since you still rely on rubygems for deployment.

Under normal circumstances, you do not hit Rubygems.org at all. If your cache is out of date, bundler will automatically hit Rubygems.org for you, but you can also update the cache from your locally installed gems, and then it won't. Which means no, you do not hit Rubygems.org while deploying.

If you can deploy while Rubygems.org is down, that's 'not relying on Rubygems.org' in my book.

    > Also noteworthy: described bundler usage is the default behavior of capistrano bundler recipe.

Thank you for confirming. I haven't used cap in a few years, and I thought so, but I didn't check yet.

Looking at the long, long list of Gems required by Rails these days, makes it look less like a framework, and more like a patchwork. Complete with holes of course.

This kind of snark is not very constructive. I see your account is two days old, and it's basically done nothing but talk shit on Rails.

Whilst correct that my account is recent, I don't think the comments are really 'talk shit on Rails' - rather they point out the numerous serious security issues with Rails, Ruby Yaml libraries, and ecosystem in general have forced our hand to migrate away from Ruby onto pastures new.

We actually have been using Rails internally and externally since 0.13, followed it through the Engines clash, watched the Github hack, and have been caught up like everyone else in the rapid update cycles due to the security issues. But there comes a time to sit back, consider if software engineering are two dirty words in the Ruby community, and move on.

EDIT: Nevermind, Rule #1 of the internet, don't feed the trolls.

Is Troll Ruby slang for someone who just got fed up being called into IT Security meetings to report on yet another urgent change to Prod being required because, the Ruby guys just love sticking Yaml parsers in wherever they can, and the world now knows about it, and we have to leap into action yet again?

Ever tried to install a semi-decent framework from cabal or maven?

Forget the framework ... maven itself will download all kinds of plugins and deployment tools before even downloading the framework.

I've never before seen a build tool hit so many servers before even doing real work -- until maven.

My personal maven moment was when I did a "mvn clean" on a train ride - and it failed, because it had to lazy-load 'mvn-clean-plugin' (5kb).

Reply on news.ycombinator.com