Anfrage Erweiterung der Verzeichnisstruktur

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

Vorheriges Thema - Nächstes Thema

KernSani

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   

 
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

CoolTux

Danke Oli, so sehe ich das auch. Habe auch geschrieben das ich kein Problem mit einer "negativen" Entscheidung habe.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

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.

herrmannj

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.

Wzut

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
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

rudolfkoenig

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.

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

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.

Christoph Morrison

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.

Dr. Boris Neubert

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.

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Christoph Morrison

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

KernSani

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....
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

rudolfkoenig

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?

KernSani

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....
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...