Repository navigation
Strukturera om koden till en plugin arkitektur #92
Description
Något vi pratat om är att strukturera koden så att alla actions byggs om till en pluginstruktur, tex så läggs all kod som tillhör marvin väder i en klass (eller motsvarande) och alla pluginer som ligger i en viss katalog läses in automatiskt vid uppstart och blir en del av den körande boten.
Strukturen för en plugin kan tex vara en klass med en metod som "gör allt" men att författaren till pluginen tillåts dela upp koden fritt i klassen. Eller så har vi en mer tydlig struktur för hur en plugin-klass skall se ut (förenklar troligen kodgranskning).
En plugin skulle kunna vara en katalog med många filer men jag lutar åt att vi håller det enkelt (för kodgranskning...) och tillåter att en plugin är en fil och den skall innehålla all kod inklusive förklarande docstrings. Om det finns variantern i svaren som "hej" eller "tjena" så måste det extraheras ur klassen (på något sätt) och placeras som en egen enhet (i klassen, eller ovan klassen, men i samma fil).
Lite osäker på vilka krav man skall ställa på pluginen när det gäller test, men det bör vara vältestat och stödja regressionstester.
Tanken är att skriva om koden på en gång så att marvin blir "tom" och sen är allt pluginer så det blir ju en rejäl strukturell förändring, men det känns inte orimligt att göra på det viset.
Om man kikar på min PR där jag uppdaterade marvin väder så var det 8 filer som behövde ändras. Tanken är alltså att vi kommer ned till 2 filer, själva pluginen och testerna mot den.
Jag ser nu i koden att vi kallar det för "actions" där marvin väder är en action. Alla actions skall alltså hanteras som en plugin.
Activity
kh31d4r commentedon Sep 24, 2026
Jag tänker mig att vi har en basklass för pluginer som bestämmer själva interfacet, idag är det väl bara en function som körs varje gång det kommer in en rad text, men man skulle ju kunna utöka det med en funktion som körs när pluginet laddas (om man vill förladda någon cache eller något) och kanske någon funktion som bara körs en gång om dagen eller liknande.
Sedan kan man packa det i ett antal python paket som man installerar i miljön är botten ska köras, och för att ladda in pluginerna behöver man bara scanna miljön efter subklasser av basklassen för alla pluginer. Så ett pythonpaket kan innehålla en eller flera pluginer, och en eller flera sådana pythonpaket kan vara installerade samtidigt.
Då borde själva bot-koden och marvin-koden vara kanska oberoende av varandra. Testerna borde inte påverkas nämnvärt, de använder bara det som är tänkt att vara interface in pluginen iaf, och idag är alla actions i praktiken stateless.