Registry metadata: do we need keywords?

[peterhuene]

Following a discussion on a cargo-component PR, cargo-component is implementing support for mapping Cargo.toml fields to the appropriate registry metadata.

Currently cargo supports distinct categories and keywords fields, where the former supports a list of predefined slugs meant to describe the overall category for the package and the latter meant to describe keywords about the package itself.

Right now the registry metadata supports only categories, with what I believe is the intention to be the set of keywords meant for searching the package.

Should this field in the registry metadata be called keywords instead? Should we have two distinct fields like cargo?

cc @silesmo.

[silesmo]

I brought this up in the initial discussion in one of the meetings. We landed on just a list of categories as we didn't want to restrict the possible options by having a moderated list of slugs. The reason for that we wanted to leave the meaning of the categories and what categories would be supported up to the registry implementation and different implementation having the ability to offer support different categories and just ignore what the implementation wouldn't support.

[peterhuene]

Regarding "categories", that makes total sense to me.

I think, though, that "keywords" speak more to the notion of "this is what people might search for to find this package".

Should we also have a keywords field in the registry metadata?

If not, should I be populating the categories in the registry metadata with the union of categories and keywords from Cargo.toml?

[silesmo]

I'm a bit unsure to be honest I originally assumed this would be covered by categories and then each registry could implement free form search against information in the description. But I guess adding keywords could make sense as well. I'm fine with adding keywords if you prefer that?