Okay all! Sure you’re loving me by this point. I actually have something
constructive to say this time! 
First off: How to install to dreamhost
#1: Install personal rubygems as per
http://wiki.dreamhost.com/index.php/RubyGems
#2: Use the following to install some of the gems (Seems dreamhost gem
dependencies break occasionally)
gem install redcloth
gem install bluecloth
gem install radius
#3: Install radiant as previously mentioned
#4: Follow instructions to install radiant. Example command would be
like this:
radiant ~/ --ruby=/usr/bin/ruby
#5: Go into your .gems/cache folder and copy radiant-0.6.0rc1.gem to
radiant-0.6.0.gem (See below for comment)
#6: Go into your vendor directory on your webdir and unpack radiant (See
below for comment)
cd ~//vendor
gem unpack radiant
#7: Rename radiant-0.6.0 to radiant
#8: Change up your config/environment.rb to uncomment the line which
says ENV[‘RAILS_ENV’] ||= ‘production’ – You may also need to add the
following line at the top:
ENV[‘RADIANT_ROOT’] = ‘//vendor/radiant’
#9: Finish up the database.yml and perform the rakes and such as
suggested by the radiant installer.
When you do go to launch the website the first time, be patient.
DreamHost’s FastCGI is tempermental and DreamHost’s autoprocess killer
may tank your fastcgi the first few times until it learns that it isn’t
hanging. If you want to help with the process, enter this into the
bottom of your dispatch.fcgi: (Provided from numerous sources.)
class RailsFCGIHandler
private
def frao_handler(signal)
dispatcher_log :info, “asked to terminate immediately”
dispatcher_log :info, “frao handler working its magic!”
restart_handler(signal)
end
alias_method :exit_now_handler, :frao_handler
end
If you want to make sure it is dreamhost and the FastCGI implementation
being funny, go into public/.htaccess, uncomment
AddHandler cgi-script .cgi
and go down and change the line which says:
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
to
RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
If this works (It will be slow,) it is DreamHost’s proc killer being
strange. If you can’t get it launched the first time, do a
killall -9 dispatch.fcgi
a few times until it says theres no more processes named dispatch.fcgi,
and then try again. I know this is a bit of a mickey mouse workaround,
but until DreamHost catches on that the dispatch.fcgi isn’t evil
afterall, its what you have to do.
To show proof of working, go to http://test.bladedthoth.com
COMMENTS!
Okay, now that I’ve been using gems for a while and fighting with them,
I’ve come to find a few things that may help for the developers.
Problems that aren’t commonly seen but are showing up.
The gem being called radiant-0.6.0rc1.gem causes issues. gems still
apparently heavily relies on the file naming being dead-on to what it
needs. While it will install it, it gets itself confused on the process
of use. All the gems show up now EXCEPT for radiant in rails, because
it’s looking for radiant-0.6.0.gem and it doesn’t find it. This is part
of why custom installs of rubygems has a time with it. Something,
somewhere gets itself horridly confused and will not pick up the gems
properly when the instance of radiant can find itself for loading; You
get the error of ‘Can not find radiant-0.6.0’ even though when I write
up a script to list gems it shows it. Somehow the gempack process that
is being done works fine mostly, but for some reason some versions of
gem and the way they are set up have a hell of a time picking it up.
I hope this can help isolate the issue.
