FUDCon:Milan 2011 - Ruby SIG meeting

Hugh Brock hbrock at redhat.com
Fri Sep 23 13:57:11 UTC 2011

On Fri, Sep 23, 2011 at 09:56:57AM +0200, Emanuel Rietveld wrote:
> On 09/22/2011 07:52 PM, Hugh Brock wrote:
> > On Thu, Sep 22, 2011 at 01:37:33PM -0400, Darryl L. Pierce wrote:
> >> On Wed, Sep 21, 2011 at 03:02:10PM -0400, Mo Morsi wrote:
> >>>> This is a small part of what I mention above. One of the things we
> >>>> discussed was a complete separation of things like specific versions of
> >>>> Rails (and other gems) from version of Fedora. IOW, why should F14 be
> >>>> Rails 3.1? Why not let us run Fedora 17 with whatever version of Rails
> >>>> we choose?
> >>>>
> >>> Not sure if I'm following, you can always gem install any version of any 
> >>> gem you choose. We are talking about the single supported stack in Fedora.
> >> I'm talking about completely separating Ruby gems from Fedora. So, for
> >> example, installing Fedora XX won't require rubygem-rails yy.xx.
> >> Insteadl, _all_ Ruby gems would be kept in a separate, optional yum
> >> repository. Then you could maintain the gems separately.
> >>
> >> So if you're app requires Rails 2.3.11 and farkle 3.1, even though those
> >> aren't the latest, then you could install them without having to hunt
> >> down, grab and install the RPMs (and then do the same for all
> >> dependencies) manually. The one repositoryw ould have 2.3.8, 2.3.11,
> >> 3.0.0, 3.1.0, etc. and all dependent versions available.
> > This is probably going to give fedora packagers massive heartburn, but
> > I think Darryl is on the right track here.
> >
> > To really make this work you also need a way to install multiple
> > stacks of gems on the same machine. So I need for example to be able
> > to have two different Rails apps installed, each of which may depend
> > on different and conflicting package sets, and have everything work
> > and be happy. As horrible as this is from a support standpoint, it is
> > the way the Ruby world works, and trying to get away from it is
> > swimming upstream...
> >
> > /me ducks large rocks
> >
> > --Hugh
> >
> Perhaps we can make something like rvm (or the more recent rbenv - which
> does seem simpler and more robust) central to the Fedora ruby strategy.
> They allow you to install multiple ruby versions with multiple gem
> stacks concurrently, and decide on a per-application basis what ruby
> stack to use. It would be good it if it was easy for Fedora users to
> install rvm/rbenv and multiple versions of ruby and rails via rpm and
> have it all work out of the box.
> On the other hand, it may be worth going to great lengths to ensure we
> have a single well-supported stack in that works with all the ruby
> applications we package for Fedora. Perhaps we need to make one official
> Fedora-supported stack and meanwhile make it as easy as possible to
> install additional ruby versions + gemstacks concurrently, say, from
> third party repos.

Yes... the problem with RVM of course is that from a production
support standpoint it is a living horror:

"What Ruby interpreter are you using?"

"Hmm... let me just see if I can figure out what that environment
variable was set to the last time the bug happened..."

Endorsing RVM as a winning strategy in Fedora is ultimately just
enabling bad practice. "Moment-of-pleasure-for-lifetime-of-pain" type
of thing.

Having said that, *trying* to get to a single well-supported stack has
been so expensive and painful for us that I'm about ready to give
up. I'm really not even sure it's possible. So the notion of having an
"official" stack but also enabling apps to have their own stacks, as
horrible as that is, may be the only sensible solution in the end.

/me contemplates rewriting everything in C...


== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey

More information about the ruby-sig mailing list