[ale] Fedora grousing

[Derek Atkins]

JD <jdp at algoloma.com> writes:

>>> Use rvm or rbenv to keep ruby app dependencies
>>> self-contained. NEVER use the OS
>>> ruby, gem, rails - NEVER.
>> 
>> Unfortunately this does not always work well.  When you create a new
>> rails app ("rails new", IIRC -- it's been over a year) -- it tries to do
>> a "bundle install" which will pull down new gems... which is really hard
>> to back out.
>
> If you are inside an rvm environment, the Rails version, which is key in the
> Gemfile, should force compatible gems most of the time. I see versions specified
> in the default Gemfiles here. Any incompatible gems will cause an error that
> begs to have a version entered back into the project Gemfile.
>
> Lots of Rails devs develope on older Rails/Ruby versions.

Yes, once you have an app created and configured it will stabilize on
those versions; using rvm and gemsets will let you keep all developers
on the same environment, too.  It absolutely works then.

However, it's literally the "inital creation" that will pull down
"current" gems, and I haven't figured out a way around that.  This
happens because there is no "Gemfile.lock" file to specify exact
versions, so when rails creates this via "bundle install" it will run
"gem install" for all the gems in the Gemfile list.  IIRC this all
happens even before you have the chance to manually put specific version
numbers into the Gemfile.

Last time I tried this (6+ months ago) using an rvm environment it wound
up pulling a bunch of new gems into my gemset and I never got a working
environment with the new app.  The only way I was able to get it working
was to start a completely fresh gemset and let "rails new" do its magic;
then I could stabilize on that environment.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available