The search feature is going to be implemented in steps.
First step
The first step will accept one keyword, that'll be searched inside package names and summaries, case-insensitively.
Second step
We'll want to pass moss multiple keywords to narrow the search results and make them more relevant. As an example, searching for email cli may return packages that are both email clients, and terminal-based (without a GUI). While we take the time to complete the second step, a workaround for a similar outcome is to search with one keyword and then to grep the result list.
Implementation
We use a SQLite3 backend to store package metadata. For performance reasons and to make the code likely clearer, we are going to use SQLite3's full-text search.
We also use Diesel as the ORM inside moss. Diesel provides a full-text search crate that unfortunately works only with Postgres. Hopefully, we'll be able to upstream a similar SQLite3-based implementation and use it inside moss.
The search feature is going to be implemented in steps.
First step
The first step will accept one keyword, that'll be searched inside package names and summaries, case-insensitively.
Second step
We'll want to pass
mossmultiple keywords to narrow the search results and make them more relevant. As an example, searching foremail climay return packages that are both email clients, and terminal-based (without a GUI). While we take the time to complete the second step, a workaround for a similar outcome is to search with one keyword and then togrepthe result list.Implementation
We use a SQLite3 backend to store package metadata. For performance reasons and to make the code likely clearer, we are going to use SQLite3's full-text search.
We also use Diesel as the ORM inside moss. Diesel provides a full-text search crate that unfortunately works only with Postgres. Hopefully, we'll be able to upstream a similar SQLite3-based implementation and use it inside moss.