Anfrage Erweiterung der Verzeichnisstruktur

Begonnen von CoolTux, 12 Mai 2020, 09:05:22

Vorheriges Thema - Nächstes Thema

CoolTux

Hallo Rudi,
Hallo FHEM Entwickler,

Es war ja schon in einem anderen Thread ersichtlich das ich etwas mit packages und dem damit verbundenen Verzeichnisstrukturen experimentiere.
Nun bedeutet ein kleiner Rückschlag ja nicht gleich das ich aufgebe. Und somit habe ich beschlossen das ganze mit einem Modul zu testen welches kein BlockingCall verwendet und wo es definitiv mehr wie Sinn macht es entsprechend auf zu teilen. Ich habe mich für AutoShuttersControl entschieden.

Doch bevor ich nun meine Zeit und Mühe investiere steht natürlich die generelle Frage im Raum ob ein solches Vorhaben auch unterstützt wird.
Hier geht es erstmal darum das in Zukunft die Verzeichnisstruktur bei einem Update auch mit verteilt werden muss.

Auf Basis meines erlesenen und was ich so bei anderen Projekten sehe wäre das

lib/

inklusive allen Unterverzeichnissen.

Für AutoShuttersControl wäre meine Idee folgende Struktur

Zitatlib/Automation/AutoShuttersControl.pm
lib/Automation/AutoShuttersControl/ASC_Shutters.pm
lib/Automation/AutoShuttersControl/ASC_Shutters/Attr.pm
lib/Automation/AutoShuttersControl/ASC_Shutters/Readings.pm
lib/Automation/AutoShuttersControl/ASC_Window.pm
lib/Automation/AutoShuttersControl/ASC_Window/Attr.pm
lib/Automation/AutoShuttersControl/ASC_Window/Readings.pm
lib/Automation/AutoShuttersControl/ASC_Roommate.pm
lib/Automation/AutoShuttersControl/ASC_Dev.pm
lib/Automation/AutoShuttersControl/ASC_Dev/Readings.pm
lib/Automation/AutoShuttersControl/ASC_Dev/Attr.pm

Es wäre vorerst ein Experiment, sollte es aber klappen würde ich mich über eine derartige Struktur und dessen Auslieferung sehr freuen.
Und natürlich wäre es auf Basis dieser Struktur einfach entsprechende Unit-Tests zu erstellen.

Also, wie steht Ihr dazu. Hat mein Anliegen eine Zukunft?


Grüße
Marko




aktueller Status:

Zitat von: rudolfkoenig am 16 Mai 2020, 12:02:42
Es fehlt immer noch eine grobe Festlegung der Verzeichnis- bzw. Package-Struktur.
Da trotz mehrfacher Aufforderung keiner damit rausgerueckt ist, muss man mit meinem Vorschlag hier leben.

- $attr{global}{modpath}/lib wird am Anfang von @INC aufgenommen, hier befindliche Dateien werden mit update ausgeliefert.
- eine maximale Tiefe der Unterverzeichnisse ist nicht spezifiziert, auf Betriebsystemgrenzen ist zu achten.
- lib/FHEM ist nicht erlaubt.
- jede Datei in lib ist in MAINTAINERS.txt einzutragen, lib/dir/* ist ok.
- weder help noch commandref_join interessieren sich fuer Dateien in lib, das heisst aber nicht, dass man da kein =pod Abschnitt hinterlegen darf.
- in lib befinden sich nur Dateien mit der Endung .pm, sie muessen alle mit "svn propset svn:keywords Id" markiert werden.

Wenn jemand die Zeit un Energie hat fuer mehr Ordnung zu sorgen (z.Bsp. um Namenskollisionen mit CPAN Paketen zu vermeiden), dann  moege sich melden.

Ich werde fhemupdate.pm, perl, pre-commit und was ich sonst noch pflege, erweitern, meine Zielvorgabe ist bis Ende naechster Woche.

Wegen einer Verzeichnisstruktur wird noch diskutiert.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

Bedeutet fuer mich nicht unversentliche Arbeiten an 98_update.pm und fhemupdate.pl, und vmtl auch fhem.pl.
Weiterhin kommt Support dazu.

Ich will solchen Bestrebungen nicht im Weg stehen, aber bevor ich die Arbeit investiere, haette ich gerne
- Absichtserklaerung von mehreren Maintainer, dass sie Ihre Module so umbauen wollen
- eine halbwegs abgestimmte Verzeichnisstruktur. Beachte, dass in FHEM/lib bereits jetzt was Vergleichbares existiert

So ein Verzeichnisstruktur wird keine Einladung fuer Reinkopieren von CPAN Modulen sein.

CoolTux

Drei Zustimmungen hat mein Post bereits  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Nun ja, ich habe die Absicht, die im Moment in lib/Device/MySensors vorhandenen .pm abzuschaffen und diesen Zweig zu löschen... (Auf die Frage, ob das zielführend ist, hatte ich leider keine Antwort erhalten und daher beschlossen, diese bisher scheinbar hier eher als exotisch angesehene Struktur abzuschaffen, zumal es afaik in der Vergangenheit keine Anknüpfungspunkte gab, diese beiden generischen Modulbestandteile irgendwie "mit der Außenwelt" abzugleichen; ich weiß daher nicht, ob je via cpan was anderes oder "besseres" verteilt wurde).

Muß aber für andere Maintainer nichts heißen...

Gebe nur zu bedenken, dass es für willige Helfer unter den Usern ggf. noch schwieriger wird nachzuvollziehen, wo man genau eingreifen muß und was wie austauschen, um zu testen. (War ja bisher schon für einige eine große Hürde, das wird sicher nicht besser).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

ZitatGebe nur zu bedenken, dass es für willige Helfer unter den Usern ggf. noch schwieriger wird nachzuvollziehen, wo man genau eingreifen muß und was wie austauschen, um zu testen. (War ja bisher schon für einige eine große Hürde, das wird sicher nicht besser).
Sehe ich ähnlich. Wer blickt da noch durch, außer dem dann irgendwann verschwundenen Maintainer ?  :-\

ZitatEs wäre vorerst ein Experiment
Und wo liegen die riesen Vorteile für dieses Experiment, das Rudi scheinbar ne Menge Arbeit aufhalsen würde ? Wo ist das Gesamtkonzept ? Was bedeutet das für andere Module ? Ist das dann nur etwas für sehr komplexe Module ?

Ich kenn das Verzeichnis .../lib/.... bisher nur im Zusammenhang mit CPAN-Modulen, die dann FHEM-spezifisch modifiziert wurden(UPnP). Es bekäme ja dann eine völlig andere Bedeutung.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

CoolTux

Es ist nicht nur für komplexe Module gut sondern auch für einfache Module welche aber umgestellt sind auf package.
Dadurch können diese Module besser mit Tests versorgt werden. Ich selbst sehe in meinem Beispiel das ich mehr Überblick über ASC bekomme, ich überblicke besser wo ich Änderungen gemacht habe und welche Einflüsse diese haben.
Kann mir vorstellen das es bei anderen Modulen, auch so sein kann.

Das ist aber eher so mein persönliches Befinden, ob andere das auch so sehen müssten sie wohl selbst raus finden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

ZitatIch kenn das Verzeichnis .../lib/.... bisher nur im Zusammenhang mit CPAN-Modulen, die dann FHEM-spezifisch modifiziert wurden(UPnP).
CPAN Module sollten mittelfristig nicht mehr im FHEM-Paket ausgeliefert werden, so wie eigentlich auch alles Andere, was nicht von FHEM-Autoren gebaut wurde, und nur aus Bequemlichkeit reinkopiert wurde.

Beta-User

Zitat von: CoolTux am 12 Mai 2020, 11:35:57
Es ist nicht nur für komplexe Module gut sondern auch für einfache Module welche aber umgestellt sind auf package.
Vielleicht ist das zu naiv gedacht, aber RandomTimer ist auch auf package umgestellt. Der ist sicher sehr viel einfacher aufgebaut, aber alleine die Umstellung als Argument gelten zu lassen kommt mir etwas wenig vor.

Was ich teils gesehen habe: Manche heutigen .pm haben intern mehrere packages, und sowas sollte man lt. PBP vermeiden. Aber auch das ist doch kein Selbstzweck, oder?

Mmn. macht es Sinn, package zu verwenden, um Funktionen, die man eigentlich nicht in main braucht sauber gegen den Rest abzugrenzen. Aber mehrere innerhalb eines Moduls zu haben: Wozu braucht man das? (Vereinfacht gesagt: Innerhalb "meines Namespace" kenne ich die Namen...). Wenn, dann doch eher dazu, ggf. "allgemeingültige" Funktionen (die auch außerhalb Sinn machen) und rein internen unterscheiden zu können. Wenn du also innerhalb ASC heute mehrere packages hast, stellt sich mir die Frage, ob das nicht eine allzu künstliche Herangehensweise ist (aber nochmal: ich bin Hobbyist und kann das letztlich nur vom Bauchgefühl her beurteilen).

Was die RandomTimer-Geschichte angeht: Es gab/gibt ein paar Funktionen, die auch WeekdayTimer (und ggf. die "Mutter" Twilight) identisch haben (da geht es vorrangig darum, mehrere InternalTimer identifizieren und ggf. abbrechen/erneuern zu können). Sowas _könnte_ man ggf. als package auslagern. Aber wer pflegt das dann? Da paßt unser Entwicklungsmodel nur bedingt dazu... (Die Funktionen sind aber praxiserprobt und vermutlich auch die kommenden Jahre eher keinen Änderungen unterworfen, von daher könnte das sogar eine gute Idee sein, weil andere die dann einfacher einbauen können!).

ZitatDadurch können diese Module besser mit Tests versorgt werden.
Das wäre ggf. ein interessanter Aspekt, aber da ist mein aktuelles Wissen um das wie wann wo warum viel zu rudimentär. Gibt es dazu irgendwo eine halbwegs DAM-freundliche Option, sich einzulesen? (Sidey hatte zum Thema Tests am meisten geschrieben, und das scheint auch eine akzeptable Grundlage zu sein, ich bin nur noch nicht über die richtige Einstiegsstelle gestolpert und war bisher auch zu faul zum Suchen...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 12 Mai 2020, 11:56:31
Vielleicht ist das zu naiv gedacht, aber RandomTimer ist auch auf package umgestellt. Der ist sicher sehr viel einfacher aufgebaut, aber alleine die Umstellung als Argument gelten zu lassen kommt mir etwas wenig vor.

Was ich teils gesehen habe: Manche heutigen .pm haben intern mehrere packages, und sowas sollte man lt. PBP vermeiden. Aber auch das ist doch kein Selbstzweck, oder?

Mmn. macht es Sinn, package zu verwenden, um Funktionen, die man eigentlich nicht in main braucht sauber gegen den Rest abzugrenzen. Aber mehrere innerhalb eines Moduls zu haben: Wozu braucht man das? (Vereinfacht gesagt: Innerhalb "meines Namespace" kenne ich die Namen...). Wenn, dann doch eher dazu, ggf. "allgemeingültige" Funktionen (die auch außerhalb Sinn machen) und rein internen unterscheiden zu können. Wenn du also innerhalb ASC heute mehrere packages hast, stellt sich mir die Frage, ob das nicht eine allzu künstliche Herangehensweise ist (aber nochmal: ich bin Hobbyist und kann das letztlich nur vom Bauchgefühl her beurteilen).

Was die RandomTimer-Geschichte angeht: Es gab/gibt ein paar Funktionen, die auch WeekdayTimer (und ggf. die "Mutter" Twilight) identisch haben (da geht es vorrangig darum, mehrere InternalTimer identifizieren und ggf. abbrechen/erneuern zu können). Sowas _könnte_ man ggf. als package auslagern. Aber wer pflegt das dann? Da paßt unser Entwicklungsmodel nur bedingt dazu... (Die Funktionen sind aber praxiserprobt und vermutlich auch die kommenden Jahre eher keinen Änderungen unterworfen, von daher könnte das sogar eine gute Idee sein, weil andere die dann einfacher einbauen können!).
Das wäre ggf. ein interessanter Aspekt, aber da ist mein aktuelles Wissen um das wie wann wo warum viel zu rudimentär. Gibt es dazu irgendwo eine halbwegs DAM-freundliche Option, sich einzulesen? (Sidey hatte zum Thema Tests am meisten geschrieben, und das scheint auch eine akzeptable Grundlage zu sein, ich bin nur noch nicht über die richtige Einstiegsstelle gestolpert und war bisher auch zu faul zum Suchen...).

Bezüglich Tests bin ich selbst gerade dabei mich ein zu lesen. Ich verwende aktuell dafür das Buch "Der Perl Programmierer" und ich schaue mir noch das Buch "Perl Testing: A Developer's Notebook".

AutoShuttersControl ist Objektorientiert entwickelt worden daher auch viele package Abschnitte.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Nun ja, "auf Vorrat" dicke Wälzer zu lesen, deren Inhalt ich nur vielleicht verstehe, ist jetzt nicht so ganz oberste Prio bei mir.

Und auch einen - aus welchen Gründen auch immer entstandenen - Ist-Zustand eines Moduls zugrunde zu legen, halte ich auch für fragwürdig. Das soll ausdrücklich aber keine Wertung darüber sein, ob der OO-Lösungsansatz jetzt gut oder schlecht ist. Für meinen persönlichen Geschmack ist mir das zu zerfasert, (welchen Stellenwert man dem sachlich evtl. völlig flaschen "Geschmacks"-Argument auch beimessen mag...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Hi,

Ob Perl Module in FHEM/lib oder lib/ liegen ist technisch egal.

Der Vorteil ein Perl Modul zu schreiben ist es, dass es außerhalb von FHEM lauffähig ist. Zumindest sollte es so sein.

Um das deutlich zu kennzeichnen, kann so eine Aufteilung lib bzw. FHEM/lib helfen.

Ob man etwas in Package Main oder nicht packt ist davon unabhängig.
Die Idee von Libs ist, sich daraus bedienen zu können.
CPAN ist auch nur eine riesige lib. Dort gibt es auch Maintainer, oft auch mehrere.
Zu CPAN hat sich Rudi bereits geäußert, ich kam noch nicht dazu, mir da ein paar Gedanken zu machen. Und bevor ich das angehe möchte ich noch ein offenes Projekt abschließen.

Wir drehen uns leider im Kreis. :-(

Ich könnte mir gut vorstellen, sobald die CPAN Thematik gelöst ist, könnte jeder seine Libs über CPAN verteilen.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

KernSani

Zitat von: Beta-User am 12 Mai 2020, 11:56:31
Was die RandomTimer-Geschichte angeht: Es gab/gibt ein paar Funktionen, die auch WeekdayTimer (und ggf. die "Mutter" Twilight) identisch haben (da geht es vorrangig darum, mehrere InternalTimer identifizieren und ggf. abbrechen/erneuern zu können). Sowas _könnte_ man ggf. als package auslagern. Aber wer pflegt das dann? Da paßt unser Entwicklungsmodel nur bedingt dazu... (Die Funktionen sind aber praxiserprobt und vermutlich auch die kommenden Jahre eher keinen Änderungen unterworfen, von daher könnte das sogar eine gute Idee sein, weil andere die dann einfacher einbauen können!).
Etwas OT hier, aber nur als Anmerkung: Aus WOL habe ich die Abhängigkeit zu Twilight letztes Jahr mal ausgebaut, weil m.E. InternalTimer das selbst alles kann (Habe jetzt aber nicht in WeekdayTimer nachgeschaut, ob da evtl. noch mehr gemacht wird): https://wiki.fhem.de/wiki/DevelopmentModuleAPI#RemoveInternalTimer
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Beta-User

Zitat von: Sidey am 12 Mai 2020, 12:56:58
Ob Perl Module in FHEM/lib oder lib/ liegen ist technisch egal.

Der Vorteil ein Perl Modul zu schreiben ist es, dass es außerhalb von FHEM lauffähig ist. Zumindest sollte es so sein.
So hatte ich das auch verstanden. Alles, was unabhängig von FHEM nutzbar ist, kann und darf eine lib sein (der Weg war @MySensors - für ein paar zentrale, aber letztlich kleine Elemente - eingeschlagen gewesen, aber mangels cpan-Integration nicht vertieft worden). In anderen Fällen, wo das ggf. mehr Sinn gemacht hätte, hat man diesen Weg - aus welchen Gründen auch immer - nicht gewählt. OK, Vergangenheitsbewältigung, mal schauen, wie dazu die Zukunft aussieht.

ZitatUm das deutlich zu kennzeichnen, kann so eine Aufteilung lib bzw. FHEM/lib helfen.
Auch nachvollziehbar. Ob das bei ASC und der vorgeschlagenene Modulstruktur der Fall ist kann ich nicht sagen. Im Prinzip wird es afaik in dem Moment für ein (FHEM-) "Modul" praktisch unmöglich, außerhalb von FHEM lauffähig zu sein, wenn man auf "typische" Datenstrukturen zurückgreift (ReadingsVal()&Co) bzw. typische Anweisungen (CommandSet(), AnalyzeCommandChain() & Co) raushaut. Du stellst die Funktionen in der Testumgebung zur Verfügung, aber irgendeine beliebige andere Perl-Anwendung wird damit nichts anzufangen wissen.
Es dürfte schon gehen, Teilfunktionen zu abstrahieren, aber das klingt mir nach ziemlichem Aufwand, weil man erst die Basis zusammenklauben muß, dann alles "in einem Rutsch" an eine allgemeingültige Funktion übergeben und dann wieder die Rückgabe "verfhemen" muß, oder?

(Und viele user wissen übersehen jedenfalls derzeit schon mal gerne, dass nach einer Änderung im ASC-Umfeld ein restart erforderlich ist. Das würde vermutlich mit zunehmender Verbreitung von Objekten bald besser, aber nur für den Teil der user, die heute einigermaßen "aktiv mitlesen". Bin daher noch unsicher, ob ich das insgesamt als Verbesserung empfinden soll, auch wenn es hilft, das "rereadcfg" für die Mehrheit zum "Unding" zu machen, was afaik allgemein als gewollt angesehen wird.)



Zitat von: KernSani am 12 Mai 2020, 13:11:03
Etwas OT hier, aber nur als Anmerkung: Aus WOL habe ich die Abhängigkeit zu Twilight letztes Jahr mal ausgebaut, weil m.E. InternalTimer das selbst alles kann (Habe jetzt aber nicht in WeekdayTimer nachgeschaut, ob da evtl. noch mehr gemacht wird): https://wiki.fhem.de/wiki/DevelopmentModuleAPI#RemoveInternalTimer
Danke für den Hinweis, das schaut mir so aus, als wäre die Diskussion damit auch hinfällig... (So ist das mit den "Erbstücken; was noch nicht heißt, dass das schon "done" ist).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RichardCZ

Ich finde ja immer noch FHEM/lib hat was megalomanisches an sich. lib/FHEM wäre so die übliche Vorgehensweise.

Zur Antwort auf "wer soll da noch durchsteigen?": Nun - alle anderen.
Bzw. alle, die den Verknöcherungsprozess noch nicht abgeschlossen haben.

Merke: Nehme die Standardlösung in der Perl Welt, drehe sie um 180° und Du hast die FHEM Lösung.

Warum sollten unter lib nur FHEM-unabhängige Sachen rein? Ob etwas von FHEM unabhängig ist oder nicht sollte durch den Namespace gegeben sein.

lib/FHEM/xxx ist eben FHEM-spezifisches Zeug.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

CoolTux

Wo das ganze am Ende liegt ist in der Tat egal. Wollte mich da nur am Vorhanden orientieren. Also Perl Vorhandenen.
In der Tat haben wir in FHEM das auch schon. Bestes Beispiel ist Residents. Es gibt eine Moduldatei Residents wo der Hauptteil des Codes für Residents, Guest, Roommates und so weiter drin steht und es gibt die einzelnen Module Residents, Roommates, Guest mit Zahlen davor wie gewohnt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net