make plug types (entrypoint groups) inventor agnostic

[emphasize]

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

ovos-plugin-manager/ovos_plugin_manager/utils/__init__.py

Lines 23 to 44 in 68ec25f

	class PluginTypes(str, Enum):
	PHAL = "ovos.plugin.phal"
	ADMIN = "ovos.plugin.phal.admin"
	SKILL = "ovos.plugin.skill"
	VAD = "ovos.plugin.VAD"
	PHONEME = "ovos.plugin.g2p"
	AUDIO = 'mycroft.plugin.audioservice'
	STT = 'mycroft.plugin.stt'
	TTS = 'mycroft.plugin.tts'
	WAKEWORD = 'mycroft.plugin.wake_word'
	TRANSLATE = "neon.plugin.lang.translate"
	LANG_DETECT = "neon.plugin.lang.detect"
	UTTERANCE_TRANSFORMER = "neon.plugin.text"
	METADATA_TRANSFORMER = "neon.plugin.metadata"
	AUDIO_TRANSFORMER = "neon.plugin.audio"
	QUESTION_SOLVER = "neon.plugin.solver"
	COREFERENCE_SOLVER = "intentbox.coreference"
	KEYWORD_EXTRACTION = "intentbox.keywords"
	UTTERANCE_SEGMENTATION = "intentbox.segmentation"
	TOKENIZATION = "intentbox.tokenization"
	POSTAG = "intentbox.postag"
	STREAM_EXTRACTOR = "ovos.ocp.extractor"

[JarbasAl]

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]

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

• "ovos.ocp.extractor" -> "ovos.plugin.ocp.extractor"
• "intentbox.XXX" -> "intentbox.plugin.XXX"

[emphasize]

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]

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]

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]

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.