Adding 'bundle grep PATTERN' for searching across gems / add bundle show --paths

[tiegz]

This patch adds a "bundle grep" cli command, which greps for a pattern across all your bundled gems.

bundle grep 'some_mysterious_method'

I just noticed someone else did this too with ack (#1257) ... Seems like grep would be more ubiquitous than ack, but either way both solutions would be really helpful to me in bundler.

[indirect]

Can I ask how you did this before, with system rubygems? This seems like a feature that would be great to have, but I'm not sure it belongs in the core of Bundler?

On Aug 19, 2011, at 9:24 AM, [email protected] wrote:

This patch adds a "bundle grep" cli command, which greps for a pattern across all your bundled gems.

bundle grep 'some_mysterious_method'

I just noticed someone else did this too with ack (#1257)... Seems like grep would be more ubiquitous than ack, but either way both solutions would be really helpful to me in bundler.

Reply to this email directly or view it on GitHub:
#1360

[tiegz]

I just did a "rake build" and installed the bundler gem in the pkg folder. I just dived into the Bundler source so I'm not sure if this is the best way to do it (maybe exec instead?), but the spec did pass for me. If you didn't put it in the core of Bundler, where would be a better place?

[indirect]

Sorry, I meant: how do you search for methods inside gems when you aren't using bundler?

On Aug 19, 2011, at 11:20 AM, [email protected] wrote:

I just did a "rake build" and installed the bundler gem in the pkg folder. I just dived into the Bundler source so I'm not sure if this is the best way to do it (maybe exec instead?), but the spec did pass for me. If you didn't put it in the core of Bundler, where would be a better place?

Reply to this email directly or view it on GitHub:
#1360 (comment)

[tiegz]

Ah! I actially don't know of a way to grep across system rubygems. Im on a train now, but I'll look later and see if there's a built in way.

[tiegz]

So I can't find anything in rubygems that searches for a pattern across system gems.

There's always obj.method(:some_mysterious_method).__file__, and obj.method(:some_mysterious_method).source_location in 1.9.2, but people don't always have an IRB session open.

The big reason I thought this would be good for bundler was b/c projects using bundler by nature use a lot of external code. Broken tests or bugs would be much easier to track down if you could easily search among all bundled gems (even for a constant or variable, in addition to methods).

Another alternative to this would be making a bundle open * option available (that would open them all, which you could then search amongst). Thoughts?

[danp]

I don't think I've ever needed to search across everything in my bundle; usually I know the gem I want to dig into (via an exception usually) and I can use bundle show <name> to get its path. If you want the ability to search across all gems, perhaps adding an option to bundle show to show all paths, one per line, would be more generally useful?

That way you could do things like:

% grep foo $(bundle show --paths)
% ack foo $(bundle show --paths)
% du -csh $(bundle show --paths)

[indirect]

I personally tend to use bundle open GEM and then Ack In Project, but bundle show --paths seems useful. Definitely much more flexible than either bundle grep or bundle ack, and seems to easily fit into the core functionality Bundler provides. It also lends itself to easy shell aliasing, if it's something you find yourself doing a lot. Does that seem like a reasonable compromise?

[tiegz]

dpiddy: good idea for a patch; doesn't a --paths flag seems more applicable to bundle list though? My original hope was to avoid shell one-liners for bundle grep too, since it's a common need for me.

indirect: I think bundle open is incredibly useful, but also a different use case than bundle grep would provide. For instance, there might be some string variable used in your codebase (eg .../some_gem/en.yml). When you see a failing test with that string, bundle grep would be a faster way to find that mystery string.

Thanks for the input! Good to get others' opinions about this.

[danp]

bundle list is an alias for bundle show, so as it stands I think bundle show --paths is reasonable.

Out of curiosity, why are you looking to avoid a shell alias/function? For bundler use I have them even for built-in commands, eg bi for bundle install, be for bundle exec, ber for bundle exec rake, etc.

[tiegz]

Those shell aliases are technically just shortcuts for existing bundler commands, but there is currently no bundler command to search amongst bundled gem sources. I just do this often enough that I felt it should be built-in.

[danp]

Right, you said:

My original hope was to avoid shell one-liners for bundle grep too, since it's a common need for me.

I thought you meant you weren't a fan of bundle show --paths because it would mean you'd have to have a shell function for something like:

grep -r foo $(bundle show --paths)

You could do that with a function, something like:

bgrep() {
  grep -r "$@" $(bundle show --paths)
}

Would that be acceptable?

[tiegz]

Yes, I know what you meant. I'm not against a shell function/alias-- my whole point is that I thought it should be in core. But I don't mind doing a shell function/alias instead. No worries. If I have time I'll try to add bundle show --paths.

[tiegz]

^ Okay, that last commit adds bundle show --paths. The spec I added works, but jic do you guys see any helpers that would help clean up that spec at all?

[tiegz]

Just for posterity, I came across another good use case of "bundle grep" this week. An argument to an ActiveSupport method changed from Rails 2.3.* to Rails 3.*, and actually broke a plugin that I'm using. If I had "bundle grep" I could easily search all our bundled gems that use this changed method (to ensure they still work). But I'll just use that shell alias for now ^_^