Anfrage Erweiterung der Verzeichnisstruktur

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

Vorheriges Thema - Nächstes Thema

DS_Starter

#45
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).
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wuppi68

schliesse mich DS_Starter an.

Das könnte auch das Cut & Paste etwas eindämmen
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

CoolTux

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

M.Schulze

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
Muss ich das Licht aus machen?

CoolTux

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

CoolTux

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

Thorsten Pferdekaemper

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
FUIP

Christoph Morrison

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.

Sidey

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

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

rudolfkoenig

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.

CoolTux

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

Christoph Morrison

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.

rudolfkoenig

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 bzw. in der folgenden Begruendung.


KölnSolar

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

RichardCZ

Zitat von: rudolfkoenig am 16 Mai 2020, 13:05:16
Die Begruendung liegt in dieser Bitte bzw. in der folgenden Begruendung.

@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.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.