My rationale for including it in the code is that you could get it from an installed instance of the library, just like __version__. I may be misunderstanding, but the pyproject.toml doesn’t get pulled down when you pip install something, right? In the future it would be awesome if PyPI had fields on the site/ in the REST endpoint for citation information, but that’s a pretty big change to hope for as it’s relatively niche.
Another positive of doing it in code is the ability to dynamically generate things like the access date, and reuse the existing __version__ field rather than having to keep track of yet another version string.
Doing this in code makes it difficult to validate the correctness of the citation.
Correctness in terms of the structure, or that it points to something worthwhile? The format of the citation could be checked by jsonschema (when they work together, of course). In terms of pointing to something worthwhile, I’m not sure using metadata helps much: anyone can write semantically incorrect text wherever they want in any kind of project.
The downside of doing it in code is that you need an intermediate step to turn it into something usable by e.g. citation-js. But keeping an extra metadata file around is not great either, given you’d then have to include it in the manifest (the procedure for which doesn’t have the clearest documentation) and then dig it out of site-packages.
Looks like something to include in
pyproject.toml.
Another concern with this is that we wouldn’t be able to leverage existing citation data standards like CSL-data JSON. We could invent our own which trivially maps to it (CSL-data TOML), but given we already need a third-party tool (citation-js) to turn the JSON into other formats, going TOML → JSON → bibtex/whatever seems unnecessarily tortuous. We could store a raw JSON or bibtex string in the pyproject but that is even harder to write and validate, and doesn’t really make sense IMO.
This is all great feedback!