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
on 2006-04-13 20:01
on 2006-04-13 20:15
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.
on 2006-04-13 20:18
I won't say it can't be done, because of course it can :) ... 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 2006-04-13 20:53
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
on 2006-04-13 22:13
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 ...