New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #15434 (closed enhancement: fixed)

Opened 5 years ago

Last modified 4 years ago

RFE: port search should search name, description and long_description

Reported by: raimue@… Owned by: raimue@…
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version: 1.6.0
Keywords: Cc: landonf@…, blb@…
Port:

Description

At the moment, port search only searches in the name of a port. It would be more helpful if it would also look in description and long_description.

The result for 'port search foo' should be the same as for:

port echo name:foo or description:foo or long_description:foo

(Given that we eliminate duplicates, #15433).

Change History

comment:1 Changed 5 years ago by raimue@…

  • Owner changed from macports-tickets@… to raimue@…
  • Status changed from new to assigned

comment:2 Changed 5 years ago by raimue@…

  • Status changed from assigned to closed
  • Resolution set to fixed

Fixed in r37119.

comment:3 follow-up: ↓ 5 Changed 5 years ago by landonf@…

  • Status changed from closed to reopened
  • Resolution fixed deleted

This actually makes 'search' pretty useless if you use a common term. Take 'tex' as an example -- port search tex returns 391 ports, but almost none of them are related to TeX.

comment:4 Changed 5 years ago by landonf@…

  • Cc landonf@… added

Cc Me!

comment:5 in reply to: ↑ 3 ; follow-up: ↓ 9 Changed 5 years ago by raimue@…

Replying to landonf@macports.org:

This actually makes 'search' pretty useless if you use a common term. Take 'tex' as an example -- port search tex returns 391 ports, but almost none of them are related to TeX.

Hm, there is port echo name:tex to search in port names only, but that is not so obvious. How should it be changed?

We could add flags to specify the fields to search for:

port search tex
port search --name tex
port search --name --description --long_description tex

Or add an option to port echo to get more output than just the name.

comment:6 Changed 5 years ago by raimue@…

  • Component changed from ports to base
  • Milestone set to MacPorts base enhancements

comment:7 Changed 5 years ago by raimue@…

  • Milestone changed from MacPorts base enhancements to MacPorts 1.7.0

Please comment what should be done here. I don't want to change the behavior again in the next release.

comment:8 Changed 5 years ago by blb@…

  • Cc blb@… added

The old search sometimes wasn't helpful because there are lots of things that should match but didn't because of the limits. The new one is somewhat the opposite, potentially giving too many results. I prefer the new way since to me more info is better, but some may disagree.

The big problem here is that we don't really know how most people use search. One way to find out is to ship 1.7.0 with search like this and see if there are lots of tickets filed against it. If so, we can always switch back to the old method in 1.7.1 until a better solution is found.

comment:9 in reply to: ↑ 5 Changed 5 years ago by mcklaren@…

Replying to raimue@…:

Replying to landonf@macports.org:

This actually makes 'search' pretty useless if you use a common term. Take 'tex' as an example -- port search tex returns 391 ports, but almost none of them are related to TeX.

Hm, there is port echo name:tex to search in port names only, but that is not so obvious. How should it be changed?

We could add flags to specify the fields to search for:

port search tex
port search --name tex
port search --name --description --long_description tex

Or add an option to port echo to get more output than just the name.

I see fine this option, I think that port search tex could be a default form, for example, port search tex = port search --name tex then add 2 new options port search --description and port search --long-description, too i will add best a --long-description that --long_description, IMHO

comment:10 Changed 4 years ago by raimue@…

  • Milestone changed from MacPorts 1.7.0 to MacPorts 1.7.1

Moving to milestone 1.7.1, so we can revisit it again after 1.7.0 is released and we got some more feedback on 'port search'.

comment:11 Changed 4 years ago by andrew@…

This sort of search problem is rather common. My suggestion would be to add options for perl-like regular expression searching, as well as the --name, --description, and --long_description options.

That way, if searching for TeX, you can use

port search --rexexp "/\btex\b/i"

to search, case-insensitively, for TeX on a word boundary.

Just my $0.02 - and at the current Canada to US exchange rate, it may not be worth much... :-)

comment:12 Changed 4 years ago by clayton@…

I would agree that the new search can be helpful but it is bringing back way to much information. Another example is the ack (p5-app-ack) port.

$ port search ack
...
Found 673 ports.

That more than fills up the buffer on my terminal :). I like the idea of having the options for searching --name, --description and --long-description. I'm inclined to say that it should search --name by default also.

comment:13 Changed 4 years ago by raimue@…

I added some new options to port search on trunk, check port help search to see them all. Special options are now --exact, --glob, --regex to choose match style; --case-sensitive should be obvious. The other options specify which fields are searched.

Relevant revisions are r44071, r44073, r44077, r44079, r44080, r44082, r44083, r44084.

comment:14 Changed 4 years ago by raimue@…

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Milestone changed from MacPorts 1.7.1 to MacPorts 1.8.0

Moving to 1.8.0 as this also includes some refactoring parts.

comment:15 Changed 4 years ago by raimue@…

The default was changed in r48007 to port search being equivalent to port search --name --description, which gives much better results for some search terms, e.g. "haskell".

If this gives too much results, it can be narrowed down with the new options.

Note: See TracTickets for help on using tickets.