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.issues or bugs. Right now, for example, I see that “description” is missing on one of mine (mattersim)
As for citations, GitHub suggests CITATION.cff files, but I kind of like the duecredit package 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/plugins that 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 specify project.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.cff is 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
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.doi as a list in the pyproject.toml as an alternative if the CITATION.cff isn’t found.
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.)
Column status, would it be sensible to add a third level of “a newer version / update is available” – similar to the “green check mark + arrow” in Debian’s package manager synaptic?
do not automatically check if there is a new version of the plugin in question (as by now / default)
report if there is a new version of the plugin; a check which takes place once daily to update the indicator in the first column if necessary. If affirmative (there is an update available) a brief notifier could be shown for about 5 s (similar to some email client’s notifier “you have mail”) when Avogadro2 is started. I would prefer if this level were be an explicit opt-in by the user.
The potentially most intrusive level: if there is a new version of a plugin identified, to notify the user and then automatically install the updated version of the corresponding plugin(s), then i) inform that the update was successful and ii) the update is available right now/after restart of Avogadro2. Equally only available by explicit opt-in, this might be useful for users which own the device.
The three-level approach do nothing/ask in advance/automatically roll-out the update is inspired by DataWarrior:
Flagging plugins for updates is probably a good idea. I’ll need to think a bit because some cases may be an updated plugin for a new version. For example the next update of generators will include support for z-matrix coordinates. But that’ll require v2.1 of Avogadro.
I’d probably go for the two levels you mentioned:
no automated check (current behavior, only show when you open the window)
some sort of opt-in notification that there are updated plugins to install
I’m pretty reluctant to use automatic updates - in part because I’d hate to break someone’s workflow.
Oh, everything would be opt-in. As I mentioned elsewhere, there’s a new build for Windows with crash reporting built-in. But IMHO, that won’t be the default build for Windows and you still need to opt-in at startup for it.
links to the GitHub issues or relevant bug tracker)
