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