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.