
How to not rely on Rubygems.org for deployment - steveklabnik
http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg-for-deployment
======
msmith
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>

------
scotje
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?

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

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

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

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

------
brugidou
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-...](http://blog.sprout-
technology.com/setting-up-rubygems-proxy-on-local-server/))

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

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

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

~~~
steveklabnik
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_typed
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.

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

~~~
static_typed
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?

