Comment on Feedback Wanted: Manage Plugin Dialog
matterhorn103@discuss.avogadro.cc 2 weeks ago
Great ideas!
Given the counts that have accumulated within less than three weeks, I think a count of 30-day/monthly downloads would be both fair and typical. I suppose you’d add that to the stats file alongside the all and recent counts?
Python packaging has standard URL labels that include an issues label, so we should look for project.urls.issues (and potentially the aliases listed at the linked page too, e.g. bugs) and encourage people to use that mechanism.
I’d suggest we also provide a general link to the plugin’s repository as well, which we don’t have to rely on the pyproject.toml for, we already have that info in the plugin database.
Here I’d also suggest reusing the standard mechanism, encouraging authors to use the project.keywords field and then extracting that. We’ll need the search to match on substrings of the plugin name too though, in case a plugin doesn’t specify any keywords.
Isn’t that already possible by sorting on the Features column?
Right now “recent” is defined as 180 days. I’d just change it to 30.
I’d just want to make sure we have a fallback for plugins that don’t add the
project.urls.issuesorbugs. Right now, for example, I see that “description” is missing on one of mine (mattersim)As for citations, GitHub suggests
CITATION.cfffiles, but I kind of like theduecreditpackage which handles NumPy and SciPy, as well as MDAnalysis already.My concern is that as the number of plugins grow, we’ll want more organization than a sorted list. I feel like ~30 is starting to get to that point and certainly ~50 will start to feel a bit overwhelming.
I’m also thinking about some ways to add a “plugin gallery” to the website - since some users don’t realize we already have plugins for RDKit, xtb, etc. based on the survey.
We could just fall back to the main repo URL. Or, the script in
avogadro/pluginsthat extracts the metadata from the plugins’ TOML files to generate the index could automatically generate the appropriate issues URL for any plugin that is on GitHub and doesn’t manually specifyproject.urls.issues.Not sure I’m a huge fan of something that’s Python-specific, encodes the metadata using Python code, and is a solution specific to that one implementation. This
CITATION.cffis GitHub’s own solution, but it is at least supported by Zotero and Zenodo. But I don’t have strong feelings. It’s a shame there’s no standardized way to handle companion publications, really – it would be good if citations of academic papers were part of the SPDX Bill of Materials specification, for example.That would be my suggestion, since most (all?) of the current plugins don’t use
project.urls.issues:slight_smile:It’s fairly common for people to list things in the README, but that’s not very uniform and I’m a little reluctant to try to extract DOI or BibTeX from the README.
I guess the alternative would be to add something like
pyproject.urls.doias a list in thepyproject.tomlas an alternative if theCITATION.cffisn’t found.Here’s my latest version. The author list grows if needed (e.g., here) and gives a download count and a link to the bug tracker.
Thoughts? Ideas? Right now, the keywords are stored in the model but in a hidden column. (Not that any current plugin includes keywords in their pyproject.toml yet.)