Hey everyone,
I was curious if there would be a way to add Chaos Toolkit as a trove classifier considering it would help categorizing and discovering chaostoolkit extensions?
The page at Classifiers · PyPI mentions the instructions should be detailed at Writing your pyproject.toml - Python Packaging User Guide but I couldn’t find anything about it.
Does anyone know if there is a process for this?
Thanks,
Thanks Dustin.
I saw this package but there is no documentation there either about the right process nor how a decision is made.
There’s no process besides a PR to that repository; previous recent discussions happened in the PRs themselves.
Here’s a recent example: Add Odoo 18 trove classifier by sbidoul · Pull Request #187 · pypa/trove-classifiers · GitHub
(There are no formal guidelines yet, but there are some informal ones mentioned here: Add Data Acquisition (DAQ) classifier by stephanlachnit · Pull Request #184 · pypa/trove-classifiers · GitHub)
Thank you William.
I guess I’ll have to try my luck then 
This has me thinking, is there a concrete benefit to having trove classifiers rather than increasing the usefulness and search semantics of keywords?
I think the main advantage is in trove classifiers being curated/hierarchical, but this is arguably also their greatest disadvantage 
(Keywords reduce the bottleneck/curatorial overhead here, but they also rely on people using the same terms consistently/the index being able to normalize/equalize between keywords. cli versus command-line-interface versus cli-tool, etc.).
I think a better path would be to allow communities/ecosystems themselves to dictate the proper naming for easier discoverability of packages on PyPI. Maintainers would then have an incentive to follow conventions of said communities.
I’d be in favor of a proposal to deprecate trove classifiers the more I think about it, should someone have the time
Maybe I’m doing it wrong, but keywords have been almost completely useless to anything I ever did, exactly because there’s no canonical hierarchy of them.
On StackOverflow, they used to be moderately useful because the UX of that site recommended them based on frequency of usage. That would be completely gone when authoring a static text file in one of the myriad of editors out there.
I agree. I think the best path would be to hand off curating of certain trove subtrees to communities dedicated to that topic.
This is the exact same problem that keywords have in any large non-coordinated repository of data.
As an example, the Apache Software Foundation provides a single JIRA instance for all its projects. On this JIRA instance, projects can add freeform tags to their issues. Unfortunately, the autocomplete for the tags field searchs through all tags used by all projects. It’s a horrible, unusable mess.
So, yes, a curated list of topics is the way to go for PyPI.
I understand your desire for a curated enumeration rather than keywords but I think this is a poor example. I experience this issue as well and it is entirely due to Atlassian’s current implementation and they could fix it whenever they wish but haven’t. Within a project it is desirable to have scoped tags and search because other projects are of no concern to you.
In the case of PyPI there is no use case for a scoped search. Instead, it’s entirely about the global search.
As a counter example, are the classifiers for Python 3.12 used by anyone for search? Individual projects you’re already using could document support but I doubt anyone is searching for that in the hope of finding a package to use and therefore is not useful for search.
This is my entire point. Uncoordinated keywords do not work well with a global search. The Apache JIRA example was meant to illustrate that point.
Not in isolation, but people could use that keyword in combination with the full text search (and/or other classifiers) in order to narrow down results.
Yes, it’s used programmatically by Python Readiness and I’ve recently been using the 3.13 list to find projects that aren’t yet testing on the upcoming release, and may also need more work to be compatible.
As a datapoint: other ecosystems (like Rust’s crates) use both classifier and keyword-type schemes at the same time, to get both benefits.
I don’t have a strong opinion on inclusion criteria for classifiers, but I do think they currently serve a valuable use case that keywords can’t currently (because of data quality issues).