Autor Thema: Anfrage Erweiterung der Verzeichnisstruktur  (Gelesen 2732 mal)

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #30 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   

 
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...
Gefällt mir Gefällt mir x 2 Zustimmung Zustimmung x 1 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25322
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #31 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.
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://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22328
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #32 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.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5605
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #33 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.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3496
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #34 am: 13 Mai 2020, 18:00:30 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22328
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #35 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.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25322
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #36 am: 13 Mai 2020, 18:10:58 »
Eine überarbeitete Version für mich wäre

Zitat
lib/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://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22328
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #37 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.

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

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1127
  • Maintainer von 12 Modulen + holiday-Files
    • Private Website
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #38 am: 13 Mai 2020, 18:46:48 »
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.
Maintainer von:
holidays · 59_Twilight · contrib/sacha_gloor · Buienradar

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4720
  • Are we just self-replicating DNA?
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #39 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.

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4720
  • Are we just self-replicating DNA?
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #40 am: 13 Mai 2020, 18:50:28 »
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!

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1127
  • Maintainer von 12 Modulen + holiday-Files
    • Private Website
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #41 am: 13 Mai 2020, 19:48:22 »
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.



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.

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
Maintainer von:
holidays · 59_Twilight · contrib/sacha_gloor · Buienradar

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #42 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....
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22328
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #43 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

Zitat
Aktuelles 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?

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3372
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #44 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.
Zitat
Btw: 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, ...
Zustimmung Zustimmung x 1 Liste anzeigen