Add Compatibility for `category` and `categories` in Properties Files

[SableRaf]

Continuing the conversation with @mingness started in #42

Do you want to allow a library to submit without a category? If so, then the validate script needs updating, wrt optional or required fields.

Thanks for catching that! The properties file for LazyGUI (which is the library I picked as an example for testing my changes to the issue templates) is using category instead of categories which caused the workflow to error out.

The original script appears to have gracefully handled this by mapping category to categories when creating the contribs file.

To maintain compatibility with both formats (category and categories), we should update the script to support this mapping.

Regarding the case where category or categories are both missing or unpopulated, it looks like the original script set categories as null if it couldn't find it though I don't know if that was intentional (see here for example). I'd lean towards throwing an error and asking the contributor to pick at least one category.

[mingness]

The code already allows for existing properties files that use category

processing-contributions/scripts/parse_and_validate_properties_txt.py

Line 38 in d5b14cb

categories: Optional[str] = Field(None, alias='category')

The code just doesn't allow for new properties files to use category, instead forcing the use of categories.

processing-contributions/scripts/parse_and_validate_properties_txt.py

Line 23 in d5b14cb

categories: Optional[str] = Field(None)

Would you like to change this? Basically, a properties file like LazyGUI's, should it or should it not be allowed to be submitted as a new library properties file? The way the code is now, I'm loose when reading in files for updating the database, but strict when accepting new ones in submissions.

For completeness, categories are required for libraries

processing-contributions/scripts/parse_and_validate_properties_txt.py

Line 56 in d5b14cb

categories: str

[mingness]

I'm using Pydantic for data validation - I had manually tested for all these cases before it started getting unwieldy.

[SableRaf]

Would you like to change this? Basically, a properties file like LazyGUI's, should it or should it not be allowed to be submitted as a new library properties file?

I think writing category instead of categories is an easy mistake to make, especially if you are making a library from scratch. Is there a drawback to keeping the category > categories mapping?

[mingness]

It's an easy mistake, but it's a mistake that only has to be corrected once, and then it's not an issue. I see it as a consistency and simplicity thing. Why accept category and not author in that case? Technically, Pydantic makes it easy to accept aliases, but I have no idea how to code this in kotlin for instance - if we want to eventually move the scripts to Kotlin, do they have something like the Pydantic library?

[SableRaf]

I think the fact that both recent submissions used category shows it feels more natural for contributors. I'd say we should support category, author and any other singular/plural aliases for the same reason. It’s a small adjustment on our side that could reduce friction. What do you think?