skill plugins

[JarbasAl]

companion discussion MycroftAI/mycroft-core#2958
sample implementation NeonJarbas/NeonCore@0735033

my proposal is that "system skills" are skills that are crucial for core operation, core just doesnt work without them.

I contend that those should be separated from user skills and handled by the package manager, defined in requirements.txt and optimized for a specific (major) core version. Having core functionality available should not depend on downloading external files

where to port this:

• ovos-core
• HolmesV
• mycroft-core

list of ovos system skills: (TODO add links)

• homescreen skill
• wifi skill
• pairing skill
• volume skill
• stop skill
• unknown skill
• enclosure skill

other candidate skills

• common_play/query
• homescreen skills for other platforms

[JarbasAl]

https://github.com/OpenVoiceOS/ovos-skills-info is also a good candidate

[JarbasAl]

i suppose system and default skills are the same and could use this approach, i mainly do this differentiation because i dont think things like jokes skill should be a default, or anything that would likely be replaced/removed by the user (eg, pandora skill only works in USA and is/was a default skill)

the main distinction is user vs package manager skills, unless mycroft-core changes all skills to this new scheme we need to support both in OVOS, i would define a user skill as a skill not handled by the package manager

[PureTryOut]

Ah I normally define "system" as something that is installed system-wide, e.g. somewhere in /usr, and "user" as something that is installed to the person's home directory, so somewhere in $HOME. Maybe it's good to get a clear definition first then?

Something like "core" for skills that are installed by default which includes ones absolutely necessary to run and "non-core" for the rest?

[JarbasAl]

the less confusion the better, so lets avoid the system/user nomenclature, core/non-core is fine for me

[ChanceNCounter]

For the sake of having commentary in the same place, I'm gonna repeat something I said in one of the other discussions: how a skill is distributed, and how users interact with the distribution channels, should boil down to how we conceive of a skill.

If skills are libs (or deps in general) they can, and perhaps should, be distributed and updated as such. That certainly applies to skills on which core depends, as well (probably) as platform-appropriate framework skills.

The majority of skills, though, are more like applets, for which the "app store" paradigm makes sense to devs and is familiar to users. It also makes it much easier to identify, as a user, the source and trust model of the software they're installing.

I think this could be a useful, loose measure for how to implement/classify something:

Is it intrinsic to your version of Core? --> Plugin
Is it meant for inheritance? --> Plugin
Is it now a plugin that also needs to be a skill? --> Publish as plugin
Is it still Not a Plugin? --> Skill

[PureTryOut]

That sounds fine. Trickles down then to skills for end users, plugins for non-user visible "skills".

[JarbasAl]

this is now live at OpenVoiceOS/ovos-core#9

additionally multiple skill directories support has also been implemented and already merged, full XDG support + "classic" directory + user defined extra paths

[j1nx]

Do we want to include our default skills as plugins already for the next upcoming pre-release? At the moment, the image ships with the default skills installed within the /home/mycroft/.local/share/mycroft/skills/ directory.

Default included skills as plugin will ship as /usr/lib/pythonX.X/site-packages/ however the mycroft user does not have write acces to that folder, so we have to make sure when the user updates/upgrades the skill the command should be; pip install --upgrade ". That way it gets installed within the /home/mycroft/.local/lib/pythonX.X/site-packages/ folder and over rule the system wide installed skill.