FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: CoolTux am 12 Mai 2020, 09:05:22

Titel: Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 12 Mai 2020, 09:05:22
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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 12 Mai 2020, 09:56:21
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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 12 Mai 2020, 10:13:22
Drei Zustimmungen hat mein Post bereits  ;D
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Beta-User am 12 Mai 2020, 10:17:03
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).
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KölnSolar am 12 Mai 2020, 10:42:57
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
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag 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.
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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 12 Mai 2020, 11:40:29
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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Beta-User am 12 Mai 2020, 11:56:31
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...).
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 12 Mai 2020, 12:33:10
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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Beta-User am 12 Mai 2020, 12:51:45
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...).
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 12 Mai 2020, 12:56:58
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

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KernSani am 12 Mai 2020, 13:11:03
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
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Beta-User am 12 Mai 2020, 13:30:29
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 (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).
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: RichardCZ am 12 Mai 2020, 14:30:20
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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 12 Mai 2020, 14:31:52
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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: RichardCZ am 12 Mai 2020, 14:40:05
Zitat von: CoolTux am 12 Mai 2020, 14:31:52
Wo das ganze am Ende liegt ist in der Tat egal.

Klar ist es egal, solange es unter lib liegt und

package FHEM::Nippel -> lib/FHEM/Nippel.pm
package FHEM::Rad::Neu -> lib/FHEM/Rad/Neu.pm


gilt. Dann ja, dann ist es komplett egal wo das liegt, so lange es so da liegt.  ;)
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Beta-User am 12 Mai 2020, 14:55:32
Zitat von: RichardCZ am 12 Mai 2020, 14:30:20
Zur Antwort auf "wer soll da noch durchsteigen?": Nun - alle anderen.
Kein Problem, wenn dem dann wirklich so ist (ich hänge nicht an dem "Maintainer" und bin gefühlt nach wie vor deutlich eher User...). Ich versuche nur auf dme mir gegönnten Niveau zu verstehen, was "Sache" ist. Reicht wohl nicht (das ist nicht groß emotional zu verstehen, eher als objektive Feststellung).

Den Hinweis auf Residents&Co versteht der DAM allerdings auch nicht (und auch nicht, was die Splittung des Codes in eine "Initalize+Commandref"+dem eigentlichen Code für einen tieferen Sinn haben soll). Habe mir nur Residents+Roomate (je mit stk) angesehen und finde keine "besonderen" packages, und der *stk-Code ist auch nichts, was von fhem.pl unabhängig lauffähig sein dürfte. Da fehlt mir daher der Bezug zum Thema.

Aber ich verstehe wirklich nichts von diesen Sachen und bin daher jetzt still.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 12 Mai 2020, 18:30:51
Wenn ich das richtig gezählt habe sind 2 dagegen und 5 dafür.

Wir können natürlich weiterhin endlos das für uns für und wieder Diskutieren bis dann in 3 Tagen die Diskussion zu erliegen kommt und der Thread in den untiefen des Forums versiegt.
Also

JA - wir erproben es

oder

Nein - wir lassen es

Wenn wir ständig darüber nachdenken müssen was das alles eventuell vielleicht für einen einzelnen für Mehraufwand bedeutet dann wird das alles hier nie was.
Niemand sagt das eine Änderung am Ende auf eine einzelne Person die Arbeit runter bricht. Über das ändern etwaiger Abhängigkeiten (die neben bei keine User betrifft) können wir uns dann zusammen Gedanken machen und sicherlich Arbeitsaufgaben teilen.
Meine vorgeschlagenen Änderung soll auch nicht für User sein sondern Entwicklern die Möglichkeit bieten Ihre Module entsprechend zu entwickeln und es einfacher machen Tests auf einzelne Komponenten dieser Module los zu lassen.


Grüße
Marko



Nägel mit Köpfen und einfach mal machen. Schwätzer gibt es zu Hunderten in diesem Forum, was FHEM weiter bringt sind die Macher.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: betateilchen am 12 Mai 2020, 19:33:50
Zitat von: CoolTux am 12 Mai 2020, 18:30:51
Wenn ich das richtig gezählt habe sind 2 dagegen und 5 dafür.

Ich bin auch dagegen, da sich mir auch nach mehrmaligem sorgfältigem Lesen dieses Threads ein positiver Nutzen der angedachten Änderung immer noch nicht erschließt.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: zap am 12 Mai 2020, 21:50:31
Ich kann mir nicht vorstellen, dass nach gerade mal 7 abgegeben Stimmen hier irgendwelche weitreichenden Entscheidungen getroffen werden.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 12 Mai 2020, 22:13:03
Zitat von: zap am 12 Mai 2020, 21:50:31
Ich kann mir nicht vorstellen, dass nach gerade mal 7 abgegeben Stimmen hier irgendwelche weitreichenden Entscheidungen getroffen werden.


Den meisten ist es sicherlich schlicht egal, da sie der Meinung sind es betrifft sie nicht (womit sie ja Recht hätten, wer nicht expliziert daran Interesse hat als Entwickler den betrifft es auch nicht). Oder sie haben keine Meinung dazu, vielleicht weil sie nicht wissen was das genau bedeutet (Unwissenheit).

Ich will einfach nur eine Sicherheit und dazu wird halt eine Entscheidung benötigt. Wie die aus fällt ist mir egal, ich kann auch wie gehabt weiter machen. Ist halt gerade bei ASC mehr Aufwand da ich denke bei einer Aufteilung besser Tests laufen lassen zu können welche auch sinnvoll sind. Ändere ich in Klasse Shutters::Attr etwas kann ich testen ob dies meine Logiken in der Klasse ShuttersControl beeinflusst. Und ich denke das ich eine bessere Übersicht habe über meine eigene Klassenstruktur.

Aber wie gesagt egal wie es aus fällt ich werde damit leben können.

Mir geht es darum nicht um sonst eventuell Energie reingesteckt zu haben und eine fertige Lösung mit allen drum und dran zu haben in einem halben Jahr und dann passiert sowas wie jetzt wo gesagt wird nö ist unnütz. Dann lieber vorher sagen und entscheiden.



Grüße
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 12 Mai 2020, 22:17:26
Zitat von: CoolTux am 12 Mai 2020, 18:30:51
Wir können natürlich weiterhin endlos das für uns für und wieder Diskutieren bis dann in 3 Tagen die Diskussion zu erliegen kommt und der Thread in den untiefen des Forums versiegt.
Also


Die Natur hat es uns vorgemacht. Hätte jemand darüber diskutiert ob es die Menscheit geben soll oder nicht, wer weiss ob es uns dann heute überhaupt geben würde.

Also ich bin für einfach mal machen und Prototypen eine Chance geben. Was der Prototoyp dann alles kann, da bin ich unsicher.
Aber jede Idee hier so lange zu diskutieren, bis die Lust vergeht, hmm, so ist das doch mit den Open Source Projekten und den Forks eher nicht gedacht oder?

Grüße Sidey
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 12 Mai 2020, 22:27:17
Achso, fast vergessen. Es wurde nach Vorteilen gefragt.

Der Vorteil, sich an sogenannte "Perl" Standards oder "best practices" zu halten liegt darin, dass neue Entwickler auf ein breites Spektrum an Informationsmaterial zurückgreifen können wie z.B. eine Bibliothek erstellt wird.
GGf. kennen diese Entwickler ja bereits auch schon diese Vorgehensweise aus anderen Projekten und können so viel leichter einsteigen.
Außerdem reduziert sich der Dokumentationsaufwand, weil diese dinge schon xFach dokumentiert sind. Es müssen dann "nur" noch die FHEM Besonderheiten dokumentiert und "verstanden" werden. Bei allem anderen, verweisen wir auf "etablierte" Standards.

Onboarding wird so viel einfacher. Das sollte doch jeder aus der Arbeitswelt kennen, wenn er einen neuen Job angefangen oder jemanden Eingearbeitet hat.


Grüße Sidey
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 13 Mai 2020, 10:26:31
Zitat von: Sidey am 12 Mai 2020, 22:27:17
Achso, fast vergessen. Es wurde nach Vorteilen gefragt.

Einen hätte ich noch!

Ich müsste meinen Code in erster Linie nicht darauf hin entwickeln, dass er im FHEM-Kontext läuft, sondern standalone als Modul. Man würde dann nur neben dem eigentlichen Modulcode noch eine Anbindung an FHEM produzieren, die aber in vielen Fällen recht generisch ist (def, undef, attr, set, get, etc.). Diese Anbindung könnte man wiederum in ein Modul auslagern und dann reduziert sich der Aufwand ein neues Modul zu produzieren auf die eigentliche Nutzlast + Anbindung. Und das sollte uns allen entgegen kommen, denn ich weiß ja nicht wie es euch geht, aber mir bluten die Finger wenn ich Code duplizieren muss, der eigentlich generalisiert in ein Modul gehört. Wie jetzt, wo ich in ein neues Modul Code aus Buienradar kopieren muss. Richtig mit copy-paste. Das kann es doch nicht sein. Und das ist uns bei Twilight + RandomTimer auch schon auf die Füße gefallen, wenn ich mal daran erinnern darf (*).

Am besten wäre es natürlich noch, wenn ich MeinModul sagen könnte: Hey, ich brauche MeinAnderesModul als Abhängigkeit, denn da ist Code drin, den ich gerne in MeinModul hätte, aber nicht duplizieren möchte - und FHEM schlägt dem User dann vor: Guck mal, du willst MeinModul installieren, dafür brauchst du aber auch noch MeinAnderesModul, soll ich das ebenfalls installieren? Und dann fügt FHEM meinetwegen eine controls hinzu, die MeinAnderesModul referenziert. Sowas könnte man dann natürlich auch mal für CPAN-Pakete machen und wir hätten das ganze Gewese mit "Ich kopiere Zeug aus CPAN-Module von anno dunnemals damit ich unsere DAUs nicht damit belasten muss, ein CPAN-Paket zu installieren" auch los. Loredo hat da doch tolle Vorarbeit geleistet und viel Zeit investiert, die aktuell nur ungenutzt rumliegt.

Für mich sind das alles Themen, die miteinander zusammen hängen. Eine gescheite Verzeichnisstruktur erlaubt mir eine bessere Modularisierung, die mir erlaubt, Dependencies zu definieren, was mir ermöglicht weniger Code zu duplizieren / Code mehr zu generalisieren - was mir erlaubt endlich mal eine sinnvolle Testabdeckung zu produzieren und nicht meine Modulnutzer als ewige Beta-Tester zu missbrauchen.

(* Das dietmar63 von uns gegangen ist, hat doch schmerzlich gezeigt, dass wir mehr Standardisierung im Code brauchen. Ich arbeite nicht an Twilight, weil es einfach die Pest ist, in den Code zu schauen. Der Aufwand so eine Ruine zu sanieren ist gigantisch: Bei BR - und da ist die Funktionalität viel einfacher - habe ich schon sicher um die 100 Stunden nur darin investiert, den Code zu sanieren damit jemand der mich mal beerbt nicht auf meinem Grab eine Kopie von PBP verbrennt und meine Kinder bis in die dritte Generation verflucht. Ohne Feature-Entwicklung. Bugfixing ist auch die Pest wenn der Code völlig unstrukturiert, unkommentiert und einfach oftmals nicht eindeutig ist.)
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 13 Mai 2020, 11:01:17
ZitatIch müsste meinen Code in erster Linie nicht darauf hin entwickeln, dass er im FHEM-Kontext läuft, sondern standalone als Modul. Man würde dann nur neben dem eigentlichen Modulcode noch einen Anbindung an FHEM produzieren, die aber in vielen Fällen recht generisch ist (def, undef, attr, set, get, etc.)

Geht doch jetzt schon: CPAN Modul bauen, und diesen vom besagten "recht generischen" referenzieren.
Uebersehe ich etwas?
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 13 Mai 2020, 11:26:17
Zitat von: rudolfkoenig am 13 Mai 2020, 11:01:17
Geht doch jetzt schon: CPAN Modul bauen, und diesen vom besagten "recht generischen" referenzieren.
Uebersehe ich etwas?

Ja. Was ist mit Modulen, die Funktionalität nur für FHEM bereitstellen und deshalb im CPAN nix verloren haben? Zum Beispiel wären perspektivisch HttpUtils, Meta, Units, FHEMWEB, etc. alles Dinge, die keine CPAN-Module sind und sein sollten, aber auch mal ordentlich modularisiert gehören. Und natürlich gibt es einige Leute, die gerne über das SVN ausliefern, z.B. CoolTux, der aber auch eine modernere Modul-Struktur benutzen möchte - und imho auch muss, denn  ASC ist z.B. so komplex und hat so viele Optionen, dass der Code auch riesig ist (und ich weiß das, weil ich jeden Commit den er auf Github macht, reviewe und mit nervigen Kommentaren versehe).
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: zap am 13 Mai 2020, 11:39:52
Zitat von: CoolTux am 12 Mai 2020, 22:13:03
Den meisten ist es sicherlich schlicht egal, da sie der Meinung sind es betrifft sie nicht (womit sie ja Recht hätten, wer nicht expliziert daran Interesse hat als Entwickler den betrifft es auch nicht). Oder sie haben keine Meinung dazu, vielleicht weil sie nicht wissen was das genau bedeutet (Unwissenheit)

Dann habe ich das falsch verstanden. In dem Fall zähle ich mich zur "ist mir egal" Fraktion ;)
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: betateilchen am 13 Mai 2020, 15:07:50
Zitat von: Sidey am 12 Mai 2020, 22:27:17
Achso, fast vergessen. Es wurde nach Vorteilen gefragt.

Welchen Vorteil hätte der Anwender?

Wir bauen doch FHEM nicht als Selbstzweck oder als Spielwiese für Entwickler, sondern für die Anwender.
Als CSM und CSPO stehen für mich immer die Kunden/Anwender im Vordergrund, denen eine Produktentwicklung einen Vorteil bringen muss, bevor entschieden werden kann, ob ein Aufwand betrieben wird oder nicht.
Einen solchen Vorteil auf seiten der Anwendung (= Benutzung) sehe ich einfach immer noch nicht.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 13 Mai 2020, 15:46:07
Zitat von: betateilchen am 13 Mai 2020, 15:07:50
Welchen Vorteil hätte der Anwender?

Wir bauen doch FHEM nicht als Selbstzweck oder als Spielwiese für Entwickler, sondern für die Anwender.
Als CSM und CSPO stehen für mich immer die Kunden/Anwender im Vordergrund, denen eine Produktentwicklung einen Vorteil bringen muss, bevor entschieden werden kann, ob ein Aufwand betrieben wird oder nicht.
Einen solchen Vorteil auf seiten der Anwendung (= Benutzung) sehe ich einfach immer noch nicht.

Wenn Du es tatsächlich genau so siehst dann bin ich als Entwickler falsch hier.
Von einem Projekt für welches ich mich als Entwickler begeistere und Arbeiten beisteuern will erwarte ich auch Unterstützung für mich als Entwickler und nicht nur das ich ausschließlich hier bin um die User zu beglücken. Du kochst doch auch nur mit Liebe wenn entsprechendes Arbeitsmaterial hast und die Umgebung passt. Und nicht weil irgendwer sich deswegen super fühlt.

Deine Aussage empfinde ich als Entwickler für mich als Beleidigung.  >:(
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 13 Mai 2020, 16:19:35
Zitat von: betateilchen am 13 Mai 2020, 15:07:50
Welchen Vorteil hätte der Anwender?
Wir bauen doch FHEM nicht als Selbstzweck oder als Spielwiese für Entwickler, sondern für die Anwender.

Er bekommt langfristig ein stabilieres, besser getestetes und leichter zu installierendes System. Da du ja ...

Zitat von: betateilchen am 13 Mai 2020, 15:07:50
Als CSM und CSPO stehen für mich immer die Kunden/Anwender im Vordergrund, denen eine Produktentwicklung einen Vorteil bringen muss, bevor entschieden werden kann, ob ein Aufwand betrieben wird oder nicht.

... so wie ich, übrigens, CSM und CSPO bist, kennst du das Konzept der technischen Schulden sicher nur all zu gut. Und die fallen am Ende allen auf die Füße, aber den Usern gleich fünfmal, denn ich kann mir ein Log anschauen und meinen unmatched Regex selbst finden ohne auf das Forum angewiesen zu sein.

Allerdings, und da stimme ich CoolTux zu, entwickele ich hier nicht in erster Linie für irgendwelche abstrakte Benutzer die mich nicht mal dafür bezahlen, dass ich irgendwelche lumpigen APIs anbinde/ranzige Altmodule überarbeite oder Bugs in meiner Freizeit fixe, sondern weil ich a) selbst ein Interesse daran habe, dass es hier läuft (und keinen Bock auf Streit mit meiner Frau habe :-D ), b) weil ich mich selbstverwirklichen möchte (Übung in einer Programmiersprache, die ich sonst nicht benutze) und c) weil ich euch was zurück geben möchte, die auch Zeit in etwas investiert haben, von dem ich profitiere (so eine Art reziproker Altruismus). Und dabei ist eben ein guter Nebeneffekt, dass die Leute, die nichts weiter beitragen, auch davon profitieren (Surplus/Mehrwert).

Und auch da stimme ich CoolTux zu: Auch ein Projekt wie FHEM muss attraktiv für Entwickler sein, denn ohne Entwickler bekommen selbst interessiert User keinen Code/keine Funktionalität. Und tut mir leid, aber bisher sehe ich keine besonderen Anstrengungen vom harten Kern, Entwickler zur Mitarbeit zu motivieren: Es gibt keine Öffentlichkeitsarbeit (in Richtung Entwickler!) und das Toolset ist von anno tobak. Ich denke mit Grausen daran, wie mit Richard hier umgegangen wird, obwohl er nichts anderes getan hat, als den Finger in die Wunde zu legen. Insbesondere von euch/einigen "alten Herren" hier.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KernSani am 13 Mai 2020, 17:00:01
Liebe Leute,
müssen eigentlich alle dieser Diskussionen immer in ein (ich formuliere mal überspitzt): "Du bist doof!" - "Nein! Du bist doof!" ausarten?
Können wir uns statt eine "Dafür" und eine "Dagegen" Position einzunehmen nicht einfach mal versuchen konstruktiv zusammen zu arbeiten?
Ich sehe hier kurz gefasst Folgendes:
* Ein Entwickler hat einen Vorschlag, der es ihm und möglicherweise anderen Entwicklern ermöglicht, besser testbare und besser wartbare Software zu erstellen.       
* Dieser Vorschlag ist mit nicht unerheblichen Aufwänden in einigen Kernfunktionen verbunden
Nun kann man:
a) konstruktiv diskutieren, ob die Ziele des Entwicklers auch mit weniger Aufwand für die Kernfunktionalitäten realisierbar sind.
b) konstruktiv diskutieren, wie man den Maintainer der Kernfunktionalitäten entlasten könnte
Damit könnte man versuchen einen Weg zu skizzieren wie wir uns dem Ziel nähern, das wir vermutlich alle haben:Gute, funktionierende Hasuautomatisierungssoftware zu bauen und uns nicht mit Supportaufgaben rumzuschlagen.
Danke,
Oli   

 
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 13 Mai 2020, 17:07:37
Danke Oli, so sehe ich das auch. Habe auch geschrieben das ich kein Problem mit einer "negativen" Entscheidung habe.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 13 Mai 2020, 17:54:21
Und ich warte noch auf eine Absichtserklerung von weiteren Maintainer ("Gefaellt mir" ist nicht gleichwertig) und eine halbwegs abgestimmte Verzeichnisstruktur.

Mir ist bewusst, dass das zu einer Zersplitterung der Modulstruktur, und mehr Chaos bei den Benutzer fuehren wird.
Das passt mir zwar nicht, ich sehe mich hier aber als Framework-Dienstleister, und nicht als Missionar.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: herrmannj am 13 Mai 2020, 17:56:56
Unentschieden, ich lese mit und versuche die Argumente zu werten. Ich möchte trotzdem darauf hinweisen dass das aus meiner Sicht massive Änderungen am updater nach sich zieht.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Wzut am 13 Mai 2020, 18:00:30
Zitat von: CoolTux am 12 Mai 2020, 22:13:03
Oder sie haben keine Meinung dazu, vielleicht weil sie nicht wissen was das genau bedeutet (Unwissenheit).
da reihe ich mich ein
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 13 Mai 2020, 18:10:34
Es wird halt ein Verzeichnisbaum geben (unter lib oder FHEM/lib), wo Teile der bisherigen Module zu verorten sind.
Siehe ersten Beitrag von CoolTux: AutoShuttersControl war bisher eine Datei, er moechte aber daraus 12 Stueck machen.

Das wird nicht jeder Maintainer machen bzw. machen muessen.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 13 Mai 2020, 18:10:58
Eine überarbeitete Version für mich wäre

Zitatlib/Automation/ShuttersControl.pm
lib/Automation/ShuttersControl/Shutters.pm
lib/Automation/ShuttersControl/Shutters/Attr.pm
lib/Automation/ShuttersControl/Shutters/Readings.pm
lib/Automation/ShuttersControl/Window.pm
lib/Automation/ShuttersControl/Window/Attr.pm
lib/Automation/ShuttersControl/Window/Readings.pm
lib/Automation/ShuttersControl/Roommate.pm
lib/Automation/ShuttersControl/Dev.pm
lib/Automation/ShuttersControl/Dev/Readings.pm
lib/Automation/ShuttersControl/Dev/Attr.pm

Im besten Fall bekommt doch der User gar nichts mit und soll ja auch nichts mitbekommen. Im sind doch die Strukturen egal so lange alles läuft.

Im übrigen habe ich sollte es so kommen auch Mehraufwand. backup muss angepasst werden. Nur mal so. Aber ich würde es sehr sehr gerne machen.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 13 Mai 2020, 18:22:37
Es fehlt noch eine Datei in FHEM, sonst weiss FHEM nicht, welche Module anzubieten sind.
Ditto fuer Doku, das wollte ich nicht auch umbauen.

ZitatIm sind doch die Strukturen egal so lange alles läuft.
Das ist klar, es faengt da an, wenn es nicht laeuft. Z.Bsp. version. Oder hol mal die Neue Datei aus dem SVN. Welche? Wohin soll ich es kopieren? Was sage ich exclude_from_update?
Aber wie gesagt: ich will nicht missionieren, nur konkreten Input, und Absichtserklaerung von sagen wir mind. 3 Maintainer.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 13 Mai 2020, 18:46:48
Zitat von: rudolfkoenig am 13 Mai 2020, 18:22:37
Aber wie gesagt: ich will nicht missionieren, nur konkreten Input, und Absichtserklaerung von sagen wir mind. 3 Maintainer.

Ich.

Mein Plan ist, unter FHEM/ eine 59_Buienradar.pm anzulegen, die lediglich ein Wrapper ist um lib/FHEM/Weather/Buienradar.pm zu laden, die ihrerseits lib/Weather/Buienradar.pm (und andere Bibliotheken) nutzt. Irgendwann wird dann das Konstrukt mit xx_Modulname.pm in FHEM/ hoffentlich aufgelöst / optional und dann kann der Wrapper weg und direkt lib/FHEM/Weather/Buienradar.pm verwendet werden, wenn ein Device angelegt wird.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Dr. Boris Neubert am 13 Mai 2020, 18:47:59
Ich sehe glaube ich vor lauter Bäumen den Wald nicht mehr.

Was sind Argumente für die von CoolTux vorgeschlagene Gliederung (rede nicht davon, wo diese genau aussehen soll)? Habe gelesen, dass sie Unit Testing fördern würde. Kann das nicht beurteilen, wüsste nichtmal wie die aussähen. Weitere Nutzenargumente?

Irgendwo von einem Vorschlag gelesen, einen Proof-of-Concept zu machen, der belegt, dass der Nutzen den Aufwand rechtfertigt. Ist für mich okay.

Spass an der Freude ist auch ein Argument. Ich hätte jetzt keinen Spaß daran, meine Module zu zerlegen, solange ich den Nutzen für die Weiterentwicklung oder für den Kontext noch nicht verstanden habe.

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Dr. Boris Neubert am 13 Mai 2020, 18:50:28
Zitat von: Christoph Morrison am 13 Mai 2020, 18:46:48
Mein Plan ist, unter FHEM/ eine 59_Buienradar.pm anzulegen, die lediglich ein Wrapper ist um lib/FHEM/Weather/Buienradar.pm zu laden, die ihrerseits lib/Weather/Buienradar.pm (und andere Bibliotheken) nutzt. Irgendwann wird dann das Konstrukt mit xx_Modulname.pm in FHEM/ hoffentlich aufgelöst / optional und dann kann der Wrapper weg und direkt lib/FHEM/Weather/Buienradar.pm verwendet werden, wenn ein Device angelegt wird.

Zur Bereicherung der Diskussion: das Wettermodul arbeitet mit Plugins. Es gibt ein Weather-Device, dass sich abhängig vom im Define gewählten API das richtige Plugin-Modul zieht. Das ist eine Frage der Logik, nicht der Verzeichnisstruktur - die wär' mir dabei grad egal.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 13 Mai 2020, 19:48:22
Zitat von: Dr. Boris Neubert am 13 Mai 2020, 18:50:28
Zur Bereicherung der Diskussion: das Wettermodul arbeitet mit Plugins. Es gibt ein Weather-Device, dass sich abhängig vom im Define gewählten API das richtige Plugin-Modul zieht. Das ist eine Frage der Logik, nicht der Verzeichnisstruktur - die wär' mir dabei grad egal.

Ich weiß, allerdings liefert BR ein bisschen andere Sachen als die bisher dort eingebundenen Module, insb. keine langfristigen Vorhersagen (zumindest das Regenradar, der Webservice könnte auch mehr Daten liefern, insb. für die Niederlande).

Aber wie du schon richtig festgestellt hast, hat das erstmal nichts mit der Modul-Logik des Weather-Moduls zu tun und ist auch nicht mein Anliegen (das habe ich weiter oben ausgeführt). Mir geht es darum, dass ich das Modul in logische Einheiten zerhauen und die in Perl üblichen Methoden zum Einbinden von Dependencies nutzen kann, mit der langfristigen Hoffnung, erweiterte Features in einem Installer nutzen zu können.



Zitat von: Dr. Boris Neubert am 13 Mai 2020, 18:47:59
Was sind Argumente für die von CoolTux vorgeschlagene Gliederung (rede nicht davon, wo diese genau aussehen soll)? Habe gelesen, dass sie Unit Testing fördern würde. Kann das nicht beurteilen, wüsste nichtmal wie die aussähen. Weitere Nutzenargumente?

Habe ich auch weiter oben ausgeführt: (Automatisierte) Regressions- und Integrationstest sorgen dafür, dass Software nicht erst beim Nutzer getestet wird. Das geht mit "fetten" Libraries, wie wir sie im FHEM-Umfeld haben, aber wirklich nur schlecht bis gar nicht. Ich kann BR aktuell eigentlich nicht ohne eine laufende FHEM-Instanz testen und das ist eben ein nicht so toll.

Zitat von: Dr. Boris Neubert am 13 Mai 2020, 18:47:59
Spass an der Freude ist auch ein Argument. Ich hätte jetzt keinen Spaß daran, meine Module zu zerlegen, solange ich den Nutzen für die Weiterentwicklung oder für den Kontext noch nicht verstanden habe.

Der aktuelle Vorschlag würde für deine Module, soweit ich sie überblicke, gar keine Änderung bedeuten. Der existierende Mechanismus mit FHEM/xx_Modulname.pm bliebe erhalten, es käme lediglich ein lib/-Verzeichnis hinzu, das eben von ein paar Leuten genutzt wird. Notwendig wäre dazu, dass man update so anpasst, dass man auch Code in ./lib verändern darf.

Ich hab mir nun mal eine controls (https://raw.githubusercontent.com/christoph-morrison/mod-Serienjunkies/reverse-engineering/controls_Serienjunkies.txt) gebaut, die in ./lib/FHEM schreibt:


UPD 2020-05-13_09:45:28 938 lib/FHEM/Serienjunkies.pm
UPD 2020-05-13_09:49:10 87 FHEM/98_Serienjunkies.pm


update Serienjunkies:


Serienjunkies
UPD lib/FHEM/Serienjunkies.pm
writing ./lib/FHEM/Serienjunkies.pm  failed: No such file or directory, trying to restore the previous version and aborting the update
Downloading
Cannot parse , probably not a valid http control file


Angekommen ist die Datei aber:

tree ./lib
./lib
└── FHEM
    └── Serienjunkies.pm


Dafür ist die in FHEM/ nicht angekommen:
stat: cannot stat '/opt/fhem/FHEM/98_Serienjunkies.pm': No such file or directory

Auch der controls-File ist weg:

-rw-r--r-- 1 fhem dialout   66 Mär 31 15:33 controls_bfs.txt
-rw-rwxr-- 1 fhem dialout   82 Apr 11 12:53 controls_Blink.txt
-rw-rwxr-- 1 fhem dialout   80 Apr 24 19:16 controls_Buienradar.txt
-rw-r--r-- 1 fhem dialout   53 Mär 31 15:33 controls_CUPS_Switch.txt
-rw-rwxr-- 1 fhem dialout   46 Jan 15 18:25 controls_EPG.txt
-rw-rwxr-- 1 fhem dialout  243 Jan 10 20:50 controls_fhemabfall.txt
-rw-rwxr-- 1 fhem dialout 142K Mai  2 13:03 controls_fhem.txt
-rw-rwxr-- 1 fhem dialout   66 Jan 10 20:50 controls_hm-js.txt
-rw-rwxr-- 1 fhem dialout   68 Mär 31 15:33 controls_Nina.txt
lrwxrwxrwx 1 fhem dialout   69 Mai  2 13:04 controls.txt
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KernSani am 13 Mai 2020, 20:19:18
Ich will nicht unbedingt meine Module in Einzelteile zerlegen. Was mich aber tatsächlich stört, ist - wie oben jemand geschrieben hat - dass jedes Modul einen hohen copy/paste Anteil hat, der dann ggf. leicht angepasst werden muss. D.h. ich wünsche mir eine Möglichkeit Gleichteile besser wiederverwendbar zu machen. Aktuelles Beispiel: Passwort speichern. Da bekomme ich 27 Hinweise aus welchem Modul ich mir das copy/pasten kann. Sicher kann man das auch anders machen (einfach ein package machen und in /FHEM werfen), aber wenn es Best Practices gibt, warum nicht nehmen?
Ich bin auch gerne bereit, mir mein Testsystem zu zerschiessen, wenn neue Updatefunktionalität o.ä. getestet werden soll.
Über Dinge wie excludeFromUpdate u.ä. miss man sich aber in der Tat Gedanken machen...


Kurz, weil mobil....
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 13 Mai 2020, 20:34:31
Zitat(Automatisierte) Regressions- und Integrationstest sorgen dafür, dass Software nicht erst beim Nutzer getestet wird.
Dafuer habe ich heute was eingecheckt: siehe https://forum.fhem.de/index.php/topic,111061.msg1053522.html#msg1053522

ZitatAktuelles Beispiel: Passwort speichern.
Fuer sowas ist kein Umbau der verzeichnisstruktur notwendig, in FHEM sind jetzt schon 30+ Dateien (wie TcpServerUtils.pm, HttpUtils.pm), die genau in diesem Sinn verwendet werden. Btw: ist setKeyValue/getKeyValue fuer diesen Zweck unpassend?
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KernSani am 13 Mai 2020, 20:43:32
Zitat
Fuer sowas ist kein Umbau der verzeichnisstruktur notwendig, in FHEM sind jetzt schon 30+ Dateien (wie TcpServerUtils.pm, HttpUtils.pm), die genau in diesem Sinn verwendet werden.
Hatte ich ja geschrieben, geht auch anders ;-)
Macht es aber nicht übersichtlicher.
ZitatBtw: ist setKeyValue/getKeyValue fuer diesen Zweck unpassend?
Die sind der Kern des Ganzen, dazu bastelt (bzw. kopiert) dann jeder Entwickler eine save, eine read, eine rename und eine delete Funktion...


Kurz, weil mobil....
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: DS_Starter am 13 Mai 2020, 23:25:07
Ich hatte mich mit einer Meinungsabgabe zurück gehalten, da ich weder Argumente dafür als auch keine dagegen vorbringen kann. Dafür fehlt mir einfach die Erfahrung bzw. das Wissen oder vielleicht besser die programmtechnische / architektonische Weitsicht.

Rein vom Gefühl her würde ich allerdings der von CoolTux angeregten Änderung eine Chance geben wollen, weil ich durchaus neugierig auf Neues bin und der Aha-Effekt sich dann vielleicht doch noch (bei mir) einstellt und ich für mich Nützliches
entdecken und anwenden kann. Viel wurde ja auch bereits dazu erläutert.
Wichtig wäre für mich, dass die Änderung keine negativen Auswirkungen auf den Bestand hat, da ich momentan neben der
aktuellen Überarbeitung meiner Module (PBP) keine Lust auf weitere Zerlegungen habe. Aber das scheint mir gegeben.

Also Zustimmung meinerseits, da sich offensichtlich Chancen für Verbesserungen eröffnen ohne zwangsläufig Nachteile in Kauf nehmen zu müssen (von der anfallenden Arbeit an den entsprechenden Stellen abgesehen).
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Wuppi68 am 14 Mai 2020, 00:05:41
schliesse mich DS_Starter an.

Das könnte auch das Cut & Paste etwas eindämmen
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 14 Mai 2020, 06:46:04
Zitat von: Dr. Boris Neubert am 13 Mai 2020, 18:50:28
Zur Bereicherung der Diskussion: das Wettermodul arbeitet mit Plugins. Es gibt ein Weather-Device, dass sich abhängig vom im Define gewählten API das richtige Plugin-Modul zieht. Das ist eine Frage der Logik, nicht der Verzeichnisstruktur - die wär' mir dabei grad egal.

Hallo Boris,

Aber gerade Weather und die API Geschichte ist doch ein perfektes Beispiel. Selbst im jetzigen Zustand haben wir unglaublich viel redundanten Code in den API Files. Das kann man noch mehr runter brechen.
Im Grunde muss in einer API Datei lediglich das parsen der gewonnen Daten stehen. Alles andere kann ausgelagert werden. Nicht ins Weather Modul das dient nur zu Anzeige (Frontend).

Aktuell könnte man
lib/Services/Weather.pm
lib/Services/Weather/api/DarkSky.pm
lib/Services/Weather/api/OpenWeatherMap.pm
.....

machen.

Und jeder kann ein Unit-Test für das API Modul erstellen um zu schauen ob es noch mit dem Frontend Modul oder anderen API Abhängigkeiten läuft. Aber wer sagt das nur Weather die APIs nutzen kann, es können auch andere Module die APIs nuten und die Daten auswerten. Sie laufen dann zwar in eine Abhängigkeit aber das kann man sicherlich relativ schnell umbauen anstatt neuen kompletten Abfrage und Parse Code zu schreiben. Einfach eine andere API verwenden.



Grüße

Marko


PS: Und nochmal um es deutlich zu sagen. Aktuell geht es einzig und allein um eine Zusage das wenn ich mich dem Umbauprojekt zuwende und alles so läuft wie ich es mir vorstelle es auch dann umgesetzt werden kann.
Ich weiß ja noch nicht ob ich es schaffe meine Vorstellung auch in Code um zu setzen. Beim ersten Versuch ging es vorerst schief. Ich gebe aber nicht auf denn ich sehe in dem ganzen potential.
Es wird aber nicht von heute auf Morgen sein, und somit muss auch keiner von heute auf morgen irgendwas aktuell umsetzen oder sich Gedanken machen um update oder sonst was. Sollte das ganze Anklang finden machen wir das Stück für Stück.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: M.Schulze am 14 Mai 2020, 08:02:53
Hallo,

wird die geplante Änderung Auswirkungen auf die aktuell vorhandene Möglichkeit haben, Module im Betrieb 'komplett' zu aktualisieren?

Also auf Befehl 'reload' wie er jetzt ist oder oder verbessert sein könnte (->reload auto oder all, auch getriggert über Uhrzeit oder z.B. Signal SIGUSR1)

MfG
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 14 Mai 2020, 08:07:55
Zitat von: M.Schulze am 14 Mai 2020, 08:02:53
Hallo,

wird die geplante Änderung Auswirkungen auf die aktuell vorhandene Möglichkeit haben, Module im Betrieb 'komplett' zu aktualisieren?

Also auf Befehl 'reload' wie er jetzt ist oder oder verbessert sein könnte (->reload auto oder all, auch getriggert über Uhrzeit oder z.B. Signal SIGUSR1)

MfG

Nein.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 14 Mai 2020, 08:16:56
Zum Thema Code Nutzung und packages und vielleicht auch Klassen eine kleine Anekdote welche ich letzte Woche mit einem User hatte.

Ein User wollte gerne an dem Programmablauf von ASC vorbei Änderungen seiner Rollozustände machen. Diese sollten aber nicht als manuellen Eingriff gelten sondern schon noch ASC konform sein. Ausserdem wollte er die Fahrt unter Achtung aller anderen Regeln machen. Also Fenster ist offen und so.
Der User war willens und auch fähig sich in kurzer Zeit in den Code ein zu lesen und auf Basis dessen sich selbst 2 Objekte für Shutter und ASC zu erstellen. Über diese Objekte hatte er nun Zugriff auf ASC Interne Routinen und konnte diese verwenden. Wohl gemerkt nur über die Objekte. Er musste keinen Code duplizieren oder Funltionen importieren um an sein Ziel zu kommen. Er musste nicht mal den Code der Funktionen kennen, es reichte aus zu wissen was die Funktionen machen. Er hat ASC damit nicht kaputt gemacht. ASC musste lediglich geladen sein. ASC bietet so viele Möglichkeiten welche User auch einzeln verwenden können oder andere Entwickler in ihre Rollomodule einbauen könnten ohne Code zu duplizieren. Viel bedarf es dafür nicht.



Grüße
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Thorsten Pferdekaemper am 15 Mai 2020, 21:38:46
Hi,
um mir eine Meinung zu bilden würde ich gerne verstehen, worin genau die große Änderung bestehen würde. Soweit ich es verstanden habe, macht es z.B. HM485 und insbesondere FUIP bereits so.
Gruß, 
   Thorsten
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 15 Mai 2020, 23:32:33
Mit CoolTux, KernSani und meiner Wenigkeit sind die drei Maintainer übrigens gefunden.
Ich wäre aber auch glücklich, wenn update das Schreiben in lib/ unterstützen würde.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 16 Mai 2020, 00:34:39
Vier gefunden!
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag 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.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 16 Mai 2020, 12:31:33
Hallo Rudi,

Vielen Dank für Deine Vorschläge und die Arbeiten.
Bezüglich der Verzeichnisstruktur kann man ja bevor man los legt kurz hier nach fragen. Aktuell ok finde ich schon mal

lib/Device
lib/Device/Multimedia
lib/Automation
lib/Service
lib/Service/Weather
lib/Frontend


Grüße
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 16 Mai 2020, 12:48:27
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.

Gerne. Ein CPAN-Paket (in diesem Fall FHEM::Weather::Buienradar) sieht so aus, wenn man es sich mit module-starter erstellen lässt:


fhem-weather-buienradar
├── Changes
├── MANIFEST
├── Makefile.PL
├── README
├── ignore.txt
├── lib
│   └── FHEM
│       └── Weather
│           └── Buienradar.pm
├── t
│   ├── 00-load.t
│   ├── manifest.t
│   ├── pod-coverage.t
│   └── pod.t
└── xt
    └── boilerplate.t


Daran würde ich mich orientieren, also brauchen wir lediglich $attr{global}{modpath}/lib.

Zitat
- $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.

Kann ich mit leben.

Zitat
- lib/FHEM ist nicht erlaubt.

Weshalb nicht? Bildet man den Namespace der Module korrekt ab, muss man zwingend unter lib/FHEM schreiben dürfen, sogar am besten nur unter diesem Pfad um Kollisionen mit CPAN-Modulen zu vermeiden.

Zitat
- 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.

Kann ich mit leben.

Zitat
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.

Wenn die Pakete korrekt mit FHEM:: prefixt werden, dann wird es so lange keine Kollisionen geben, wie niemand etwas mit FHEM:: ins CPAN eincheckt.

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

Finde ich super von dir.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 16 Mai 2020, 13:05:16
ZitatWeshalb nicht? Bildet man den Namespace der Module korrekt ab, muss man zwingend unter lib/FHEM schreiben dürfen, sogar am besten nur unter diesem Pfad um Kollisionen mit CPAN-Modulen zu vermeiden.

Die Begruendung liegt in dieser Bitte (https://forum.fhem.de/index.php/topic,111061.msg1053764.html#msg1053764) bzw. in der folgenden Begruendung (https://forum.fhem.de/index.php/topic,111061.msg1053888.html#msg1053888).

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KölnSolar am 16 Mai 2020, 14:05:09
Ist es nur mein Unverständnis, oder haben wir mit 2 Posts bereits Unterschiede in der Verzeichnisstruktur ?
Zitatlib/Service/Weather
ungleich
Zitat├── lib
│   └── FHEM
│       └── Weather
Was denn nun ?

Und irgendwie OT u. irgendwie nicht: bereits in Post#5  ::) antwortete Rudi mir mit einem Kommentar, den ich eben aus OT-Gründen nicht erwidert hatte, was ich nun aber in Anbetracht der Verzeichnisstruktur nachhole
ZitatCPAN 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.
Bei UPnP ist das ein Trugschluss. Das war keine Bequemlichkeit, sondern es wurden auch Modifikationen durchgeführt. Wie ist dann dazu der mittelfristige Plan ? Alles was heute unter /lib steht wird gelöscht ? DLNARenderer und SONOS und ? wären  dann tot, weil sie auf die Modifikationen angewiesen sind.

Ich wiederhole daher meine Frage aus Post#4  :'(
ZitatWo ist das Gesamtkonzept ? Was bedeutet das für andere Module ?
Ist es zu viel verlangt, dass ein TE mit Änderungswunsch ähnlich wie bei Modulentwicklungen im ersten Post das wesentlichste zusammenfasst, als dass man sich durch 57 Posts mit tw. äußerst unsachlichen Kommentaren durchkämpfen muss ? (Und dann irgendwie immer noch eine nur nebulöse Vorstellung hat, welche Regeln für ein Unterverzeichnis "lib" zukünftig gelten.)
Grüße Markus
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: RichardCZ am 16 Mai 2020, 14:30:42
Zitat von: rudolfkoenig am 16 Mai 2020, 13:05:16
Die Begruendung liegt in dieser Bitte (https://forum.fhem.de/index.php/topic,111061.msg1053764.html#msg1053764) bzw. in der folgenden Begruendung (https://forum.fhem.de/index.php/topic,111061.msg1053888.html#msg1053888).

@Christoph M.

Ich antoworte mal allgemein und publik auf Deine PM, damit das hier für die zuschauer auch etwas klarer wird.

Rudi hat erstmal dieses t-Verzeichnis eingeführt. Ein "lib Verzeichnis" wurde nicht eingeführt. Oder noch nicht.
Alles was ich geschrieben habe - platt ausgedrückt -  war: "FHEM/lib ist die Pest, sollte man nicht nutzen"
und "wäre schön lib zu haben"

Das geht - glaube ich - sogar d'accord mit Rudis Wunsch aus dem FHEM/lib Verzeichnis irgendwann z.B. diese alten CPAN module rauszuschmeissen.
Im Endeffekt sollte das Ziel sein FHEM/lib sterben zu lassen, und im Idealfall hätte man irgendwann ein "lib" Verzeichnis (gleich neben t) in das man anfangen könnte Module mit dem richtigen hierarchischen Namespace zu kippen.

Also auch gerne lib/FHEM/Weather/Buienradar.pm

wenn Rudi zeit und Muße findet a) lib zu erstellen, b) fhemupdate.pl entsprechend aufzubohren.
Wenn unter FHEM/59_Buienradar.pm das entsprechende FHEM-Legace-Interface-Skelett ist und

Das erste Wenn ist Voraussetzung zu allem und ausschliesslich in Rudis Regie. Bis dahin ist erstmal ein lib/FHEM/Weather/Buienradar.pm nicht nur "verboten", sondern einfach schlicht nicht möglich.

@Köln

Die Frage nach

lib/Service/Weather
oder
lib/FHEM/Weather

stellt sich nicht. Ersteres ist ein allgemeines Modul, welches unabhängig von FHEM läuft und "auf CPAN könnte", letzteres ist ein FHEM-spezifisches Modul (welches gerne Service::Weather nutzen kann), aber ohne ein FHEM Kontext/Environment keinen Sinn macht.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 16 Mai 2020, 14:37:44
Zitat von: KölnSolar am 16 Mai 2020, 14:05:09
Ist es nur mein Unverständnis, oder haben wir mit 2 Posts bereits Unterschiede in der Verzeichnisstruktur ?ungleichWas denn nun ?

Man muss differenzieren: Code, der nur im Kontext von FHEM läuft, gehört IMHO unter $modpath/lib/FHEM/ (dahin gehört übrigens auch IMHO $modpath/lib/FHEM/MyUtils und das sollte auch ein gesperrtes Verzeichnis für den Code aus 99_myUtils sein!). Code, der auch standalone laufen würde, gehört unter $modpath/lib/. D.h. beide Pfade sind ok, weil sie unterschiedliche Dinge abbbilden. Siehe mein Posting (https://forum.fhem.de/index.php/topic,111125.msg1053700.html#msg1053700).

ZitatUnd irgendwie OT u. irgendwie nicht: bereits in Post#5  ::) antwortete Rudi mir mit einem Kommentar, den ich eben aus OT-Gründen nicht erwidert hatte, was ich nun aber in Anbetracht der Verzeichnisstruktur nachholeBei UPnP ist das ein Trugschluss. Das war keine Bequemlichkeit, sondern es wurden auch Modifikationen durchgeführt. Wie ist dann dazu der mittelfristige Plan ? Alles was heute unter /lib steht wird gelöscht ? DLNARenderer und SONOS und ? wären  dann tot, weil sie auf die Modifikationen angewiesen sind.

Ich halte die Antwort von Rudi auf deine Frage auch nicht für eine richtige Antwort, denn wie du ja sagst, sind die Sachen die aktuell unter $modpath/FHEM/lib liegen, modifizierte Dinge, die vorerst zumindest dort bleiben könnten und gerade auch keine Not verursachen. Ich fände es trotzdem charmant, wenn man sie langfristig unter $modpath/lib/ einsortiert, vorzugsweise auch unter $modpath/lib/FHEM, da sie ja (teilweise?) modifizierte Versionen von offiziellen CPAN-Paketen sind.

Zitat von: KölnSolar am 16 Mai 2020, 14:05:09
Ich wiederhole daher meine Frage aus Post#4  :
Wo ist das Gesamtkonzept ? Was bedeutet das für andere Module ?

Das wurde schon ausführlich beantwortet. Erstmal bedeutet es für andere Module gar nichts, weil es sie schlicht nicht betrifft, nicht mal den Code aus $modpath/FHEM/lib/.

Zitat von: KölnSolar am 16 Mai 2020, 14:05:09
'(Ist es zu viel verlangt, dass ein TE mit Änderungswunsch ähnlich wie bei Modulentwicklungen im ersten Post das wesentlichste zusammenfasst, als dass man sich durch 57 Posts mit tw. äußerst unsachlichen Kommentaren durchkämpfen muss ? (Und dann irgendwie immer noch eine nur nebulöse Vorstellung hat, welche Regeln für ein Unterverzeichnis "lib" zukünftig gelten.)

Auch bei den "Profis" werden RfC (https://de.wikipedia.org/wiki/Request_for_Comments) gemacht und dann diskutiert. Solche Regeln entstehen doch gerade erst in der Diskussion.

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: RichardCZ am 16 Mai 2020, 14:38:07
Wenn man ein lstree2 aufs lib Verzeichnis im HoBo macht, kommt der u.g. Baum zum Vorschein. Das meiste davon sind einfach nur "Schall und Rauch" Namen, ein Experiment/Stoffsammlung wegen diesem Thread: https://forum.fhem.de/index.php/topic,109986.msg1042524.html#msg1042524

Es sollte aber zeigen wieviel "Luft nach oben" man mit so einem Namensschema für die Module hat.

lib/
+- Devel
+- Device
|   `- MySensors
+- Export
+- Gentoo
+- HoBo
|   +- Component
|   +- Module
|   |   +- Air
|   |   +- Control
|   |   +- Energy
|   |   +- Multimedia
|   |   +- Security
|   |   +- Service
|   |   +- UI
|   |   `- Water
|   +- Protocol
|   |   +- 1Wire
|   |   +- Broetje
|   |   +- Buderus
|   |   +- ECS
|   |   +- EnOcean
|   |   +- Fronius
|   |   +- Gardena
|   |   +- Gavazzi
|   |   +- HomeConnect
|   |   +- HomeMatic
|   |   +- Husqvarna
|   |   +- InterTechno
|   |   +- KNX
|   |   +- Kostal
|   |   +- Lemmonbeat
|   |   +- MQTT
|   |   +- Proteus
|   |   +- SMA
|   |   +- Vaillant
|   |   +- Victron
|   |   +- Viessmann
|   |   `- ZWave
|   +- Self
|   +- System
|   `- Topic
|       +- Environ
|       |   +- Air
|       |   |   +- Humidity
|       |   |   +- Quality
|       |   |   `- Ventilation
|       |   +- EMS
|       |   +- PR
|       |   `- Temp
|       |       `- AC
|       +- Multimedia
|       |   +- Console
|       |   +- Player
|       |   +- Recorder
|       |   `- TV
|       +- Resource
|       |   +- Energy
|       |   |   +- Heat
|       |   |   `- Power
|       |   |       +- BMS
|       |   |       +- Charger
|       |   |       +- Combi
|       |   |       +- Inverter
|       |   |       `- Meter
|       |   +- HHO
|       |   +- LPG
|       |   `- Water
|       +- Safety
|       +- Security
|       +- Service
|       `- UI
+- HomeBot
+- Method
|   `- Generate
+- Module
|   `- Pluggable
+- Moo
|   `- HandleMoose
+- Net
|   +- MQTT
|   |   `- Message
|   `- SNMP
|       +- Security
|       `- Transport
|           +- IPv4
|           `- IPv6
+- Protocol
|   `- WebSocket
|       +- Cookie
|       `- Handshake
`- Sub


Statt HoBo, stellt euch einfach FHEM vor. Sind ja genauso viele Buchstaben.  ;)
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: RichardCZ am 16 Mai 2020, 14:44:48
Zitat von: Christoph Morrison am 16 Mai 2020, 14:37:44
Man muss differenzieren: Code, der nur im Kontext von FHEM läuft, gehört IMHO unter $modpath/lib/FHEM/ (dahin gehört übrigens auch IMHO $modpath/lib/FHEM/MyUtils und das sollte auch ein gesperrtes Verzeichnis für den Code aus 99_myUtils sein!). Code, der auch standalone laufen würde, gehört unter $modpath/lib/. D.h. beide Pfade sind ok, weil sie unterschiedliche Dinge abbbilden. Siehe mein Posting (https://forum.fhem.de/index.php/topic,111125.msg1053700.html#msg1053700).

Stimmt - bis auf $modpath.
Statt $modpath nimmst Du $projectroot
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 16 Mai 2020, 14:47:05
Zitat von: RichardCZ am 16 Mai 2020, 14:44:48
Stimmt - bis auf $modpath.
Statt $modpath nimmst Du $projectroot

Ich bezog mich auf das, was wir heute als $defs{global}{modpath} kennen um nicht noch eine Unbekannte einzufügen, denn mein Eindruck ist, dass die Diskussion eh schon recht verwirrend ist.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 16 Mai 2020, 14:47:29
@RichardCZ
Bedeutet für mein ASC aber weiterhin das ich es nicht zerlegen kann da es ja eigentlich alles unter lib/FHEM müsste nach Deiner Logik.
Ich würde es dennoch gerne erstmal irgendwie angehen wollen und würde das ganze unter
lib/Automation/ShuttersControl.pm
lib/Automation/ShuttersControl/...
lib/Automation/ShuttersControl/.../...

versuchen. Oder gibt es andere Vorschläge?
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 16 Mai 2020, 15:03:00
Zitat von: CoolTux am 16 Mai 2020, 14:47:29
Bedeutet für mein ASC aber weiterhin das ich es nicht zerlegen kann da es ja eigentlich alles unter lib/FHEM müsste nach Deiner Logik.

Bin zwar nicht Richard, aber was hindert dich daran, deine Sachen erstmal unter $projectroot/lib/FHEM/.. einzusortieren und das dann peu à peu zu refaktorieren, bis du den FHEM-abhängigen Teil wirklich unter $projectroot/lib/FHEM/ und den unabhängigen Teil in einem CPAN-Paket oder unter $projectroot/lib/ liegen hast?
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 16 Mai 2020, 15:31:01
Zitat von: Christoph Morrison am 16 Mai 2020, 15:03:00
Bin zwar nicht Richard, aber was hindert dich daran, deine Sachen erstmal unter $projectroot/lib/FHEM/.. einzusortieren und das dann peu à peu zu refaktorieren, bis du den FHEM-abhängigen Teil wirklich unter $projectroot/lib/FHEM/ und den unabhängigen Teil in einem CPAN-Paket oder unter $projectroot/lib/ liegen hast?

Zitat von: rudolfkoenig am 16 Mai 2020, 12:02:42
- lib/FHEM ist nicht erlaubt.

Also brauchen wir eine andere Idee.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 16 Mai 2020, 15:32:24
Zitat von: CoolTux am 16 Mai 2020, 15:31:01
Also brauchen wir eine andere Idee.

Darüber diskutieren wir doch gerade. Ich glaube, dass Rudi Richard nur falsch verstanden hat.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: RichardCZ am 16 Mai 2020, 16:12:15
Zitat von: CoolTux am 16 Mai 2020, 14:47:29
@RichardCZ
Bedeutet für mein ASC aber weiterhin das ich es nicht zerlegen kann da es ja eigentlich alles unter lib/FHEM müsste nach Deiner Logik.
Ich würde es dennoch gerne erstmal irgendwie angehen wollen und würde das ganze unter
lib/Automation/ShuttersControl.pm
lib/Automation/ShuttersControl/...
lib/Automation/ShuttersControl/.../...

versuchen. Oder gibt es andere Vorschläge?

"meine Logik" - zuviel der Ehre.  ;)
Ich bin nur der Bote.

Ich weiß nicht wie weit ShuttersControl FHEM-unabhängig ist. Ich meine wenn es Jalousienregelung auf einem abstrakten Niveau anbietet (anbieten würde) und FHEM wäre sozusagen nur eine Exekutive für die ASC Logik, dann wäre es FHEM-unabhängig.

Falls die aber unscheidbar miteinander verheiratet sind, dann eben lib/FHEM/

(und dann vmtl. direkt ShuttersControl und man spare sich das Automation, das ist schon in FHEM)

Aber das tolle an diskreten Namespaces mit wohldefinierten APIs und ohne globale Variablen ist ja, dass man sie relativ leicht und flockig umbenamsen kann.
ASC kann ja unter lib/FHEM leben und mit der Zeit könnte das ein abstraktes/FHEM-unabhängiges Modul werden. Vielleicht, eventuell, möglicherweise.
Das muss man jetzt nicht klären.

Wichtig ist doch nur, dass man ein Konzept hat wo man alle diese künftigen Namespaces, von denen keiner von uns heute genau weiß (mich eingeschlossen) wie sie konkret heißen werden, ablegen kann.

@Cool/Christoph

"was hindert dich daran, deine Sachen erstmal..."

genau! Das hin und herverschieben von Modulen ist eigentlich kein großer Act. Auch ich kenne die finale Namensgebung der Module eines FHEM oder HoBo im Jahr 2100 nicht. Aber ich weiß FHEM-spezifische Module sollten unter lib/FHEM leben, allgemeine Module unter lib und HoBo-spezifische Module unter lib/HoBo

Und im Zweifelsfall kann man ein FHEM::ShuttersControl einfach so lassen, oder nach HoBo::Shutterscontrol umbenennen, oder ein HoBo::SNMP::Manager nach FHEM::SNMP::Manager umbenennen (oder so lassen) ... geht alles. Mir war nur wichtig den Rahmen zu zeigen in dem wir dann alle tünchen können.

Also nochmal:

FHEMROOT/lib gibt es noch nicht, ergo kann es momentan kein FHEMROOT/lib/FHEM geben. "Ist nicht erlaubt" stimmt in der Hinsicht nicht.

Falls man sich auf $modpath bezogen hat, also FHEMROOT/FHEM, dann ja, dann ist

FHEMROOT/FHEM/lib/FHEM

echt verboten. Da langt man sich doch sonst an den Kopf.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 16 Mai 2020, 16:42:05
Wenn lib/FHEM ok sein soll, dann kommen nach t/FHEM sowohl die "echten" FHEM Module (wie t/FHEM/00_MQTT2_SERVER), wie auch die Packages (wie t/FHEM/Weather/Buienradar). Das finde ich etwas verwirrend, aber von mir aus.

Verstehe ich also richtig: lib/FHEM ist OK, und in t/FHEM gibt es "Gedraenge"?

ZitatDas hin und herverschieben von Modulen ist eigentlich kein großer Act.
Achtung: das FHEM update Befehl macht sowas (noch?) nicht mit.
Habe z,Zt. auch kein Plan, wie das funktionieren soll.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: RichardCZ am 16 Mai 2020, 17:08:42
Zitat von: rudolfkoenig am 16 Mai 2020, 16:42:05
Wenn lib/FHEM ok sein soll, dann kommen nach t/FHEM sowohl die "echten" FHEM Module (wie t/FHEM/00_MQTT2_SERVER), wie auch die Packages (wie t/FHEM/Weather/Buienradar). Das finde ich etwas verwirrend, aber von mir aus.

Es ist dank der 00_XYZ, 98_Foo, ... Module etwas Nonstandard, aber als verwirrend würde ich es jetzt nicht bezeichnen.

ZitatVerstehe ich also richtig: lib/FHEM ist OK, und in t/FHEM gibt es "Gedraenge"?

lib/FHEM immer relativ zur Projektroot - ist ok (müsste es aber erst lib geben).

Gedränge ist relativ, es gibt da hierarchische Bäume drin (wie t/FHEM/Weather/Buienradar - das ist der eigentliche Standard) und es gibt dort eben die Legacy
00_xyz als "Flachland". Und auch wenn das Verzeichnis FHEM ziemlich voll erscheinen mag (hey: das ist das Projekt, da gibt es eben viele FHEM::* Dateien), dann ist alles am richtigen Ort gekapselt und ein t/Device/MySensors oder t/Moo oder oder ... läuft dem nicht in die Quere - und vice versa.
Eigentlich kann man sogar garantieren dass dem künftig nie jemand in die Quere läuft, wenn man z.B. auf CPAN den FHEM-Namespace für sich beansprucht - was man machen kann.

Zitat
Achtung: das FHEM update Befehl macht sowas (noch?) nicht mit.
Habe z,Zt. auch kein Plan, wie das funktionieren soll.

Muss er IMHO auch nicht. Soweit ich das verstanden habe löschst Du ja eh keine Files beim update, also angenommen ein Modul wird umbenamt, dann bleibt das Alte an Ort und Stelle und das Neue wird neu angelegt. Sammelt sich im Laufe der Zeit ne "Kruste" an, aber prinzipiell sollte das tun. Ein Aufräumskript kann ja ein ambitionierter Lehrling als Hausaufgabe bekommen.  ;)
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 21 Mai 2020, 13:30:33
Habe:
- fhem.pl geaendert, damit $modpath, $modpath/lib und $modpath/FHEM _vorne_ im @INC sind (bisher war $modpath und $modpath/FHEM hinten).
- contrib/fhemupdate.pl umgebaut, damit in lib rekursiv nach .pm Dateien gesucht wird. Achtung: MOVE oder gar REMOVE ist nicht implementiert.
- contrib/pre-commit geaendert, damit lib/.*.pm genauso nach SVN Id geprueft wird, wie FHEM/.*.pm
- contrib/fhemupdate.control.fhem gekuerzt, damit das 5 Jahre alte reorg der .js und .css Dateien (move nach unused) nicht mehr gemacht wird.
- Code fuer Update-Kompatibilitaet mit FHEM 5.5 (2013-09 bis 2014-11) ausgebaut.
- kurz getestet

Dabei ist aufgefallen, dass FHEM/lib/Device/MySensors/.*.pm entfernt wurde, bis vor kurzem wurden diese Dateien per update verteilt.
Diese Dateien werden auf den Clients nicht entfernt.

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 21 Mai 2020, 13:40:30
Zitat von: rudolfkoenig am 21 Mai 2020, 13:30:33
Habe:
- fhem.pl geaendert, damit $modpath, $modpath/lib und $modpath/FHEM _vorne_ im @INC sind (bisher war $modpath und $modpath/FHEM hinten).
- contrib/fhemupdate.pl umgebaut, damit in lib rekursiv nach .pm Dateien gesucht wird. Achtung: MOVE oder gar REMOVE ist nicht implementiert.
- contrib/pre-commit geaendert, damit lib/.*.pm genauso nach SVN Id geprueft wird, wie FHEM/.*.pm
- contrib/fhemupdate.control.fhem gekuerzt, damit das 5 Jahre alte reorg der .js und .css Dateien (move nach unused) nicht mehr gemacht wird.
- Code fuer Update-Kompatibilitaet mit FHEM 5.5 (2013-09 bis 2014-11) ausgebaut.
- kurz getestet

Dabei ist aufgefallen, dass FHEM/lib/Device/MySensors/.*.pm entfernt wurde, bis vor kurzem wurden diese Dateien per update verteilt.
Diese Dateien werden auf den Clients nicht entfernt.

Vielen Dank Rudi. Ich hatte mir das vor ner halben Stunde schon angeschaut. Sieht erstmal in Ordnung aus auf den ersten Blick. Richtig testen werde ich es dann in den kommenden Wochen wenn ich ASC anfange um zu bauen. Brauche dafür aber noch etwas.


Grüße
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 03 Juni 2020, 18:15:12
Hallo,

Ich habe es nun vollbracht. ASC ist nun komplett zerlegt und entsprechend der package sind die Files erstellt. Wer sich das ganze einmal anschauen möchte ist herzlich eingeladen

https://git.cooltux.net/FHEM/mod-AutoShuttersControl/src/branch/newdirstructure



@Rudi
Noch mal herzlichen Dank für Deine Arbeit und das Du uns/mir das ganze ermöglichst. Es macht riesen Spaß auf die Art zu arbeiten da ich endlich einen besseren Überblick über die gesamte Struktur und einzelne Funktionen habe.


Grüße
Marko
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: StefanStrobel am 10 Juni 2020, 22:29:03
Hallo,

ich habe begonnen meine Fhem-Module zu überarbeiten und möchte dabei eigene Packages daraus machen.
Bei der Gelegenheit würde ich gerne ein paar Funktionen, die seither als Kopie z.B. in HTTPMOD, Modbus, ArduCounter und FReplacer liegen, an eine zentralere Stelle auszulagern. Wo wäre denn jetzt der bevorzugte Ort für eine Funktion, die ein gesetztes Regex-Attribut prüft und an userAttr anfügt (damit das Attribut per Fhemweb editierbar wird).


#########################################################################
# set userAttr-Attribute for Regex-Attrs
# pass device hash and new attr based on a regex attr
sub HTTPMOD_ManageUserAttr
{                     
    my ($hash, $aName) = @_;       
    my $name    = $hash->{NAME};
    my $modHash = $modules{$hash->{TYPE}};

    if ($modHash->{AttrList} =~ m{  (?:\A|\s)
                                    $aName
                                    (?: \s | \: | \z)
                                }xms) {                             # does AttrList contain the passed attribute (potentially with an added hint) -> no regex attr?
        my $retVal;
        if ($aName =~ m{ \| \* \+ \[}xms) {                         # contained in list -> make sure nobody tries to set it as regex attr
            $retVal = "$name: Atribute $aName is not valid. It still contains wildcard symbols";
            Log3 $name, 3, $retVal;
        }
        return $retVal;
    }
    foreach my $listAttr (split " ", $modHash->{AttrList}) {
        my ($listAttrName, $listAttrHint)
            = $listAttr =~ m{ \A ([^:]+) (:?.*) }xms;               # split list entry in name and optional hint
        if ($aName =~ m{\A$listAttrName\z}xms) {                    # yes - the passed attribute name now matches the entry in the list as regex
            addToDevAttrList($name, $aName . $listAttrHint);        # create userattr with hint to allow change in fhemweb
            #Log3 $name, 5, "$name: ManageUserAttr added attr $aName to userattr list";

            if ($listAttrHint) {                                    # in case an earlier version added the attribute without the hint, remove old entry
                my $uaList = $attr{$name}{userattr} // '';
                my %uaHash;
                foreach my $userAttr (split(" ", $uaList)) {
                    if ($userAttr !~ m{\A $aName \z}xms) {          # no match -> existing entry in userattr list is attribute without hint
                        $uaHash{$userAttr} = 1;                     # put $userAttr as key into the hash so it is kept in userattr list
                    } else {                                        # match -> in list without attr -> remove
                        #Log3 $name, 5, "$name: ManageUserAttr removes attr $userAttr without hint $listAttrHint from userattr list";
                    }
                }
                $attr{$name}{userattr} = join(" ", sort keys %uaHash);
            }
        }
    }
}


Soll ich dafür (und für ähnliche Funktionen) eine eigene "Bibliothek" anlegen? Wo müsste die dann hin?
Oder passen solche Funktionen in eine gemeinsame neue Bibliothek wie z.B. "AttrUtils"?
Oder etwas ganz anderes?

Was ist denn die empfohlene Vorgehensweise?

Gruss
   Stefan

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 10 Juni 2020, 22:32:56
Hi,

Meine Meinung, die muss nicht korrekt sein muss es in ein Package httpmod.
Da wir noch nicht wissen was es da so alles gibt könnte man z.B. mit einem attr.pm starten:

./lib/FHEM/httpmod/attr.pm

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 10 Juni 2020, 22:54:56
Ich bin gerade sehr involviert darin, meinen ganzen Code umzustellen (MyUtils, aber auch die Module) - ich bin auch schon darüber gestolpert, dass ich nun Funktionen habe, die ich generell im FHEM-Namespace sehen würde und nicht im Modul-Namespace.

Ich würde so eine Funktion unter FHEM::Attributes::Utils (also lib/FHEM/Attributes/Utils.pm einsortieren, wenn es eine generelle Funktion sein soll. Ansonsten vielleicht in FHEM::WWW::HTTPMOD? HTTPMOD kann ohne FHEM ja nicht existieren, oder?
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 10 Juni 2020, 23:02:47
FHEM::Attributes::Utils
Finde ich Recht passend.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 11 Juni 2020, 00:28:19
Hi,

ich habe eine kleine Hilfsbibliothek für das verwalten von interen Timer erstellt.
Würde das Package wie folgt verorten: FHEM::Timer::Helper;

https://github.com/fhem/lib_timer/tree/master/lib/FHEM/Timer


Vielleicht gibt es ja auch noch Zukünftig weitere Packages unterhalb von Timer.

Würde das ganze dann auch gerne ins SVN committen, damit es zur Verfügung steht.

Grüße Sidey
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 11 Juni 2020, 06:29:07
Zitat von: Sidey am 11 Juni 2020, 00:28:19
Hi,

ich habe eine kleine Hilfsbibliothek für das verwalten von interen Timer erstellt.
Würde das Package wie folgt verorten: FHEM::Timer::Helper;

https://github.com/fhem/lib_timer/tree/master/lib/FHEM/Timer


Vielleicht gibt es ja auch noch Zukünftig weitere Packages unterhalb von Timer.

Würde das ganze dann auch gerne ins SVN committen, damit es zur Verfügung steht.

Grüße Sidey

Wie wäre es mit

FHEM::Automation::Timer::Helper
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 11 Juni 2020, 10:38:42
Zitat von: CoolTux am 11 Juni 2020, 06:29:07
Wie wäre es mit

FHEM::Automation::Timer::Helper

Ginge natürlich auch, aber was bedeutet die Kategorie Automation. Was gibt es denn noch auf dieser Ebene und sind Timer immer eine Unterkategorie von Automation ?

Für mich im Moment noch wenig greifbar.

Grüße Sidey
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 11 Juni 2020, 10:38:43
Für was auch immer ihr euch entscheidet, ich hätte zwei Kandidaten, von denen ich glaube, dass sie reserviert sein sollten:

FHEM::MyUtils für den Code, den Benutzer aktuell in ihrer 99_MyUtils.pm haben
FHEM::Core für den Kern von FHEM, der aktuell in erster Linie in der fhem.pl schlummert.

Ich habe meine Sachen wie folgt einsortiert (WiP, deshalb mag sich das noch ändern):

FHEM::MyUtils, wie oben geschrieben liegt da nun der Code, der früher in 99_MyUtils lag.
FHEM::Test::Mock - Gemockte FHEM-Funktionen für meine Unit-Tests
FHEM::Weather::Buienradar, FHEM-spezifischer Teil von Buienradar
FHEM::WWW::Serienjunkies::Latest, FHEM-spezifischer Teil meines Testmoduls
FHEM::App::* - Kommandozeilen-Skripte wie der Modul-Generator, log2db, Generator für Control-Files, etc.
FHEM::Misc::FertilityCalendar - Fruchtbarkeitskalender für FHEM
etc. pp.

Aktuell überlege ich noch, was ich mit den Nicht-FHEM-spezifischen-Teilen mache. Hab mir jetzt mal einen PAUSE-Account beantragt und ggf. schiebe ich den dann direkt ins CPAN. Wir müssen dann die Nutzer dann halt dahin gehend erziehen, dass sie cpanm ausführen können bzw. legen ihnen einen Installer nahe, der notwendige Module installiert (so wie der von Loredo). Wenn wir diese Hürde mal genommen haben, könnte die Funktionalität von FHEM deutlich umfangreicher werden, denn es gibt im CPAN wirklich hunderte interessanter Module, die letztlich nur einen Wrapper für FHEM brauchen, z.B. Sendungsverfolgungen, die ganzen Google-Services, Wikidata, etc. etc.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 11 Juni 2020, 10:41:01
Beim Schreiben meines Postings eben habe ich noch mal über die Frage von Stefan nachgedacht und ich glaube, ich würde es eher unter FHEM::Core::Attributes::Utils einsortieren, aus den eben beschriebenen Gründen (Attribute sind ein Kernfeature von FHEM).

Die Timer-Lib von Sidey würde ich unter FHEM::Core::Timer::Helper einsortieren, denn - gleiche Argumentation - Timer sind Kernfeature von FHEM.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 11 Juni 2020, 10:44:10
Stimme Dir zu, ist wirklich besser da aufgehoben.

@Stefan
Automation ist in meinen Augen sowas wie notify, DOIF oder auch für mich relevant AutoShuttersControl
https://git.cooltux.net/FHEM/mod-AutoShuttersControl
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 11 Juni 2020, 10:44:35
Zitat von: Christoph Morrison am 11 Juni 2020, 10:38:43

FHEM::Test::Mock - Gemockte FHEM-Funktionen für meine Unit-Tests

Ich habe die bislang immer in meine Testscript hinterlegt.
Das in ein Package packen ist sicher gut, gehört das aber in den FHEM oder in einen Test Namespace ?

Grüße Sidey
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 11 Juni 2020, 10:54:12
Zitat von: Sidey am 11 Juni 2020, 10:44:35
Ich habe die bislang immer in meine Testscript hinterlegt.
Das in ein Package packen ist sicher gut, gehört das aber in den FHEM oder in einen Test Namespace ?

Es gehört halt in einen Test-Namespace der exklusiv zu FHEM gehört (zumindest so lange z.B. ReadingsVal($#!% (https://en.wiktionary.org/wiki/grawlix)) noch in fhem.pl und nicht in FHEM::Core::Readings liegt ;-) )

Test::Mock ist außerdem ein CPAN-Modul und ggf. kollidiert hier etwas.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 11 Juni 2020, 11:00:09
( Ich habe übrigens im Github mal eine Doku angefangen, die dann später inschallah auch ins Wiki soll): Namespaces (https://github.com/fhem/doc-wiki/blob/master/DE/Namespaces.md)

Ihr seid natürlich eingeladen zu forken und PR'en)
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Sidey am 11 Juni 2020, 15:31:53
Zitat von: Christoph Morrison am 11 Juni 2020, 10:54:12
Es gehört halt in einen Test-Namespace der exklusiv zu FHEM gehört (zumindest so lange z.B. ReadingsVal($#!% (https://en.wiktionary.org/wiki/grawlix)) noch in fhem.pl und nicht in FHEM::Core::Readings liegt ;-) )

Ich war eher am Überlegen ob es nicht eher Test::FHEM::Mock anstelle FHEM::Test::Mock.

Wenn ich dann etwas außerhalb Fhem teste wäre das auch in Test::irgendwas::...


Gruß Sidey

Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KernSani am 11 Juni 2020, 17:41:35
Hallo zusammen,
nachdem ich gerade eine kleine myUtils Routine schreiben wollte, dachte ich mir ich probiere das mal in der neuen Struktur. Funktioniert auch wunderbar, allerdings habe ich ein kleines Problem (wahrscheinlich stelle ich mich einfach dumm an):
* Beim erstmaligen "reload 99_myUtils" wird brav meine FHEM::myUtils::meineSub geladen
* nach einer kleinen Änderung von meineSub und erneutem "reload 99_myUtils" zieht die Änderung leider nicht
* Ein reload lib/FHEM/... geht nicht, weil reload slashes verbietet.
Wie bekomme ich jetzt meine geänderte sub ge-reloaded?
Danke,
Oli
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: rudolfkoenig am 11 Juni 2020, 17:56:11
Reload laedt nur "FHEM-Module" aus dem FHEM Verzeichnis.
Wenn diese wiederum andere Dateien laden, dann muss das reload dieser Dateien mit "eigenen" Mitteln passieren, z.Bsp. mit
{ do "lib/FHEM/myUtils/meineSub.pm" }


Das gilt auch fuer HttpUtils.pm, wenn man es erneut reinladen will, insofern gibt es keine Sonderbehandlung.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: KernSani am 11 Juni 2020, 18:35:15
Zitat von: rudolfkoenig am 11 Juni 2020, 17:56:11
Reload laedt nur "FHEM-Module" aus dem FHEM Verzeichnis.
Wenn diese wiederum andere Dateien laden, dann muss das reload dieser Dateien mit "eigenen" Mitteln passieren, z.Bsp. mit
{ do "lib/FHEM/myUtils/meineSub.pm" }

Thanks :-) Passt.

Das gilt auch fuer HttpUtils.pm, wenn man es erneut reinladen will, insofern gibt es keine Sonderbehandlung.
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: Christoph Morrison am 11 Juni 2020, 20:30:29
Hat ne Weile gedauert bis ich deine Antwort in dem Zitat gefunden hatte  :D
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: StefanStrobel am 16 August 2020, 17:52:43
Nur noch mal zur Sicherheit dass ich es auch richtig verstanden habe:

Wenn ich jetzt die Funktionen von HTTPMOD, die ich auch in anderen Modulen verwende, als package FHEM::HTTPMOD::Utils im Verzeichnis lib/FHEM/HTTPMOD/ ablege bzw. einchecke, dann wird das auch per Update verteilt und danach kann ich ein neues HTTPMOD mit eigenem Namespace als package HTTPMOD zum Testen posten?

Tests für HTTPMOD (habe ich inzwischen einige geschrieben) würde ich dann unter t/FHEM/98_HTTPMOD einchecken?

Gruss
   Stefan
Titel: Antw:Anfrage Erweiterung der Verzeichnisstruktur
Beitrag von: CoolTux am 16 August 2020, 18:41:05
Zitat von: StefanStrobel am 16 August 2020, 17:52:43
Nur noch mal zur Sicherheit dass ich es auch richtig verstanden habe:

Wenn ich jetzt die Funktionen von HTTPMOD, die ich auch in anderen Modulen verwende, als package FHEM::HTTPMOD::Utils im Verzeichnis lib/FHEM/HTTPMOD/ ablege bzw. einchecke, dann wird das auch per Update verteilt und danach kann ich ein neues HTTPMOD mit eigenem Namespace als package HTTPMOD zum Testen posten?

Tests für HTTPMOD (habe ich inzwischen einige geschrieben) würde ich dann unter t/FHEM/98_HTTPMOD einchecken?

Gruss
   Stefan

Ja das ist korrekt.