Installation of Rails without 'gem install rails'

I am wondering if anyone has any procedural documentation for installing
and using Rails from the standalone packages rather then via ‘gem
install’. It seems there should be some steps outside of simply
unpacking the tar ball in order to integate it with your Ruby
installation. Seems every bit of installation documentation I can find
has ‘gem install rails’ as the step for deploying Rails.

Thanks,
Devin Kramer

there isn’t much to document. once you untar the standalone package,
all the rails stuff is included in /vendor/rails. if you want to
install all the components, you can go into each directory and run
the setup.rb or install.rb scripts. each comes with a readme, so you
might want to take a look.

-tak.

I won’t say it can’t be done, because of course it can :slight_smile: … but if
you’re
going to drink the cool aid, you need to get and use gems (or live with
svn
and edge)

My desktops are all Debian … and when I first wanted to play, I do
what
all good deb heads do “apt-get install rails” … well it worked, but
then
when you want to anything the least bit interesting and there isn’t a
deb
package but a gem … getting them to talk to each other is a pain.

Then I stumbled upon some huge religeous fight about using gems within
debian, because it’s “not the Debian way” … which is a really annoying
part of the Debian community.

So I installed gems from rubyforge and do all my rails stuff via ‘gem
install’ … it makes my rails world a happier place.

Finally as you’ve already found, all the docs and troubleshooting
advice,
make the fundemental assumption that you’re using gems or svn … it’s
the
way this part of the world works … I found it easier to adopt the
system
than fight it.

On Thu, Apr 13, 2006 at 11:17:17AM -0500, Hank M. wrote:

install’ … it makes my rails world a happier place.
I don’t know if you’ve seen this yet, or installed rubygems by hand to
get the gems, but I stumbled across a .deb of rubygems and so have a
“mostly the debian way” setup here… Relevant lines of sources.list
are:

Daigo M.'s ruby & other packages

deb http://www.sgtpepper.net/hyspro/deb unstable/
deb-src http://www.sgtpepper.net/hyspro/deb unstable/

It looks like Daigo M.'s a debian maintaner for several
packages, and he maintains this additional archive, too.


Michael A. Gurski (opt. [first].)[last]@pobox.com
http://www.pobox.com/~[last]
1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7 17 57 1E 4E 62 56 45 70
1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB AD81 ADC9 E606 1166 213E
4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042 7788 1DCE B5EE C0B4 F04B
Views expressed by the host do not reflect the staff, management or
sponsors.

“Economics deals with real man—not ideal beings, omniscient and
perfect.” --Ludwig von Mises

I hadn’t seen that when I was looking … though that’s only half the
debate. There certainly is an anti-gem attitude in Debian such that
those
debs probably won’t be in the official archives … but the second half
of
the debate is that you shouldn’t need gems because they are a
competing/conflicting package manager and hence polutes the ‘Debian Way’

Of all the linux dixtros, I like debian the best over all; mostly for
apt-get and it’s package base … but this dogmatic “though shalt only
do it
this way” gets grating at times …

Besides, I’ve ‘poluted’ my system with a patch kernel.org kernel,
non-official debs for all the multi media stuff, etc. etc … adding
gems
from source and then loading a few gems rather than debs is certainly no
worse than using CPAN …

Pragmatic instead of dogmatic is how I tend to view such things …