Add new index generation script for the updated plugin metadata specification

[matterhorn103]

No description provided.

[ghutchis]

Doesn't this follow from the git.commit? Or vice versa, if we have a src.url, why do we also want git.commit?

I'm wondering whether it's a good idea to have a script that helps people add to the repositories.toml or we use a GitHub action to generate some of these fields.

[matterhorn103]

It does if the plugin is hosted on GitHub.

The idea was that if the plugin is being downloaded using Git, you use the repo + ref, and if downloading the source archive directly, you use the URL. If it's done with Git there's no need to check the hash of the downloaded files, they're verified already, whereas if the archive was downloaded directly, it'll need to be hashed and checked against src.sha256.

Happy to only use one or the other, I was just under the impression that you're keen to have the plugin downloader use Git when it's available.

[ghutchis]

I meant more along the lines of "how do we make this easy to add a new repo"

I'm okay with including all these bits if there's an easy way for someone to say "here's my repo, can you please add all the bits for me?"

[matterhorn103]

OK, that makes sense.

In that case, I'd propose that we say we "fully support" plugins from two sources:

1. Certain Git-based development platforms from a list of recognised platforms, which for now means GitHub, and will hopefully in the future mean GitHub or GitLab
2. Arbitrary URLs that return archives of the source code

For (1), authors should provide only git.repo and git.commit in repositories.toml, and I'll edit the script so that it derives src.url and src.sha256 for the index, so that those fields are always available and Avogadro doesn't have to determine them itself.

For (2), authors should provide only src.url and src.sha256 in repositories.toml.

Then it'd be up to you whether you want to also support "any Git repository" as a third class of source that is then only available to users who have git available for Avogadro to make use of.

[ghutchis]

While I'd like to eventually support git checkout and cloning, for now it's probably better to keep https as the main source since most users won't have git

[ghutchis]

I think we probably don't want this in the repository. My email is everywhere, but I think some folks might not want all of this in one easy-to-spam format.

[matterhorn103]

I assume here you're talking about the authors information? That's a fair point. Thought you might need it for the plugins list, that's all.

[matterhorn103]

Would you like for the authors field to no longer be required in the plugin's pyproject.toml at all, or for it still to be mandatory and just not put into the index?

[ghutchis]

I'd want to strip e-mail addresses from the index. Having author names seems useful (e.g., do I trust this plugin?) but many people are cautious about their email address.

[matterhorn103]

@ghutchis how is the Avogadro code currently getting the README of the plugins? Via the GitHub API? If so, wouldn't it be better if the index contained the URL of the README?

I think it'd be really good if we can make the Avogadro end completely GitHub-agnostic.

[ghutchis]

@ghutchis how is the Avogadro code currently getting the README of the plugins? Via the GitHub API? If so, wouldn't it be better if the index contained the URL of the README?

Yes, right now it comes from the API, e.g. https://api.github.com/repos/openchemistry/avogadrolibs/readme

IMHO, we should be using Python modules for the APIs, e.g.
https://pygithub.readthedocs.io/en/stable/
https://python-gitlab.readthedocs.io/en/stable/