Improve categories input for package upload

[nihaals]

Current implementation

https://github.com/thunderstore-io/Thunderstore/blob/adc0d906c93afc5f1da715ba627ddec4ab2131e0/django/thunderstore/repository/package_upload.py#L72-L76

https://github.com/thunderstore-io/Thunderstore/blob/adc0d906c93afc5f1da715ba627ddec4ab2131e0/django/thunderstore/repository/package_upload.py#L217-L225

Proposal

WIP

[nihaals]

For the API, I think something like the following would work well:

{
  "communities": {
    "riskofrain2": {
      "categories": ["mods", "tools"]
    }
  }
}

The way the categories and communities are "paired" could be improved, but the idea is to provide a community and then the categories for that community's listing.

[MythicManiac]

I was planning on adding tags to the package manifest already in v1 (as an optional field). This would make sense since tags could be used for matching to categories per-community, even if not otherwise used yet.

Likewise, had the same plan for the NSFW flag

[nihaals]

I was planning on adding tags to the package manifest already in v1 (as an optional field). This would make sense since tags could be used for matching to categories per-community, even if not otherwise used yet.

So would the user not provide any categories but only tags, which are then mapped on the community's side to categories? If that's the goal I think this issue can be replaced with a tags proposal. I'd also like to remove the categories input in the package upload API in the meantime as the goal is to remove any inferred community data from the API.

[MythicManiac]

Yes, that's a solution more in-line with the long term goals I'd imagine.

[nihaals]

Could you open an issue with an idea of what tags would actually look like (e.g. PyPI's classifiers which essentially have categories/a hierarchy) and how the community management side would work (like can they create their own tags too or only map predefined tags to their own categories)?

[MythicManiac]

I think we discussed it in some issue briefly already, but for now you could assume them to be free-input strings with allowed characters of a-zA-Z0-9\-, with a max length of say, 32 chars (for UI purposes)? That's easy to make less restrictive later on if need be.

The intention is not to enforce a schema on them, but allow free input instead.

So for example you could have

{
  "name": "SomePackage",
  ...
  "tags": ["modpack", "some-custom-tag", "asd"]
}

and we'd map the package to the categories with a matching slug as any of the tags.

The community would get to define their own categories and which tags get matched to those categories. For now though we can just rely on the slug (so one tag per category).