Packages vs Plugins in Interface

Development Design & Interface
1

@brockdyer03 submitted a pull request to use “plugins” for where packages / plugins are installed:

I don’t particularly care whether it’s “packages” or “plugins” but want to make sure there’s some agreement so the code can get finished up for release. :slight_smile:

“plugins” or “packages”

2

So people don’t have to go to the GitHub to see my reasoning, I’m copy+pasting it here:

To briefly explain the reason behind renaming the plugin install directory, I just found that in general it is more obvious to a user to look for a directory called “plugins” than “packages” since “packages” is

  1. More broad than just an Avogadro plugin (it could be a Python package that is a dependency of a plugin)
  2. Specifically a type of Python plugin
  3. Not the name that is most commonly used on the forum, where most users will be looking
  4. Generally more descriptive of what the plugins are.
1 Like
3

I’m fine with “plugin” - I just want to make sure everyone is on-board, because I think @matterhorn103 and I have been referring to them as “packages” .. and we should get the terms straight. :slight_smile:

1 Like
4

If I understand the current implementation correctly, I’d say “plugins”, for sure.

But to clarify:

  • Unless something has changed, we are supporting plugins that consist of scripts, right? What I have been referring to in various places as pyscript plugins?

  • Script plugins are definitely not Python packages in either of the two usual senses.

  • So my question would be, where are pyscript-type plugins saved to? And where would hypothetical Julia plugins be saved to, or binary ones (which I’m keen for Avogadro to support in the near future, at least for local installation)?

    • If the answer is “the same directory”, then I don’t think “packages” is the correct catch-all term

  • “package” would also be a third term on top of “extension” and “plugin” that’s used in the code, documentation, forum etc. to refer to very similar concepts

5

I think it’s best to say:

Avogadro is extended by plugins that can be downloaded using the plugins manager and can be uploaded to the Avogadro/plugins repo

I think it’s also reasonable to say:

one of the forms that a plugin can take is a Python package

In this case “package” retains its usual Python meaning. But that refers then to a specific subset of plugins, not all of them.

What I had originally envisaged the directory structure to look like was something like:

OpenChemistry/Avogadro
├── autosave
└── plugins
    ├── bin
    │   └── fortran-nonsense
    ├── pypixi
    │   └── avo_xtb
    ├── pypkg
    │   └── avogenerators
    └── pyscript
        └── simplecommand

or

OpenChemistry/Avogadro
├── autosave
└── plugins
    ├── bin
    │   └── fortran-nonsense
    └── python
        ├── avo_xtb
        ├── avogenerators
        └── simplecommand

At the moment it seems to be the case that all plugins are stored in a single directory, regardless of type? I.e.:

OpenChemistry/Avogadro
├── autosave
└── plugins
    ├── fortran-nonsense
    ├── avo_xtb
    ├── avogenerators
    └── simplecommand

which is also an entirely reasonable approach.

So yes, I’d definitely go for plugins wherever the term is meant to refer to all kinds of plugins.

6

I thought the idea was to minimize subdirectories to make it easier for anyone to find the appropriate place to put plugins.

It should be easy enough from the metadata files (e.g., pyproject.toml or avogadro.toml) to figure out how to install and run things.

1 Like
7

Yeah, that makes a lot of sense.