Paketierung von FHEM-Modulen

Markus Bloch · 22 Februar 2016, 21:01:21

Hallo zusammen,

als ich beim Usertreffen in Karlsruhe vergangenes Wochenende war, hat Thorsten Pferdekämper bei seinem Vortrag auf die Möglichkeiten des update-Mechanismus mit verschiedenen Update-Streams hingewiesen, sowie deren Vorteile erläutert. Dies hat mich auf folgende Idee gebracht.

Warum diese Möglichkeit nicht dahingehend nutzen und die Vielzahl der Module, die aktuell in FHEM standardmäßig ausgeliefert werden in logische Gruppen einordnen und daraus eigene Update-Streams erzeugen. Man würde damit die schiere Anzahl der Module reduzieren und User würden nur noch die Modulpakete via "update add ..." einbinden, die sie wirklich brauchen.

Ich denke dabei an beispielhaft folgendes.

Paket "Multimedia": MEDIAPORTAL, SONOS, SONOSPLAYER, YAMAHA_AVR, ONKYO_AVR, YAMAHA_BD, ENIGMA2,...
Paket "TV": STV, PHTV, LGTV
Paket "HomeMatic": CUL_HM, HMLAN, HMinfo
Paket "panStamp" : panStick, SWAP, SWAP_xxxxxxyyyyyy, ...
Paket "1-Wire": OWX, OWFS, OWX_xxx, OWServer, OWSWITCH, ...
Paket "Firmata" : FRM, FRM_AD, FRM_I2C, FRM_OUT, ...
Paket .... usw.

In jedem Paket wären dann auch die entsprechenden Abhängigkeiten dabei im Sinne von XML-Files, Perl-Module, Libraries, Sketches, usw.

Wenn ein User anfangen möchte 1-Wire zu benutzen, führt er ein "update add 1-Wire" aus und damit ist das Paket mit Modulen im normalen update-Prozess eingebunden und die Module werden geladen. Ebenso bei anderen Paketen. Somit kann man sich seine Installation Step-By-Steb aufbauen und nach und nach ergänzen.

Auf fhem.de müsste man dann eine Datei mit allen Paketen, einer Beschreibung und der controls.txt-URL pflegen, die man sich dann per update-Befehl auflisten kann.

Folgende Vorteile sehe ich:

- kleineres Installationspackage
- kleinere und übersichtlichere Commandref die nur die Module/Pakete beinhaltet, die man auch wirklich brauch. Dadurch einfacher für den Einsteiger zu verstehen, da die Modulanzahl bei der Grundinstallation deutlich sinkt.
- Trafficeinsparungen beim täglichen Update auf fhem.de (??)

Man müsste einmalig eine Definition solcher Pakete machen. Ich würde vorschlagen sich auf eine technische Rubrik (bei vielen unterschiedlichen Modulen) oder dem Namen (bei einer großen Modulfamilie wie 1-Wire, Firmata) zu beschränken.

Was haltet ihr davon?

Gruß
Markus

betateilchen · 22 Februar 2016, 21:21:00

auf dem gleichen Gedankengang kaue ich seit Samstag auch rum, ich finde die Idee ziemlich gut.

Sidey · 22 Februar 2016, 21:27:49

Ich finde auch, dass es eine gute Idee ist.
Wir sollten dem Anwender nur einfach ermöglichen, diese Features zu aktivieren oder zu deaktivieren.

Grüße Sidey

Markus Bloch · 22 Februar 2016, 21:42:19

Momentan ist es ja so, dass es im Forum viele User gibt, die ein Modul/Feature entwickeln (bspw. auf github) und dies über eine eigene controls.txt anbieten. Die URL schwirrt dann irgendwo in einem bestimmten Thread rum. Nur wenn man den Thread liest, kommt man an die URL und somit an die Dateien.

Wenn man nun eine zentrale Liste führt, sowohl offizieller "Modulpakete" als auch solcher Dritt-Module durch Forumsuser, hat man eine zentrale Stelle wo alle Repositories gesammelt sind und dem User zentral zum Abruf bereitstehen (z.B. per update-Befehl).

Gruß
Markus

Loredo · 22 Februar 2016, 21:43:15

Klingt sehr überlegenswert.
Vor allem aber finde ich es attraktiv, weil man damit endlich (teilweise) auf Git umsteigen kann.
Das einzige, was mich daran stören würde ist, dass ich selbst gerne auf Github arbeiten würde, sich so ein Paket aber wohl aus esoterischen Gründen (ja trotz der realen SF Erfahrungen) unbedingt auf einem privat gehostetem Server befinden soll/muss, was ich so lese...

Gruß
Julian

Markus Bloch · 22 Februar 2016, 21:48:00

Zitat von: Loredo am 22 Februar 2016, 21:43:15
Das einzige, was mich daran stören würde ist, dass ich selbst gerne auf Github arbeiten würde, sich so ein Paket aber wohl aus esoterischen Gründen (ja trotz der realen SF Erfahrungen) unbedingt auf einem privat gehostetem Server befinden soll/muss, was ich so lese...

Kommt drauf an wie man es organisiert. Kannst ja auch den raw-Link zu deinem controls.txt auf github nehmen. im FHEM-SVN müsste man aber mindestens deine URL aufnehmen. Jenachdem wie man es serverseitig verwaltet.

Gruß
Markus

Loredo · 22 Februar 2016, 21:58:53

Naja ich denke schon, dass es Sinn macht das nicht zu weit zu zerstreuen, also beispielsweise sich generell auf Github zu einigen, um dann dort auch Pull-Requests nutzen zu können. Auch der Bugtracker wäre toll für das sammeln, abarbeiten und priorisieren von Features.

Dazu gehörte aber auch einmal darüber nachzudenken, ob die Art wie aktuell neue Versionen von FHEM ansich veröffentlicht werden, so sinnvoll ist. Ich würde gerne im develop-Branch regelmäßig neue Versionen einchecken und das sollte die bleeding edge sein, während der User sich aber auch fûr den stabilen master-branch entscheiden kann. Wenn es nun aber zig parallele Repos gibt, dann wird es schwer ggf. Merges in den master-Branch abzustimmen (die Kategorien-Einteilung am Anfang kann ja nur eine Momentaufnahme sein).

Also je mehr ich darüber nachdenke, desto mehr Entscheidungen sollten damit gleichzeitig fallen, ganz gleich ob sie sofort umgesetzt werden, wichtig ist die Vision dahinter (und ich meine die ohne den Arzt

).

Gruß
Julian

justme1968 · 22 Februar 2016, 21:59:27

die idee an sich ist klasse. ich glaube etwas in der art ist noch mehreren durch den kopf gegangen.

aber... bei der aufteilung in pakete muss man glaube ich etwas anders vor gehen.

z.b.: alle tv module in einem paket zu haben ist nicht wirklich sinnvoll. die meisten haben vermutlich nur einen fernseher und wenn es doch zwei sind wahrscheinlich vom gleichen hersteller. es würde also nur ein paket aus der liste gebraucht. das gleiche für multimedia: mehrere avrs ist eher unwahrscheinlich, mediaportal und plex und kodi gleichzeitig auch, ... d.h. am ende installiert man doch wieder ein komplettes paket um ein modul zu bekommen.

bei den homematic, 1-wire und firmata paketen passt es sehr viel besser.

vielleicht bieten sich die 2 stufigen module überhaupt besser an? auf der anderen seite: ich vermute die mehrzahl der der jeelink anwender verwendet nur LaCrosse oder nur PCA301 und nicht beides.

aber: wenn man anfängt die installation zu modularisieren warum nicht gleich bis runter auf modul ebene und bei installation eines moduls werden die nötigen fhem abhängigkeiten mit installiert. um die abhängigkeiten zu bestimmen ist es vermutlich besser das aus den modulen zu lesen statt extra dokumente dafür zu pflegen.

das mit der kleineren commandref ist so eine sache... ich finde immer noch eine grosse commandref besser um darin zu suchen. unter anderem auch welche module es eventuell noch gibt. das ist meiner meinung nach ein grosses minus nicht alles dort stehen zu haben.

wenn man nur den traffic reduzieren will könnte man update auch so ändern das im normale fall nur das control file, die gerade verwendeten und komplett neu dazu gekommene module aktualisiert werden. beim define eines moduls könnte dann ein hinweis erscheinen wenn die lokale version nicht aktuell ist oder sogar direkt geholt werden. das hätte fast die gleiche trafic reduzierung zur folge ohne eine gänzlich unvollständige commandref zu haben

gruss
andre

justme1968 · 22 Februar 2016, 22:01:41

ich sehe nicht das für eine modularisierung git oder github nötig sind. das vermischen beider diskussionen sehe ich eher kontraproduktiv da die abneigung gegen eine der beiden die andere negativ beeinflusst.

und ja: github hat ein paar vorteile. aber git selber, das branchen, mergen und verteilte repositries gehören definitiv nicht dazu.

Markus Bloch · 22 Februar 2016, 22:03:36

Zitat von: justme1968 am 22 Februar 2016, 21:59:27
das mit der kleineren commandref ist so eine sache... ich finde immer noch eine grosse commandref besser um darin zu suchen. unter anderem auch welche module es eventuell noch gibt. das ist meiner meinung nach ein grosses minus nicht alles dort stehen zu haben.

Dafür kann man nachwievor auf fhem.de die vollständige commandref einsehen und suchen. Sehe ich daher nicht umbedingt als Nachteil.

Gruß
Markus

justme1968 · 22 Februar 2016, 22:08:47

bei den schwierigkeiten die es jetzt schon mit der commandref bei manchen gibt glaube ich nicht das es eine gute idee ist so sehr unterschiedliche versionen zu haben. der unterschiedliche umfang der deutschen und englischen sorgt ja schon für probleme.

gruss
andre

rudolfkoenig · 22 Februar 2016, 22:51:18

Ich habe kein Problem damit, weniger Module zu verteilen, ich sehe aber hier einige noch zu loesende Probleme:
- usb scan / autocreate
- wenn jemand im Wiki/Forum was liest, dann muss er vorher rausfinden, in welchem Paket die Zutaten sich befinden, um sie vorher herunterladen zu koennen. Das wird fuer viele Anfaenger ein KO sein. Wenn das automatisch in LoadModule erfolgen soll, dann braucht man ein aktuelles Verzeichnis und Internet.
- wenn ein Modul nach einem update ein neues Hilfsmodul braucht, dann muss zusaetzlich nachgeladen werden.
- manche Attribute sind im commandref nur einmal definiert, sonst nur verlinkt.
- wer/wie definiert man Pakete.

@Loredo: ein stable und dev Branch kann jeder auf seinem Server anbieten. Nur ich mache da nicht mit, ich habe keine Energie dafuer: Weder fuer solange Testen, dass ich mit ruhigen Gewissen dazu "Stable" sagen kann, noch fuer Backports von dev nach stable, oder beim Support rauszufinden, wer welche Staende wie gemischt hat, damit ich das richtig nachstellen kann.

Loredo · 23 Februar 2016, 09:52:17

Zitat von: rudolfkoenig am 22 Februar 2016, 22:51:18
@Loredo: ein stable und dev Branch kann jeder auf seinem Server anbieten. Nur ich mache da nicht mit, ich habe keine Energie dafuer: Weder fuer solange Testen, dass ich mit ruhigen Gewissen dazu "Stable" sagen kann, noch fuer Backports von dev nach stable, oder beim Support rauszufinden, wer welche Staende wie gemischt hat, damit ich das richtig nachstellen kann.

Ich sehe da jetzt keinen Unterschied dazu, dass du alle Jubeljahre mal sagst "so, hier ist ein ZIP und ich nenne es Version x.y". Das entspricht dem, was im Master-Branch ist. Ein Dev-Branch entspricht dem aktuellen Entwicklungsstand wie bisher auch im SVN. Nur sagst du eben dann nicht mehr "hier ist ein ZIP File", sondern mergst einfach bei Zeiten den aktuellen Dev-Branch einmal in den master-Branch (siehe z.B. git-flow).
Deshalb spreche ich es ja an, es bedürfte hier einer klaren Abstimmung wann man diesen Merge machte, wenn es kein einzelnes, zentrales Repository mehr gäbe.

Zitat von: justme1968 am 22 Februar 2016, 22:01:41
ich sehe nicht das für eine modularisierung git oder github nötig sind. das vermischen beider diskussionen sehe ich eher kontraproduktiv da die abneigung gegen eine der beiden die andere negativ beeinflusst.

Nötig nicht, aber ich finde das ist der richtige Zeitpunkt darüber zu sprechen. Ich verstehe weshalb du das trennen möchtest. Eine Aufspaltung und so große Dezentralisierung sollte aber auch zunächst als Kernelement der Diskussion beinhalten, wie zusammengearbeitet werden kann und soll. Sonst reden wir hier wieder nur über die Technik und welche Vorteile es so oder so hätte. Die Organisation sollte aber nicht zu kurz kommen, das wird sie IMHO leider hier zu oft.

justme1968 · 23 Februar 2016, 11:18:43

es sind aber erst mal zwei logisch getrennte dinge die hier angesprochen werden:
- die organisation in paketen/modulen/was auch immer die für den endanwender und für installation und updates relevant sind
- die organisation des repositories und die zusammenarbeit mehrerer entwickler

das eine kann einfluss auf das andere haben und es gibt sicher auch überlappungen. aber für beides den gleichen mechanissmuss zu verwenden muss bei weitem nicht die optimale lösung sein. und selbst wenn es eng verzahnt ist wie z.b. bei npm und github ist das nicht unbedingt optimal.

die möglichkeiten die es bei npm/github gibt dinge zu strukturieren und pakete inklusive abhängigkeiten automatisch zu installieren sind für einen entwickler klasse. reine anwender sind damit aber sehr oft überfordert.

und git selber ist wirklich geschmackssache und ich finde z.b. das fhem entwicklungsmodell sehr viel besser. vor allem das es ein definitives repository gibt in dem die aktuelle version steht. alle andere ist für einen 'nur' anweder eine katastrophe wenn er sich durch x clones und forks suchen muss um von diversen modulen genau die version zu erwischen die sein problem löst, die aber untereinander nicht zusammen arbeiten. been there, done that, hate it!

das werkzeug sollte nicht das entwicklungsmodell vorgeben sondern passend zum gewünschten modell ausgesucht werden.

es wäre schade wenn die sehr persönlichen meinungen die es zu git gibt auch die diskussion zu modularisierung von installation und update abblocken.

gruss
andre

ps: ich möchte noch mal anregen das ganze bis auf fhem modul herunter zu betrachten. für viele dieser module gibt es keine sinnvollen pakete.

rudolfkoenig · 23 Februar 2016, 11:58:05

ZitatIch sehe da jetzt keinen Unterschied dazu, dass du alle Jubeljahre mal sagst "so, hier ist ein ZIP und ich nenne es Version x.y".

Fuer mich sind die Unterschiede aber deutlich. Ein Release als .ZIP hat folgende Gruende:
- wesentliche Aenderungen von update bzw. fhem.cfg ins Initialpaket aufzunehmen.
- die Menge der Dateien, die beim ersten update runtergeladen werden, zu minimieren.

Die Formulierung "Stable-Branch" impliziert, dass es stabil ist (was durch Tests bewiesen wurde), und dass fuer diesen Branch separate Fixes gibt. Ich will sowas nicht machen, und deswegen auch nicht behaupten.