Add page with list of trove classifiers

[nlhkabu]

For package authors, we will need to add a list of all trove classifiers. I am not sure where this is best placed - maybe in the footer?

ping @dstufft for an opinion on this.

[timofurrer]

Is this really a page that belongs on the PyPI site?

PEP 301 calls them distutils trove classifiers. Maybe a better place to give more information about those to the package authors would be the Python Packaging User Guide?

I think a link somewhere close to the classifiers shown in the project details page would be useful.

[nlhkabu]

Yes, sure. I am not opposed to moving it out of the site and into the docs. I do think we need to continue to link directly to it though, as this is something that is currently done on PyPI (so users may be accustomed to finding the list via this link).

[takluyver]

It's valuable to have the list in a convenient plain form, not embedded in HTML docs, for tools to fetch. Flit does this, for instance. The list changes often enough (e.g. adding new frameworks) that I don't want to bundle a static copy.

At present it seems you can get this from the legacy API at https://pypi.org/pypi?%3Aaction=list_classifiers - can we rely on that URL working for the foreseeable future?

[dstufft]

Yes that will continue to work, although ideally for automated consumption we come up with some newer, better JSON based API.

[takluyver]

Great, thanks. There's no pressure from my side for a JSON version of this unless someone makes a classifier with a newline in.

[ncoghlan]

I think @timofurrer's question does raise an interesting UX question: would a file in the specifications section of the PyPUG and/or some other PyPA repo that anyone can submit a PR to be a better primary data source for this information than the PyPI database?

Then PyPI would just be a consumer of that file (presenting it via the web URL), rather than the source of the official list.

[waldyrious]

would a file in the specifications section of the PyPUG and/or some other PyPA repo that anyone can submit a PR to be a better primary data source for this information than the PyPI database?

As an additional data point, doing this would be more transparent and would make issues like this easier to address.

[theacodes]

I agree with @ncoghlan - we should have some canonical location for this that's easy to modify.

Could we pull these classifiers out of the warehouse database and just store them in a datafile in this repository?

Alternatively, I could see us establishing a new project that holds the canonical list that warehouse and pypug depends on.

Related: #3028

[dstufft]

Easy to modify isn't exactly ideal here, there are a few different types of modifications you can make:

• Addition: This is easy to cope with, since it's purely addition, Warehouse can simply add it.
• Deletion: This is less easy to cope with, because there are really two kinds of deletion possible:
  • Deletion where we want to expunge the record from all releases. This is technically easy, but unlikely to actually be what we want (and it would make the PyPI metadata and the package metadata disagree, which is undesirable)
  • Deletion where we simply want to disallow new uploads, containing the classifier, but still want to retain it for historical record.
• Rename: This is hard to deal with, because you don't want to suddenly start rejecting previous versions of the classifier, it would break people's uploads for little reason, but you want to treat the old and the new name as equivalent.

This also makes a simple text file not really well suited for it, because you can't really different between deletion to expunge from deletion to block from renames. In addition, internally in Warehouse (and legacy PyPI) the trove classifiers are represented as a rows in a database that we foreign key against, so something that we depend on isn't going to be a workable solution unless we do something janky like try to automatically reconcile our database against that dependency (which then starts to get into all of the problems I listed above with having to figure out what sort of change it was made).

Beyond all of that though, regardless of what we call the list in some other location or the list inside of the DB the "canonical" location, practically speaking, PyPI is going to be the defacto canonical location in every way that anyone actually cares about (since 99% of the time, what someone cares about when looking at classifiers, is whether PyPI will accept them or not).

Ultimately, I think the canonical location being on PyPI makes things easier to maintain and manage and it allows us to provide a better user experience for end users as well. It lets us put structured data in the database, while providing a UI to actually manage it that glosses over the details of actually managing that structured data. It also lets us tailor what the list we give people contains, based on what the context of us giving them that list is. For example, in documentation we would almost certainly exclude any legacy aliases for renamed classifiers or deleted classifiers that we still have the record for but are no longer accepting, but for an API endpoint that something like flit might call, we'd want to include all of the classifiers we are currently accepting (legacy alias or not) but none of the ones that we are not. I imagine there'd even be an API that reports all classifiers past and present and their current status.

[ncoghlan]

Thanks @dstufft, given that extra information, I agree it makes sense to have the database remain the official classifier listing, with various APIs to extract the current state of the list.

[theacodes]

So the question is now is how should we bring the legacy API forward to provide this canonical list via both an API and UI in Warehouse?

…

On Sat, Mar 24, 2018, 10:06 PM Nick Coghlan ***@***.***> wrote: Thanks @dstufft <https://github.com/dstufft>, given that extra information, I agree it makes sense to have the database remain the official classifier listing, with various APIs to extract the current state of the list. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1300 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPUczWy8EYMBcpUIPF8DMXTneTWflFRks5thyXOgaJpZM4JB0d8> .