Do we have stats on how many people use the various rubygem rpms / How can we better package rails apps?

[Chris Lalancette]

On 09/23/11 - 03:03:16PM, Tejas Dinkar wrote:
> Hey all,
> 
> I'm wondering if we had any stats on usage patterns for various rubygem
> rpms.
> 
> I've been developing and deploying rails apps for a while, and here is the
> usage patterns that I typically see:
> 
> Fact 1: The ruby world evolves (and often breaks APIs) very quickly. RSpec
> 1.x is totally different from RSpec 2.x. Thus, people tend to keep hard
> dependencies on the "~> x.y" version of a gem, which may not be what another
> project needs.

Yeah, this is exactly the problem that has prompted some of the previous
threads.  It is more-or-less impossible to create a single well-supported
stack because the APIs break all of the time.

> 
> Pattern 1: Because of the above, all developers tend to just use the 'gem'
> command to maintain their gem stack. Add rvm and rbenv to the mix, which
> most developers have adopted. Now, the question becomes the following: "What
> does gem provide that rpm doesn't?", and the answer I came up with is the
> following:
> * Ability to install multiple versions of a gem at the same and let
> bundler/3rd party choose what it needs
> * Compile a gem that isn't available by default

The second one isn't really all that compelling, in my mind.  It is the first
one that allows the ruby community to get away with not caring about backwards
compatibility at all.

> 
> Pattern 2: Some people use gem to install even on production. As you can
> imagine, this is frowned upon because it requires a compiler, and hard to
> manage native dependencies. This is considered an anti pattern.

Yeah, agreed.

> 
> Pattern 3: What people have started doing is to do a bundle deploy
> --deployment, which creates a local copy of all gems. After running this on
> a deployment-like machine, i just tar/rpm up the whole folder, and drop it
> in production. AFAIK, this is considered the best practice
> 
> Practical Question 1: Fedora has a policy that if x depends on y, then x and
> y must be packaged separately, and then both approved in the repo. Now if z
> also depends on y, then we have a general nightmare all round. I was
> wondering if it makes sense, knowing this, to package rails apps as per
> pattern 3, keeping a local app specific copy of all gems (given, of course,
> that all gems meet Fedora's license policies). I know this doesn't make that
> much sense for (say) Ruby-Qt apps, but at least it will help package things
> like redmine for fedora.

The problem comes in with security updates.  What happens when package foo
has a CVE, and 10 packages have it bundled?  You need to first *realize* that
all 10 packages have it bundled, and then update all 10 of them.  It quickly
becomes a nightmare.

> 
> Practical Question 2: Does it make sense to integrate more closely with gem?
> I'm not sure what i mean, i'm just tossing it out there. Is there something
> that we can do to get some of the benefits i mentioned in Pattern 1 in an
> easy way?

Yeah, this is one possible way to think about things.  I worry though that it
is a significant effort, if not outright impossible.  But it probably bears
looking at.

-- 
Chris Lalancette