We had a discussion about this recently, but I’m coming back around:
if users have to install all plugins (including generators, xtb, etc.) everything receives the same treatment and we avoid issues with read-only AppImage, etc. (For example, I’m slightly worried about MacOS code signing since we install into the app bundle itself.)
a huge fraction of users expect a range of input generators to be included
users without open network access / installation rights may have problems with unbundled plugins
I’m leaning towards unbundling everything, perhaps with a first launch suggesting people install the input generators.
My instinct says that as long as there’s a mechanism to install plugins from file, locally, without network access, it’s fine, because whichever system administrator can take care of things.
The most important thing is not requiring network access – I don’t think there is realistically any setup where the user does not have write access to the local user data location.
I guess the other option is that generators (or other plugins) are included in the bundle, and avogadroapp copies them into the plugin directory if the user doesn’t have them. They can then be installed there.
Well I can confirm it also works like a dream on my PC, amazing job
Though speaking of permissions issues, ~/.local/share/OpenChemistry/Avogadro/pyproject.toml is set to read-only for me, despite my user being the owner of the file, making it a bit laborious to delete. Just a small oddity.
The issue with this approach that has occurred to me is that if changes are made to the avogenerators repo but no one updates the plugins repo accordingly, people using the continuous builds will have a different version to the people who install it via the plugin manager.
Yes, that’s the point of automating the plugins repository:
I guess it’s possible to look up repositories.toml but it seems much easier to just make sure that the plugins repository (and thus repositories.toml) is automatically up-to-date.
I’m thinking we’re approaching it from the wrong direction.
Rather than having plugins run checks, we would be better having a GitHub Action in avogenerators that runs when changes are merged (or once per day), that opens and merges a PR into plugins. That way we can automate any other things necessary to occur at the same time. We ought to bump the patch version number for each different version we publish to the index, for example.
I’m happy to be proven wrong, but I don’t think an action running as avogenerators can force a merge in a separate repository. OTOH, I already set up an action to run once a day in plugins to handle that.
