Combined plugins & plugin list

[ghutchis]

@matterhorn103

Well the issue is that then you don’t have any metadata.

But you’re proposing that metadata can be included in the script file, right?

@matterhorn103

I mean, it’s already not possible to submit just a script by itself for distribution – we require the git repo to have a plugin.json file in it. So we are already requiring a distribution container

The main point of this was to make it pretty easy to have a folder that’s a set of scripts. Put them in a repo and add a fairly simple JSON with the metadata.

I’ve spent a good amount of time looking at research code - from my own group and from other groups.

While I think it’s important to promote good coding practices, I’d like to create a useful “contribution ladder” from “I made a script to generate XRD patterns” to much more sophisticated plugins like xtb. For example PyMol has a huge range of plugins from simple scripts to use of PyQt interfaces.

So if there’s a good way to include the metadata in a simple script, I’d be in favor of allowing a GitHub / GitLab / whatever repo with just a script or three and a README.

Now part of your proposal centers around more sophisticated packages, and suggesting some structure for those is a good idea. That’s also part of the need to create more examples so people can adapt them.

@matterhorn103

I’m just proposing to use a more standard format that allows us to use pixi install.

We can use pixi install on anything that has a pyproject.toml. Certainly I’d suggest plugins start using that, and I’m willing to use that as a metadata mechanism instead of the JSON file.

@matterhorn103

Why rely on the directory tree structure?

In many cases, it’s faster because the code doesn’t need to load them. 99% of the time, I don’t need to load charge plugins. Probably 50% of the time I don’t need to load energy plugins.

Also, given the list of things I need to write up, there will probably be 20-30 plugins. Having some directory structure for people makes it a bit easier IMHO.

@matterhorn103

I suggest it because having each script in a plugin be independent and run separately makes things challenging once you need common functionality.

Sure. But again, I think there’s a continuum of things from “I just want to run this one thing with pymatgen” to something like xtb which uses a bunch of common functionality. That’s why I think you’re describing a new category.

I don’t think it’s crucial to separate though. pixi allows tasks, which could be separate scripts or one entry point: Tasks - Pixi by prefix.dev

I agree that we’re on the same page as far as reducing friction. I think I’m coming from the pragmatic “I’d love people to start with a template but think that will be a mental barrier for many.”

Moreover, I think having slightly different plugin types makes it a bit easier on the C++ side. Let’s say that I want to add --batch-energy and --batch-optimize methods to the energy plugins. Right now, I can do that pretty easily. Those plugins are supposed to supply some metadata to Avogadro about their capabilities. I’m less clear on how that works in your universal proposal.

Part of the current complexity is that most useful plugins want some dependencies. That’s why pixi is great because it can pixi install an environment for pytorch for ML plugins or whatever else is needed.

Plugins need to be called at launch right now to make sure they can actually function in the current Python environment. For example if you don’t have pymatgen then don’t show those commands.