Bug: Requiring "breakpoint" causes the entire Rails framework to load

Hi

I'm working with:

1. Ruby 1.8.4 (i386-mswin32)
2. RubyGems 0.8.11
3. Rails 1.1.2 (obtained through RubyGems)
4. ruby-breakpoint (0.5.0)

Whenever I require 'breakpoint', the entire Rails framework gets
loaded as well.

I tried "gem uninstall rails", and then require 'breakpoint' returned
false and didn't load Rails, but worked. I tried
uninstalling/reinstalling ruby-breakpoint - didn't help.

What should I do? I want to use breakpoint outside of Rails, but
loading the entire Rails environment for that is pretty taxing: nearly
400 files are
loaded, which takes several seconds each time.

Regards,

Alder Green

have you tried:

ruby -r debug 'filename.rb'

Michael

Alder Green wrote:

I'm working with:

1. Ruby 1.8.4 (i386-mswin32)
2. RubyGems 0.8.11
3. Rails 1.1.2 (obtained through RubyGems)
4. ruby-breakpoint (0.5.0)

Whenever I require 'breakpoint', the entire Rails framework gets
loaded as well.

I tried "gem uninstall rails", and then require 'breakpoint' returned
false and didn't load Rails, but worked. I tried
uninstalling/reinstalling ruby-breakpoint - didn't help.

What should I do? I want to use breakpoint outside of Rails, but
loading the entire Rails environment for that is pretty taxing: nearly
400 files are
loaded, which takes several seconds each time.

I'm the author of ruby-breakpoint and not exactly sure what is happening there. The gem spec of ruby-breakpoint certainly doesn't include any dependencies. I don't see why Rails would get loaded.

One way to work around the problem might be to just copy the breakpoint library files directly into your site-lib directory of Ruby.

I'm not sure what is happening there, though. Perhaps the Rails people have an idea what might be happening here?

···

--
http://flgr.0x42.net/

I'm no gems internals guru but it seems to me that when you require
'rubygems' all of the gems/**/lib directories are added to the path, and the
rails gem has a lib/breakpoint.rb. When looking at the lib directories of
most other gems, it looks like the rails gem has a fairly dirty lib/.

-Scott

···

On 4/15/06, Florian Groß <florgro@gmail.com> wrote:

Alder Green wrote:

> I'm working with:
>
> 1. Ruby 1.8.4 (i386-mswin32)
> 2. RubyGems 0.8.11
> 3. Rails 1.1.2 (obtained through RubyGems)
> 4. ruby-breakpoint (0.5.0)
>
> Whenever I require 'breakpoint', the entire Rails framework gets
> loaded as well.
>
> I tried "gem uninstall rails", and then require 'breakpoint' returned
> false and didn't load Rails, but worked. I tried
> uninstalling/reinstalling ruby-breakpoint - didn't help.
>
> What should I do? I want to use breakpoint outside of Rails, but
> loading the entire Rails environment for that is pretty taxing: nearly
> 400 files are
> loaded, which takes several seconds each time.

I'm the author of ruby-breakpoint and not exactly sure what is happening
there. The gem spec of ruby-breakpoint certainly doesn't include any
dependencies. I don't see why Rails would get loaded.

One way to work around the problem might be to just copy the breakpoint
library files directly into your site-lib directory of Ruby.

I'm not sure what is happening there, though. Perhaps the Rails people
have an idea what might be happening here?

--
http://flgr.0x42.net/

Scott Barron wrote:

I'm no gems internals guru but it seems to me that when you require
'rubygems' all of the gems/**/lib directories are added to the path, and the
rails gem has a lib/breakpoint.rb. When looking at the lib directories of
most other gems, it looks like the rails gem has a fairly dirty lib/.

Oh, it still bundles breakpoint? I guess that would be better solved by adding a dependency on ruby-breakpoint now that it comes with a gem.

IIRC they were using slightly different default options, but if that really turns out to be a problem I can certainly try to address this in a new version of ruby-breakpoint.

It's also odd that RubyGems will load the Rails version instead of the ruby-breakpoint one. Sounds odd.

···

--
http://flgr.0x42.net/

This is a simple conflict between the two RubyGems packages; such things are
bound to happen with increasing frequency.

When you do require 'breakpoint', the new Kernel#require defined by RubyGems
searches all package directories (more precisely, the require_paths, which
doesn't however help that much given the overall slowness of this approach)
for breakpoint{,.rb,.so,.bundle,.dll,.sl} and loads the first match it finds,
"activating" the corresponding RubyGems package in the process.

This search is performed in alphabetical order relative to package names, so
rails' copy (under activesupport/) will be found before ruby-breakpoint.

As for require 'breakpoint' loading all of Rails, that's quite surprising
since there are no explicit #require calls there, and activesupport doesn't
use auto_require. It'd be interesting to see the "require chain", if the OP can
provide it.

···

On Sun, Apr 16, 2006 at 05:21:41AM +0900, Florian Groß wrote:

>I'm no gems internals guru but it seems to me that when you require
>'rubygems' all of the gems/**/lib directories are added to the path, and
>the
>rails gem has a lib/breakpoint.rb. When looking at the lib directories of
>most other gems, it looks like the rails gem has a fairly dirty lib/.

Oh, it still bundles breakpoint? I guess that would be better solved by
adding a dependency on ruby-breakpoint now that it comes with a gem.

IIRC they were using slightly different default options, but if that
really turns out to be a problem I can certainly try to address this in
a new version of ruby-breakpoint.

It's also odd that RubyGems will load the Rails version instead of the
ruby-breakpoint one. Sounds odd.

--
Mauricio Fernandez - http://eigenclass.org - singular Ruby

Actually it's pulling in the one from the rails package. Its
breakpoint.rblives right in lib, active support's lives in
lib/active_support. Of
course, 'rails' is still alphabetically before 'ruby-breakpoint', but that's
why the framework would be loaded.

-Scott

···

On 4/15/06, Mauricio Fernandez <mfp@acm.org> wrote:

On Sun, Apr 16, 2006 at 05:21:41AM +0900, Florian Groß wrote:
> >I'm no gems internals guru but it seems to me that when you require
> >'rubygems' all of the gems/**/lib directories are added to the path,
and
> >the
> >rails gem has a lib/breakpoint.rb. When looking at the lib directories
of
> >most other gems, it looks like the rails gem has a fairly dirty lib/.
>
> Oh, it still bundles breakpoint? I guess that would be better solved by
> adding a dependency on ruby-breakpoint now that it comes with a gem.
>
> IIRC they were using slightly different default options, but if that
> really turns out to be a problem I can certainly try to address this in
> a new version of ruby-breakpoint.
>
> It's also odd that RubyGems will load the Rails version instead of the
> ruby-breakpoint one. Sounds odd.

This is a simple conflict between the two RubyGems packages; such things
are
bound to happen with increasing frequency.

When you do require 'breakpoint', the new Kernel#require defined by
RubyGems
searches all package directories (more precisely, the require_paths, which
doesn't however help that much given the overall slowness of this
approach)
for breakpoint{,.rb,.so,.bundle,.dll,.sl} and loads the first match it
finds,
"activating" the corresponding RubyGems package in the process.

This search is performed in alphabetical order relative to package names,
so
rails' copy (under activesupport/) will be found before ruby-breakpoint.

As for require 'breakpoint' loading all of Rails, that's quite
surprising
since there are no explicit #require calls there, and activesupport
doesn't
use auto_require. It'd be interesting to see the "require chain", if the
OP can
provide it.

--
Mauricio Fernandez - http://eigenclass.org - singular Ruby

...

It'd be interesting to see the "require chain", if the OP can
provide it.

What's the "require chain"? And how exactly can I provide it? I'll
certainly do it if I knew how.

More generally, and for the other responders: what are the recommended
short-term and long-term solutions for this problem?

I understand the long-term solution is to file a bug in the Rails
project and ask the maintainers to add a dependency for the
ruby-breakpoint gem instead of bundling ruby-breakpoint with Rails.
That dependency makes sense since ruby-breakpoint is integrated with
Rails (it's the standard way to debug Rails applications, used by
script/breakpointer).

In the short-term, is the best solution to simply get ruby-breakpoint
not through gems? Or is there a way to fix this issue while still
using the convenient gem version?

-Alder

···

On 4/16/06, Mauricio Fernandez <mfp@acm.org> wrote:

I think maybe if you know the version of ruby-breakpoint and its not the same as the rails one you could try something like
require 'rubygems'
require_gem 'ruby-breakpoint', '0.5.0'
require 'breakpoint'

···

On Apr 16, 2006, at 1:09 AM, Alder Green wrote:

In the short-term, is the best solution to simply get ruby-breakpoint
not through gems? Or is there a way to fix this issue while still
using the convenient gem version?

Hi Logan

Thanks, your solution worked. "require_gem 'ruby-breakpoint', '0.5.0'"
did in fact load only the 0.5.0 did in fact load only the
ruby-breakpoint 0.5.0, and not the ruby-breakpoint bundled with Rails
(whatever it is; I know not how to determine).

However, on a permanent basis I'll probably use Florian Groß's
solution, which works as well: copying the two ruby-breakpoint rb
files to site_ruby. This solution allows me to require ruby-breakpoint
in the standard way ("require 'breakpoint'") and saves me the trouble
of keeping track of my current ruby-breakpoint gem version and more
importantly: of the Rails gem version, naturally worrying that one day
it might catch up with the gem and bring back the problem I raised
here.

I'm going to raise the issue in the Rails bug tracking system. Looks
like their work is cut out for them - no appearant reason why they
can't use the proper way, i.e. remove the bundled breakpoint.rb file
and add the ruby-breakpoint gem.

However, this thread seems to raise an name-clashing issue which
perhaps should be brought to the attention of RubyGems' architects.

Regards,
Alder

···

On 4/16/06, Logan Capaldo <logancapaldo@gmail.com> wrote:

On Apr 16, 2006, at 1:09 AM, Alder Green wrote:

> In the short-term, is the best solution to simply get ruby-breakpoint
> not through gems? Or is there a way to fix this issue while still
> using the convenient gem version?
>

I think maybe if you know the version of ruby-breakpoint and its not
the same as the rails one you could try something like
require 'rubygems'
require_gem 'ruby-breakpoint', '0.5.0'
require 'breakpoint'

Note that if you use require_gem 'ruby-breakpoint' instead of require
'breakpoint', you do not need to give a version. By naming
'ruby-breakpoint' explictly, it will load the proper one.

-Scott

···

On 4/16/06, Alder Green <alder.green@gmail.com> wrote:

On 4/16/06, Logan Capaldo <logancapaldo@gmail.com> wrote:
>
> On Apr 16, 2006, at 1:09 AM, Alder Green wrote:
>
> > In the short-term, is the best solution to simply get ruby-breakpoint
> > not through gems? Or is there a way to fix this issue while still
> > using the convenient gem version?
> >
>
> I think maybe if you know the version of ruby-breakpoint and its not
> the same as the rails one you could try something like
> require 'rubygems'
> require_gem 'ruby-breakpoint', '0.5.0'
> require 'breakpoint'

Hi Logan

Thanks, your solution worked. "require_gem 'ruby-breakpoint', '0.5.0'"
did in fact load only the 0.5.0 did in fact load only the
ruby-breakpoint 0.5.0, and not the ruby-breakpoint bundled with Rails
(whatever it is; I know not how to determine).

However, on a permanent basis I'll probably use Florian Groß's
solution, which works as well: copying the two ruby-breakpoint rb
files to site_ruby. This solution allows me to require ruby-breakpoint
in the standard way ("require 'breakpoint'") and saves me the trouble
of keeping track of my current ruby-breakpoint gem version and more
importantly: of the Rails gem version, naturally worrying that one day
it might catch up with the gem and bring back the problem I raised
here.