I don’t think you quite got my point. I get what you’re saying - that for some plugins like avo_xtb it’s much easier if it’s structured like a plugin with the .py files in a subfolder.
I’m thinking of a “skill ladder” for those willing to share scripts:
- one simple script (e.g., import XSF files or generating an x-ray diffraction pattern with pymatgen) - with some level of metadata embedded
- a few scripts in a folder potentially with dependencies (e.g.,
pymatgenorrdkit) .. most of the current plugins fall into this category - more complex script packages like
avo_xtborqupkakeorTurtleMol
You say "it’s pretty trivial to stick all the .py files in a subfolder. I understand it’s a benefit for more complex script packages. But what’s wrong with "hey, a few scripts and a pyproject.toml in a folder?
But why is the installed to an environment required? Seems like it’s possible to make it optional, in which case the existing bits are mostly compatible.
I understand where making a full Python package make it easier for some things. But if someone wants to share one or four scripts in a GitHub repo, they have to put together a subdirectory, create an __init.py__ etc. No, that’s not a huge barrier, but my point is that it doesn’t need to be a barrier at all if “installed to an environment” is optional.
Structure your plugin however you want, put files where you want, do imports however you want, share logic however you want, just make sure
that pip/hatch/uv/pixi/any installer can install itit and any dependencies are installed if needed and commands respond appropriately when run