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:

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
eigenclass.org for details.

James H.

On Thu, Sep 07, 2006 at 11:42:40PM +0900, Austin Z. 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.

eigenclass.org

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 9/7/06, Graham W. [email protected] 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

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.

On Fri, Sep 08, 2006 at 01:19:56PM +0900, James H. 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).

[email protected] 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