search

OpenVoiceOS / ovos-plugin-manager

plugin manager for OpenVoiceOS , STT/TTS/Wakewords that can be used anywhere
Apache License 2.0
12 stars 11 forks source link

make plug types (entrypoint groups) inventor agnostic #144

Open emphasize opened 1 year ago

emphasize commented 1 year ago

I guess this would be a task rigth before 1.0.0, but just to get it out. On the flipside, already a pain in the ass to change now, it doesn't get better with time.

in a multiplatform framework we shouldn't goup the plugins containing the platforms' name

https://github.com/OpenVoiceOS/ovos-plugin-manager/blob/68ec25f416c55cfc3944414c8f49a57330580ec3/ovos_plugin_manager/utils/__init__.py#L23-L44

JarbasAl commented 1 year ago

note that those are not the platform, OPM pugins all can be used standalone, those are the authors of the reference implementation, ie, who invented the base class

its a namespace of the reference framework we ensure compatibility with, if we for example extend a class to become incompatible with mycroft we then would change the namespace from mycroft.xxx to ovos.xxx

JarbasAl commented 1 year ago

we should however for consistenct add .plugin to all of them, seems the ones missing it are used in very little repos or WIP stuff, so def should update

emphasize commented 1 year ago

I just don't think it's the place for that. It is a group descriptor of the plugin type Has to be documented

emphasize commented 1 year ago

Furthermore, reading org discussion 142

Mycroft Neon and OVOS all adopt naming convention for plugins opm-xxx-plugin-yyy (stop using ovos / neon / mycroft in their naming)

indicating this is already planned as a package naming convention. This should also be reflected here.

JarbasAl commented 1 year ago

Furthermore, reading org discussion 142

Mycroft Neon and OVOS all adopt naming convention for plugins opm-xxx-plugin-yyy (stop using ovos / neon / mycroft in their naming)

indicating this is already planned as a package naming convention. This should also be reflected here.

that convention would depend on buy in from the others cores and imply a large refactor across many repos across orgs

ping @NeonDaniel

NeonDaniel commented 1 year ago

I think it makes sense to standardize entrypoint names, but the main issue will be keeping backwards-compat for some duration (presumably until 1.0.0).

In the event there is a breaking change to some plugin implementation (i.e. I define a neon.stt.plugin.precognition), I think it makes sense that such a plugin isn't handled in OPM factory methods.