How to not rely on Rubygems.org for deployment

http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg-for-deployment

by steveklabnik • 13 years ago

46 17 13 years ago

words.steveklabnik.com

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.

steveklabnik5• 13 years ago

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.

static_typed3• 13 years ago

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.

Argorak2• 13 years ago

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

X-Istence• 13 years ago

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.

xentronium• 13 years ago

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.

steveklabnik5• 13 years ago

> 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.

jpdoctor• 13 years ago

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.

steveklabnik5• 13 years ago

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

scotje2• 13 years ago

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?

steveklabnik5• 13 years ago

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.

scotje2• 13 years ago

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.

msmith• 13 years ago

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

brugidou• 13 years ago

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-...)

How to not rely on Rubygems.org for deployment

Related Stories