Freezing gems when dev OS != prod OS


#1

My question arises from the fact that I’m developing on Windows but, in
the short term, deploying to a shared, Linux-based host. I’m developing
on Windows because that’s where the app will eventually be installed.
But in the short-term I’d like to protect my demos from any unfortold
mods to the deployment environment. So I figured I’d freeze gems /
rails. But then I realized I’ve got a bunch of MS-specific gems on my
dev box. Same gems as on the Linux box, but Windows versions. (e.g.
hpricot-0.6.164-x86-mswin32). I’d really appreciate some advice re: how
to safely go about freezing things appropriately in this situation.

TIA,
Bill


#2

On Thu, Oct 30, 2008 at 6:48 PM, Bill W. removed_email_address@domain.invalid
wrote:

My question arises from the fact that I’m developing on Windows but, in the
short term, deploying to a shared, Linux-based host. I’m developing on
Windows because that’s where the app will eventually be installed. But in
the short-term I’d like to protect my demos from any unfortold mods to the
deployment environment. So I figured I’d freeze gems / rails. But then I
realized I’ve got a bunch of MS-specific gems on my dev box. Same gems as
on the Linux box, but Windows versions. (e.g. hpricot-0.6.164-x86-mswin32).
I’d really appreciate some advice re: how to safely go about freezing things
appropriately in this situation.

Gems that requires compilation of native extensions (hpricot, rcov and
others) cannot be frozen and will require you ask your hosting company
to install it for you or you can:

build the gem and install it locally ~/.gems/ruby/1.8

then in your application, include that location in your GEM_PATH.

Is complicated stuff, which most should not be dealing with. Users
from other platforms are affected by this too.

HTH,

Luis L.
AREA 17

Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams