Forum: Ruby Installing ROR with Darwin Ports

First let me say that I just got a new MacBook Pro and am looking
forward to developing on it. Let me also say that this is my first Mac,
so please bear with the infantile questions!

I am trying to install RoR with Darwin Ports, this seemed like the best
option for someone like me. I am going through the process just fine,
but when I attempt to install the Rails gem via: "sudo gem install
rails", I get the following error:

opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- sources (LoadError)

I have installed rails via: "sudo port install rb-rails", but the
instructions I was trying to follow called for installing via the gem.
I have read a post that went in to length debating the virtues of
managing things with gems or with MacPorts, I don't really care which I
end up using, as long as it works! I am familiar with the "gem" method
coming from a Windows world, so I guess I would prefer that.

I also tried installing RoR with the Hivelogic tutorial for compiling
and all, but somewhere along the line I hosed it up (I think I was
running software updates concurrently with the ruby build/install
process) and I had to re-install OSX!

Thanks in advance for any and all help.

Don't go this route.  It may seem easier, but you're cutting yourself
off at the knees on the learning experience.

Compiling and installing Ruby is NOT hard to do.  In fact, it's so easy
that there are fantastic tutorials on how to do it.  I highly recommend
this one as a fellow Mac user:
http://hivelogic.com/articles/2005/12/01/ruby_rails_lighttpd_mysql_tiger

It's pretty straight forward.  Make sure you read his article on why
you should compile/install in /usr/local (see
http://hivelogic.com/articles/2005/11/29/using_usr_local).

Make sure you use Ruby 1.8.4.  Ruby 1.8.5 fixed a bug that was allowing
breakpointer to work.  You're going to use breakpointer a LOT in
developing in Rails.

Let me know if you get stuck.  I'll try my best to help.

James H.

James:

Could you please clarify this:

> Make sure you use Ruby 1.8.4.  Ruby 1.8.5 fixed a bug that was allowing
> breakpointer to work.  You're going to use breakpointer a LOT in
> developing in Rails.

Are you saying that 1.8.5 broke breakpointer, hence we should use 1.8.4?

Graham

James H. wrote:
> Don't go this route.  It may seem easier, but you're cutting yourself
> off at the knees on the learning experience.
> 
> Compiling and installing Ruby is NOT hard to do.  In fact, it's so easy
> that there are fantastic tutorials on how to do it.

If learning to install stuff from source is the goal, following a
step-by-step recipe off the net may give some insight.  Personally I'd
rather just have stuff work, and spend my time on the real issues.

I have ruby, rubygems, postgres, vim and subversion installed from
ports.  Including dependencies that's 20+ packages, all installed with
~5 lines, and updated in 1.  It seems rock solid (I'm new to macs as
well - guess ~2 months).

These instructions worked for me:
http://www.nshb.net/install-ruby-and-rails-on-mac-intel

I stopped after the postgres driver.  Should perhaps have gotten that
from gems, but it seems to be working fine.


Afraid I can't say quite what your gems issue is, but google does have a
few interesting links on the first page:
<http://www.google.com/search?client=opera&rls=en&q=rubygems+no+such+file+to+load+--+sources&sourceid=opera&ie=utf-8&oe=utf-8>


HTH,
Isak

Yes.  Use Ruby 1.8.4 for now if you're doing Rails development.  See
http://eigenclass.org/hiki.rb?breakpoint+breaking+in+1.8.5 for details.

James H.

On 9/7/06, Graham Wideman <notarealaddress@nowhere.com> wrote:
> James:
> Could you please clarify this:
> > Make sure you use Ruby 1.8.4.  Ruby 1.8.5 fixed a bug that was allowing
> > breakpointer to work.  You're going to use breakpointer a LOT in
> > developing in Rails.
> Are you saying that 1.8.5 broke breakpointer, hence we should use 1.8.4?

He's saying that breakpointer depended on a bug in Ruby 1.8. This bug
was fixed in Ruby 1.8.5. Breakpointer is being updated with a way to
work in Ruby 1.8.5, but it's not updated yet.

-austin

On Thu, Sep 07, 2006 at 11:42:40PM +0900, Austin Ziegler wrote:
> work in Ruby 1.8.5, but it's not updated yet.
I just released call_stack 0.1.0, which contains a workaround to use
breakpointer with Ruby 1.8.5.

 http://eigenclass.org/hiki.rb?call_stack+0.1.0

Once you've installed it, (either with the tarball or  gem install 
call_stack
once the packages have propagated to the mirrors), you can proceed as 
usual,
the only difference being that you have to run the application being 
debugged
with

  ruby -rbreakpoint185 script/server

instead of

  ruby script/server

We're getting a little tangential to the original topic at hand, but is 
your
call_stack code expected to be integrated directly into Breakpointer so 
that
this modified calling isn't necessary in the future (i.e. we can 
eventually
have usage like 'ruby script/breakpointer' again)?

James H

On Fri, Sep 08, 2006 at 01:19:56PM +0900, James Herdman wrote:
>>I just released call_stack 0.1.0, which contains a workaround to use
>>breakpointer with Ruby 1.8.5.
>
>We're getting a little tangential to the original topic at hand, but is your
>call_stack code expected to be integrated directly into Breakpointer so that
>this modified calling isn't necessary in the future (i.e. we can eventually
>have usage like 'ruby script/breakpointer' again)?

That part of the procedure (running breakpointer) remains the same:

  old (no 1.8.5 love)          |   new (call_stack)
                               |
* add breakpoint() calls to    | * add breakpoint() calls to
  your code                    |   your code
* run the breakpointer:        | * run the breakpointer:
  ruby script/breakpointer     |   ruby script/breakpointer
* run the application, e.g.    | * run the application, e.g.
  ruby script/server           |   ruby -rbreakpoint185 script/server

As you see, only the last point changes. As for whether we can get rid 
of
-rbreakpoint185 when running the server, that's not for me to decide 
really.
script/server could be modified to load it by default, but it must be 
kept in
mind that breakpoint185 introduces some overhead and will make the app 
run
slower. That doesn't matter when debugging, and nobody should be using
script/server in production, but I guess that adding an option to
script/server would probably be best, so you can do

 ruby script/server -b      (or --breakpoint).

Well, since I have started this process with Darwing ports, how would I
go about reversing what I have done? Simply delete the directory that I
installed it to and change the file telling my Mac where to look for
files?

I tried the Hivelogic method once before, my Mac froze, wouldn't
re-boot and I had to re-install MacOSX. That isn't too big of a deal,
but I would rather not go through that again!

Thanks for the tips, I will try the Hivelogic method, I do want to
learn how to do things that way anyways.

shane.pinnell@gmail.com wrote:
> Well, since I have started this process with Darwing ports, how would I
> go about reversing what I have done? Simply delete the directory that I
> installed it to and change the file telling my Mac where to look for
> files?
>

If you installed the packages with port, you should probably use that
to remove them as well.

I think something like;

port uninstall -uc installed

should remove all installed ports. If that doesn't work, there's always
"man port", and a lot of other resources on the net.

HTH,
Isak