When searching for packages on the web interface, the search term is currently only matched on the beginning of the package name. For example, ffi returns no results while libffi returns the desired libffi package.
It would be great if the text search string was matched anywhere in the package name, not just at the beginning.
I'll totally second this, It'd be a bummer to go through the process of packaging up a new lib only to find out that it exists in core/ under a slightly different name that my searches didn't return XD
relevant links, the second contains a comment on the auto-complete style of search.
I totally didn't notice that it was autocomplete-ing. So chock this up to pebcak?
nah, I think it's confusing. It's come up several times in different forums.
@ryankeairns I think it'd be helpful if you could define exactly the behavior you think we should support in search (beyond just substring matching) so we could plan how to fix it all at one go. like are there other syntaxes we want to support? (e.g. */redis to find anyone's redis)
@juliandunn I feel the substring matching described here is the 80/20 approach to quickly get this working in a more expected and useful manner, but you're right there is the origin factor we need to deal with.
We might consider getting this substring matching working (at least on the package name initially, not the origin name) then circle back and add an origin filter. For example, you could pick a specific origin or 'all origins' from a dropdown and then match the search string on the package name (which would have been implemented in that first iteration).
*/redis is interesting, but it introduces a fairly uncommon search capability (uncommon on the web, that is) that then requires us to highlight and teach users. I think we can largely solve this problem with a simple filter/dropdown and better string matching.
ok - let's work on just substring matching on only the package portion for now and deal with origin-based searching when we have more packages in other origins.
Fixed. Example: https://app.habitat.sh/#/pkgs/search/ffi
Most helpful comment
@juliandunn I feel the substring matching described here is the 80/20 approach to quickly get this working in a more expected and useful manner, but you're right there is the origin factor we need to deal with.
We might consider getting this substring matching working (at least on the package name initially, not the origin name) then circle back and add an origin filter. For example, you could pick a specific origin or 'all origins' from a dropdown and then match the search string on the package name (which would have been implemented in that first iteration).
*/redisis interesting, but it introduces a fairly uncommon search capability (uncommon on the web, that is) that then requires us to highlight and teach users. I think we can largely solve this problem with a simple filter/dropdown and better string matching.