FHEM Forum

https://pmd.github.io/latest/pmd_userdocs_cpd.html

Ich habe mal CPD, den Copy & Paste Detektor über FHEM gejagt.

Die Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz Joseph Sylvester Buhl-Freiherr von und zu Guttenbergs sind im Anhang aufgeführt.

Den Grund, warum man Duplikate vermeiden sollte spare ich mir an dieser Stelle, o.g. Link hat eine nette Zusammenfassung. Für mich kann ich nur sagen, das Dupletten im Code einer der größten Schandflecke sind von die wo's gibt. Ich wäre zutiefst betrübt wieder eine Diskussion zu erleben warum gerade in FHEM 1:1 Code-Duplikate ein Muss oder "schon in Ordnung" sind.

Besserwisser: Du sprichst von Dublette(n)?!

Wobei eine Dublette und ein Duplikat unterschiedliche Sachverhalte beschreiben.


Gesendet von iPad mit Tapatalk

Zitat von: JoWiemann am 11 April 2020, 09:58:18
Besserwisser: Du sprichst von Dublette(n)?!

Wobei eine Dublette und ein Duplikat unterschiedliche Sachverhalte beschreiben.

Ja, da ist das Englische "Dupe" mit mir durchgegangen.

ZitatIch wäre zutiefst betrübt wieder eine Diskussion zu erleben warum gerade in FHEM 1:1 Code-Duplikate ein Muss oder "schon in Ordnung" sind.

Das wirst du von mir auch nicht hoeren, ich vermeide Duplikate, wo ich kann, stellenweise schon krankhaft.

Allerdings ist FHEM ein Gemeinschaftsprojekt, und aus Sicht eines Benutzers ist ein Modul, was Code kopiert, besser, als gar kein Modul. Das heisst nicht, dass ich das toll finde, ich weiss aber nicht, wie ich das ohne Maintainer abzuschrecken verbessern soll. Ich sehe den typischen Maintainer als den Familenvater, der ein Problem mit FHEM loesen kann, dafuer zwangsweise ein bisschen Perl lernt, aus Nettigkeit sein Code spendiert, aber nicht vor hat seine Familie fuer FHEM zu verlassen, und ein Perl-Guru will er auch nicht werden.

Ich mache mir sorgen, dass Deine unsanften Hinweise, auch wenn alleine betrachtet meist richtig sind, manche davon abhalten ein Modul zu veroeffentlichen. Nach dem Motto: lieber die Klappe halten, als ausgelacht werden.

Ich bin immer noch bei meinem urspruenglichen Vorschlag: mach Beispielmodule, und wir empfehlen diese als Grundlage fuer Neulinge.

Naja, für mich kann ich es beantworten. In GSI habe ich Code welcher funktioniert und den brauche ich auch in JsonMod. Weil Module self-contained sein sollen kopiere ich den halt rüber. Wenn wir das lockern sollten wäre ich happy den code auszulagern und in beiden Modulen zu verwenden. Um ehrlich zu sein weiß ich zwar nicht wo die Regel steht aber ich meine mich an Diskussionen zu erinnern und das Fazit war 'ein Modul, eine Datei'. Eventuell ist das aber gar nicht mehr aktuell (?)

Zitat von: rudolfkoenig am 11 April 2020, 10:26:42
Familenvater, der ein Problem mit FHEM loesen kann, dafuer zwangsweise ein bisschen Perl lernt, aus Nettigkeit sein Code spendiert, aber nicht vor hat seine Familie fuer FHEM zu verlassen, und ein Perl-Guru will er auch nicht werden.

Ich mache mir sorgen, dass Deine unsanften Hinweise, auch wenn alleine betrachtet meist richtig sind, manche davon abhalten ein Modul zu veroeffentlichen. Nach dem Motto: lieber die Klappe halten, als ausgelacht werden.

Ich bin immer noch bei meinem urspruenglichen Vorschlag: mach Beispielmodule, und wir empfehlen diese als Grundlage fuer Neulinge.

Du willst Beispielmodule im gegebenen Rahmen. Das geht nicht, der Rahmen ist zu klein.
Ich kann aus einem Golf I keinen Veyron machen und einen Spoiler draufpappen und Streifen draufmalen betrachte ich nicht als "Beispielmodul".

Lass uns darüber reden den Rahmen an einigen Stellen zu verbessern, dann kann man auch wirklich auf bessere Beispiele hoffen:
https://forum.fhem.de/index.php/topic,110036.msg1040579.html#msg1040579
Was nicht bedeutet, dass die Anleitung wie man bessere FHEM Module auch in diesem Rahmen baut bereits erarbeitet wird:
https://forum.fhem.de/index.php/topic,110048.0.html (u.a.)

---

Diese Argumentation mit "Perl Guru" entlarvt an dieser Stelle die Diskussion als ein reines Sammelsurium von Schutzbehauptungen. Hier geht es nicht um Perl. Hier geht es um Softwareentwicklung im Allgemeinen. PMD-CPD unterstützt 20 oder 30 Sprachen, da ist Perl nur eine davon. Code Dpulikate sind in jeder Sprache ein Graus und zu vermeiden. Da gibt es auch nicht viel zu diskutieren.

Ich habe noch nie jemanden wegen seinem Code ausgelacht. Ich kann mich über Code lustig machen, nicht über die Person dahinter. Siehe
https://forum.fhem.de/index.php/topic,109511.0.html

Das Argument mit "besser als nix", "einem geschenkten Gaul" etc. verstehe ich. Was ich aber nicht verstehe, dass man bei FHEM in diesem zusammenhang die verquere Regel hat, dieser nette Amateurspender habe die alleinige Hoheitsgewalt über diesen seinen gespendeten GPL code(!) im Repo. Thema Janitors wieder. Das macht das FHEM-Entwicklungsmodell zu einem altbackenen "wir entwickeln nicht gemeinsam, sondern so nebeneinander her".

PS:

Und bitte, schiebt euch den "Perl Guru" sonstwohin. Perl macht 5% meines Skill Sets aus. Wer mich nur darauf reduzieren will, wird früher oder später seinen tiefenpsychologischen Aha-Effekt erleben.

Zitat von: herrmannj am 11 April 2020, 10:52:40
Weil Module self-contained sein sollen kopiere ich den halt rüber.

Bitte was sollen die sein??? Was soll das überhaupt bedeuten? Alles in einem File oder was?

Dann macht natürlich das ~1MB EnOcean.pm "Sinn". Gibt es noch mehr so Regeln von denen man wissen sollte? z.B. nur in Unterhose programmieren oder so?

Zitat von: RichardCZ am 11 April 2020, 11:36:16
Bitte was sollen die sein??? Was soll das überhaupt bedeuten? Alles in einem File oder was?

Ja, alles in einem file.

Zitat
Gibt es noch mehr so Regeln von denen man wissen sollte? z.B. nur in Unterhose programmieren oder so?

Bist heute auf Stress gebürstet. :) Und ja, ich trage regelmäßig eine Unterhose beim programmieren. Aber hey, was immer Du willst (aber bitte, bitte, keine Details hier posten!!!)  :D :D :D

Zitat von: herrmannj am 11 April 2020, 12:04:36
Ja, alles in einem file.

Super. Womit der Rahmen nochmal ein Stück kleiner geworden ist.
Und meine Anleitung hier: https://forum.fhem.de/index.php/topic,110048.0.html
ist demnach "laut den gegenwärtigen FHEM Regeln"(tm) fürn Arsch. Soviel zu "Beispielmodul".

Sorry. Ich kann ja verstehen wenn man vor 15 Jahren mal falsche Designentscheidungen und irgendwelche seltsamen (um nicht zu sagen: komischen)  Regeln aufgestellt hat. Weil man es entweder nicht besser wusste oder weil es damals(!) Sinn gemacht hat. Aber der Zeitpunkt ab dem ein Verteidigen dieser Anachronismen kafkaesk wird ist verdammt nah - wenn wir ihn nicht bereits überschritten haben.

---

Hey - warum wusste ich, dass wenn ich wieder ein Thema aufmache bei dem es nix zu Diskutieren gibt, dass dennoch eine Diskussion mit Nebenschauplätzen erfolgt? Muss irgendein FHEMVID-05 hier sein.

Zitat von: RichardCZ am 11 April 2020, 12:12:31
...
ist demnach "laut den gegenwärtigen FHEM Regeln"(tm) fürn Arsch. Soviel zu "Beispielmodul".

Kaum zu glauben dass es überhaupt Module gibt .. ;) So, aber jetzt chill mal ein wenig und genieß das Wetter !

Mittlerweile gibt es ja einige libs die den Weg durchaus geschafft haben. Mal schauen was der Rest zu eigenen libs sagt.

vg
Joerg

Wie kann man =pod Text zwischen CommandRef DE/EN deduplizieren?

Siehe z.B.
Found a 58 line (405 tokens) duplication in the following files:
Starting at line 4250 of /data/proj/fhem/trunk/fhem/FHEM/32_WifiLight.pm
Starting at line 4895 of /data/proj/fhem/trunk/fhem/FHEM/32_WifiLight.pm

Found a 94 line (305 tokens) duplication in the following files:
Starting at line 4746 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm
Starting at line 5324 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm

Found a 102 line (479 tokens) duplication in the following files:
Starting at line 1145 of /data/proj/fhem/trunk/fhem/FHEM/44_S7.pm
Starting at line 1251 of /data/proj/fhem/trunk/fhem/FHEM/44_S7.pm


Zitat von: amenomade am 11 April 2020, 14:56:46
Wie kann man =pod Text zwischen CommandRef DE/EN deduplizieren?

Siehe z.B.

Code Auswählen Erweitern


Found a 94 line (305 tokens) duplication in the following files:
Starting at line 4746 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm
Starting at line 5324 of /data/proj/fhem/trunk/fhem/FHEM/42_SYSMON.pm


Also selbst bei den derzeit verfügbaren bescheidenen Bordmitteln würde ich ja sowas wie

Beispiele siehe <a href="commandref_EN.html#SYSMON">EN Doku</a> machen.
Und diese eben nur an einer Stelle pflegen.

Wo das nicht geht, geht's halt nicht. Dann müsste man sich überlegen, ob =pod in einem multilingualen Umfeld die richtige Wahl ist.

Ich bin beruhigt. Die Dupletten in meinen Modulen könnt ihr ignorieren. Da wurde das veraltete RPC Modul mit dem neuen verglichen => grüne Tonne.
Wundert mich, dass da nicht mehr doppelt ist.

Zitat von: RichardCZ am 11 April 2020, 11:32:43
Was ich aber nicht verstehe, dass man bei FHEM in diesem zusammenhang die verquere Regel hat, dieser nette Amateurspender habe die alleinige Hoheitsgewalt über diesen seinen gespendeten GPL code(!) im Repo.

Ich muss ein wenig ausholen:

Ich bin Ersteller des 34_ESPEasy.pm FHEM Modules und des entsprechenden ESPEasy Firmware Controller Plugins. Und: nein, ich bin kein Programmierer oder Softwareentwickler, ich habe mir ein wenig Perl und C Syntax angeeignet um meine Bedürfnisse in FHEM umsetzen zu können.

Ich würde mich darüber freuen, wenn neben mir noch jemand meine Module betreuen würde (Code verbessern, an aktuelle Firmware Version anpassen, etc.). Derjenige müßte die Änderungen allerdings auch supporten bzw. ggf. zurück drehen, wenn es Probleme gibt. Es gibt ja zur Zeit leider keinen Test/Dev Zweig im svn...

Nachdem mein Pull Request des FHEM Controllers in das ESPEasy Projekt eingeflossen ist, ist das Plugin mehrfach von unterschiedlichen Mitstreitern angepasst und optimiert worden. Das finde ich toll und sinnvoll und es gab bisher nie Probleme und wenn, dann wäre das nach x Issues auf Github zurück gezogen oder gefixed worden, da bin ich mir recht sicher.

---

Code Duplikate und wiederverwendbaren Code erstellen:

Ich habe das ESPEasy Modul so ausgelegt, dass der Anwender die Möglichkeit hat Zugriffe auf IP Adressen/Bereich zu beschränken. Eine Möglichkeit wäre gewesen, die FHEM interne und regex basierte Variante zu benutzen. Da ich das als Netzwerker und Anwender als unbefriedigend befand, habe ich einen eigenen access controll Mechanismus eingebaut, der die Eingaben von IPs, Komma separierten Listen, Netmasks (bitmask oder dotted decimal) oder regex erlaubt und umgehe dabei den FHEM internen Mechanismus.
Klar, man jetzt sagen, warum nicht einen Patch an den Core Entwickler schicken und hoffen, dass es eingebaut wird. Mit Sicherheit ist mein Code weder optimiert, zu teuer (lahm) und nicht auf Angriffe getestet, um ihn in allen Modulen zu verwenden. Das kann ich als "Anweder" auch nicht leisten.
[EDIT:] Ggf. wäre es viel sinnvoller gewesen nach einem entsprechen CPAN Modul zu suchen, dass das viel besser kann, aber auch da ist die jetzige FHEM Policy mMn nicht sehr sinnvoll: Mach alles alleine mit möglichst wenig Abhängigkeiten... Zumindest hatte ich das damals so im Kopf.

Mein Gedanke war ursprünglich mal den Code in eine NetUtil.pm oder so auszulagern, um ihn Anderen zugänglich zu machen. Aber dann wäre ich, nach jetzigen Vorgehen (eine Datei - ein Maintainer), der Maintainer dafür gewesen und hätte die Verantwortung dafür übernehmen müssen. Das wollte und hätte ich nicht leisen können. Ganz abgesehen von dem bashing "wer braucht den sowas -  das können wir auch jetzt schon alles mit einer regex definieren".

Ich fände es gut die Prinzipien von "ein Modul -> eine Datei" und "ein Modul und niemand anderes geht daran" aufzuweichen und zu überdenken.

Was könnten die Nachteile sein, wenn "globale" Entwickler Code von anderen anfassen? Klar, irgendetwas funktioniert nicht mehr und der "globale Entwickler" hat nicht die Möglichkeit das nachzuvolluiehen, weil er zB. die Hardware nicht hat, die sich buggy verhält. Dann muss das zurück gedreht werden, aber viel besser __vorher__ in einem eigenen Branch vorab zur Verfügung gestellt werden. Auch wenn das bisher nicht so funktioniert hat wie es sollte...

---

Wie dem auch sei:

Selbst wenn @RichardCZ eine Heuschrecke seien sollte, die nach x Wochen/Monaten/Jahren weiter zieht, wäre mMn etwas positves in FHEM bewegt worden, wenn man darauf eingeht und seine Art und Weise beiseite läßt. Die Art und Weise von einigen alten Hasen ist teilweise auch recht hart und läßt Hobbyisten erstarren.

Zitat von: dev0 am 12 April 2020, 11:27:12
Was könnten die Nachteile sein, wenn "globale" Entwickler Code von anderen anfassen? Klar, irgendetwas funktioniert nicht mehr und der "globale Entwickler" hat nicht die Möglichkeit das nachzuvolluiehen, weil er zB. die Hardware nicht hat, die sich buggy verhält. Dann muss das zurück gedreht werden, aber viel besser __vorher__ in einem eigenen Branch vorab zur Verfügung gestellt werden. Auch wenn das bisher nicht so funktioniert hat wie es sollte...

Meine - wiederholte - Anspielung auf das "Janitors"-Konzept des Linux-Kernels geht ja noch nicht einmal so weit wie "Globaler" Entwickler.
Die Aufgabe eines Janitors ist es Code sauber zu machen (Stichwort: Refactoring, Dokumentation) und das beinhaltet explizit NICHT Änderungen an der Funktionalität.

D.h. ja, ohne Testsuite kann es natürlich schon mal zu Regressionen kommen, aber das sollte die Ausnahme und nicht die Regel sein, denn ein Janitor geht ja mit der Maßgabe an den Code eben nix funktional zu verändern. Ergo sollte (sollte!) eine Umformatierung des Code, perlcritic/PBP Anpassungen, Namespace Aufräumarbeiten etc. gar nicht am User ankommen.

Leider - und da muss man als Janitor auch sehr diszipliniert sein - ist es nicht nur "nix funktional ändern", sondern manchmal sogar: Behalte den gegenwärtigen Fehler bei obwohl Du es besser weist.

Ich habe z.B. an etlichen Stellen ein

my $x = shift || return 'blah';

lassen müssen, obwohl eindeutig ist, dass man

my $x = shift // return 'blah';

meinte. FHEM behandelt an ungefähr 1000 Stellen eine Eingabe von 0 "als gäbe es sie nicht", aber das zu korrigieren ist eigentlich schon knapp hinter der Grenze des Wirkbereichs eines Janitors.


PS: Eine Heuschrecke, die erst nach Jahren weiterzieht ist IMHO keine Heuschrecke mehr.

ZitatEs gibt ja zur Zeit leider keinen Test/Dev Zweig im svn...

Das ist falsch, siehe svn list svn+ssh://svn.fhem.de/branches, und keiner kraeht danach, wenn jemand einen Neuen anlegt.
Das Problem ist: es ist eine Privatveranstaltung, keiner macht sich die Muehe es zu testen. Die Entwickler nicht (die wollen ihren eigenen Kram entwickeln), und die Benutzer nicht, die wollen ein stable branch mit den neuesten Features.

Der Hintergrund zu den Maintainer-Prinzip: es hat sich nach anfaenglichen Experimenten ohne eine Richtlinie als sinnvoll erwiesen, wenn jemand weiss, was in einem Modul "los ist". Sonst baut jemand ein Feature ein, was unter anderem Namen schon gibt, und unvertraeglich mit einem dritten ist. Wenn ein Benutzer ein Problem meldet, dann zuckt der urspruengliche Entwickler sein Schulter (er hat den Mist nicht eingebaut), und der Wohlwollende auch, der will/kann gar nicht Support leisten.
Es geht darum, einen Verantwortlichen fuer ein Modul zu haben. Wenn mehrere es schaffen, das unter sich zu organisieren, ist es mir egal, aber ich will einem Maintainer garantieren, dass er die Chance hat, die Uebersicht zu behalten.

Kein Regel ohne Ausnahme: wenn ein neuer Regel (z.Bsp. bei der Formatierung der Doku) in Developer kommuniziert, und nach Monaten nicht angewendet wird, dann wird es trotzdem durchgefuehrt. Ist aber selten, und war bisher nur auf die Doku bezogen.

Wie wäre es mit einem OPT-OUT?

Wer keinen Janitor in seinem Code haben möchte, macht am Anfang eine Zeile

# FHEM-TAGS: NOJANITOR

(dann können wir uns auch noch andere Tags überlegen), und dann wird der Code in Ruhe gelassen.
Ist zwar IMHO kontraproduktiv, weil es u.U. globale Aufräumarbeiten wie min/max torpedieren kann und deswegen auch OPT-OUT und nicht OPT-IN. Wer sich dem explizit entgegenstellen will, soll das auch sagen.

Aber ich verstehe die Bedenken von Maintainern schon. Vermutlich ist die ganze Geschichte - wie so vieles - einfach nur Vertrauenssache.

"Ich habe ein Modul für das ich verantwortlich bin, da will ich nicht, dass mir das einer zerschiesst."

Dann gebe ich hiermit zu Protokoll, dass diese Sichtweise eines Maintainers richtig ist. Ich würde das genauso sehen. Wenn ich für etwas verantwortlich bin und eine drite Seite grätscht rein und verursacht eine Regression, dann drücke ich vielleicht einmal das Auge zu, beim zweiten Mal ist der OPT-OUT so schnell drin, so schnell kann keiner svn commit sagen. Bzw. ich klage bitterlich und verlange nach einem besseren Janitor.

Ich erlaube mir das Thema 'ein Modul - ein file' vs 'eigene libs' nochmals noch oben zu bringen. Bisher hat sich niemand gemeldet was idr entweder bedeutet 'kein Interesse' oder die Frage ist untergegangen.

Im ersteren Fall ist es ok. Von meiner Seite aus würde ich es begrüßen die Möglichkeit zu haben. In der Praxis findet es ja auch schon teilweise statt, ist aber imho nirgendwo sauber geregelt.

Ich wäre dafür zu versuchen einen modernen Programmierstil ein zu führen.
Klassen Unterteilung und Bibliotheken wo wir mehrfach vorkommenden Code auslagern.

Zitat von: herrmannj am 12 April 2020, 12:57:25
Ich erlaube mir das Thema 'ein Modul - ein file' vs 'eigene libs' nochmals noch oben zu bringen.

Ich wollte da ursprünglich bitten etwas Nachforschung zu betreiben. Sprich: gibt es diese Regel wirklich irgendwo oder ist das nur so ein Mythos?
Du konntest die ja laut eigener Aussage auch nirgends finden.

Denn für gewöhnlich ist die Verwendung von mehr als einem package pro File zwar möglich, aber wird nicht als gute Praxis angesehen.
(siehe z.B. https://perlmaven.com/packages-modules-and-namespace-in-perl)

Und vom technischen her gibt es auch nicht viel zu diskutieren. Die ganze use/require Infrastruktur von Perl geht davon aus, dass man ein

use FHEM::Washlet::TOTO;

auch in einem @INC Verzeichnis unter FHEM/Washlet/TOTO.pm vorfindet.

Ich weiß, dass ich mir mit solchen Aussagen nicht viele Freunde mache, aber gegenwärtig weiß ich echt nicht wie man in einem Perl Projekt dieses filename <-> package name schlimmer machen könnte, als es gegenwärtig in FHEM praktiziert wird. Also selbst wenn ich bewusst wollte - weiß ich nicht wie. Und meine Fantasie ist nicht gering.

Ich hätte auc noch was. Als ich das 38_BEOK Modul geschrieben habe brauchte ich Perl Code für das Broadlink Protokoll.
Was lag also näher als alles was ich brauchte mir aus 38_Broadlink zu "borgen" und im Kopf meines Moduls eine Zeile zu hinterlassen :
# Broadlink protocol parts are stolen from 38_Broadlink.pm :) , THX to daniel2311
Wie bitte löst man sowas elegant ? Die betroffenen Subs in eine eigene Datei auslagern ? und wer ist dann für diese Datei vernatwortlich ?
bzw. der andere Maintainer muß dabei auch mitspielen und sein Modul auch anpassen.

Zitat von: Wzut am 12 April 2020, 13:44:13
Ich hätte auc noch was. Als ich das 38_BEOK Modul geschrieben habe brauchte ich Perl Code für das Broadlink Protokoll.
Was lag also näher als alles was ich brauchte mir aus 38_Broadlink zu "borgen" und im Kopf meines Moduls eine Zeile zu hinterlassen :

Code Auswählen Erweitern

# Broadlink protocol parts are stolen from 38_Broadlink.pm :) , THX to daniel2311
Wie bitte löst man sowas elegant ? Die betroffenen Subs in eine eigene Datei auslagern ? und wer ist dann für diese Datei vernatwortlich ?
bzw. der andere Maintainer muß dabei auch mitspielen und sein Modul auch anpassen.

Elegant löst man sowas so, dass es ein

FHEM::Broadlink

unter FHEM/Broadlink.pm gibt

und Du machst dann in Deinem Modul ein

use FHEM::Broadlink qw(magic_sub);

Falls ich das recht verstanden habe, diskutieren wir gerade ob wir künftig elegant wollen.

ZitatSprich: gibt es diese Regel wirklich irgendwo oder ist das nur so ein Mythos?

Wenn man ein Schreibzugriff aus SVN bekommt, kriegt man die:

ZitatStandard Belehrung:
========
- nur die eigenen Module modifizieren, sonst dem Maintainer Patches schicken.
- nach FHEM kommen nur die Module, die dokumentiert und im Forum betreut sind
  (siehe MAINTAINER.txt), sonst nach contrib.
- falls das Modul nach FHEM kommt, dann bitte das betroffene Forum (wg.
  Support) und Developer (wg. allgemeine API-Aenderungen) abonnieren.
- vor dem Einchecken alles (auch Doku, mit contrib/commandref_join.pl &
  Browser) testen, und die letzten Aenderungen mit "svn diff FHEM/MyModul.pm"
  pruefen.
- neue Verzeichnisse duerfen nur nach Ruecksprache mit mir angelegt werden, das
  Gleiche gilt fuer das Einchecken von fremden Dateien wie Bibliotheken, usw.
========

Der letzte Punkt is reingekommen, weil ich CPAN nicht doppeln, oder Bibliotheken auf Lizenz pruefen will. Weiterhin ist fhemupdate.pl absichtlich starr, sprich man kann zwar ein Verzeichnis in SVN anlegen, aber das kriegen die Benutzer noch lange nicht per update.

Ich bin offen diesen Regel aufzuweichen, wenn dabei mein Bedenken beruecksichtigt wird.

absolut! Eventuell kommen ja auch noch Beiträge und Gedanken weiterer devs dazu.

Verstehe ich richtig:

- "fremd" bezieht sich auf Code "von anderen", hauptsächlich wegen möglicher Risiken mit Bezug auf die Lizenz. Aber auch um kein CPAN 2 aufzumachen.
- "eigene" Libs sind von den bestehen Regeln gedeckt wenn die im /FHEM Verzeichnis landen. (in /FHEM aber eben flat, keine sub dirs)

Über ein "nicht flat" (da geht's ja in die Richtung namespaces) könnte man reden, die Rules müssten festgelegt werden.

So richtig wiedergegeben ?

Zitat von: rudolfkoenig am 12 April 2020, 14:37:15
Wenn man ein Schreibzugriff aus SVN bekommt, kriegt man die:

Ok. Nichts darin verbietet, dass man zur Implementierung von Funktionalität X nicht mehr als 1 Modul verwenden darf.
Ich denke, damit wäre dieses "self-contained" erstmal abgehakt. Problematisch ist nur das kein Verzeichnis anlegen...

Ich habe da jetzt knapp zwei Stunden darüber sinniert und muss kleinlaut zugeben, dass mir eine richtig gute FHEM-kompatible Lösung nicht einfällt. Oder ich formuliere es mal um:

Wenn man sich HoBo anschaut, dann sieht man schon was ich mir als Ideale Lösung vorstelle:

Im root -Verzeichnis sind zwei Verzeichnisse lib und t dazugekommen. Ersteres soll Perl Module nach der regulären Nomenklatur (X::Y::Z = X/Y/Z.pm) enthalten, letzteres die zugehörigen Testfiles. Diese Vorgehensweise würde ich auch bei FHEM sehr stark ans Herz legen.

In lib tatsächlich nur Perl Module und nur nach o.g. Nomenklatur. Kein JavaScript, XML, .GZ und sonstiges Gedöns. (sowas gehört nach shared, data, resources oder so)

FHEM/lib werde ich entsprechend knicken, sobald ich die Gelegenheit dazu bekomme.

Mein Ziel ist, dass es mit der Zeit im FHEM Unterverzeichnis nur noch xx_Modulname.pm  main::-Interfaces (Hülsen sozusagen) gibt, die eigentlich nur ein use FHEM::MeinModul::Funktion qw(MeinModul_Init MeinModul_Define ...) machen, die Hauptlogik lebt aber unter lib/* und wird getestet von t/*

---

Tja ... aber das kann man alles machen, wenn man ne Installationsbasis von < 10 Diehards hat.  8)

Ich habe es mir auch noch einfacher gemacht und contrib erstmal gekillt. Folglich keine Ahnung wie man contrib vs. non-contrib handhaben könnte. Vermutlich müsste man ./lib & ./t nur für Modulautoren die ein FHEM/xx_Frontend.pm haben freigeben und für contrib Code sperren, womit man aber ggf. Contrib torpediert. Ist ein wenig Zweiklassengesellschaft, wofür ich keine guten Konzepte habe. Ich kann das nicht einmal mit staging/production abbilden.

Module unter ./lib anlegen würde ich nicht von "nach Rücksprache mit Nadelöhr" abhängig machen, sondern von "gemäß Nomenklatur/Hierarchie und announcement in <FHEM Forum/Development/Namespace>", aber der Modulautor macht einfach. Ähnlich wie PAUSE bei CPAN.

---

Auf jeden Fall, sollte das Ziel sein, dass ein Modulautor, der heute - Beispiel aus der Rippe geschnitten -

70_ONKYO_AVR.pm
71_ONKYO_AVR_ZONE.pm
ONKYOdb.pm

maintained, künftig folgendes nicht nur machen darf, sondern als "best practice" präsentiert bekommt:

* es gibt ein 70_ONKYO_AVR.pm modul, das ist aber nur ein <10-20 Zeilen Skelett

package main;

use Multimedia::AVR::ONKYO  qw(Init Define ...);

<ggf notify defs>

1;

* unter lib gibt es dann

lib/Multimedia/AVR/ONKYO.pm
lib/Multimedia/AVR/ONKYO/Zone.pm
lib/Multimedia/AVR/ONKYO/Db.pm

welche die eigentliche Codelogik in gekapselten Namespaces bereitstellen.  Ob man dann 71_ONKYO_AVR_ZONE.pm knickt oder nicht sei dahingestellt.

---

Gemäß FHEM Kulturgepflogenheiten ist das alles aber kein Muss. Wenn ein Autor/Maintainer alles im xx_Modulname.pm im main:: Namespace belassen will, belässt er es einfach dabei. Aber wer sein Modul auf ein höheres Level hieven will, kann das dann ja machen.

Beide Arten von Modulen können nebeneinander koexistieren. Mit der Zeit kommt vermutlich Darwin zu Wort.

---

Sprung in die ferne Zukunft, der Mars ist besiedelt, FHEM bei Version 97.1

Die Enkel des ONKYO Maintainers haben das nun auch gemacht, ebenso haben das die Enkel der YAMAHA_AVR und PONEER_AVR Modulmaintainer gemacht.
Nun kommen die Enkel von RichardCZ und behaupten man könne alles viel besser machen und knicken den verbleibenden Rest von xx_Frontend Modulen, bauen stattdessen ein dynamisches Laden von Modulen mit rekursivem Absiteg in die ./lib/* Hierarchie und machen z.B. ein abstraktes Modul

Multimedia/AVR.pm

was der werte User von FHEM 97.1 als AVR Device definiert und es ist ihm komplett wurst welches Gerät von welchem AVR Hersteller er hat.

ZitatSo richtig wiedergegeben ?

Ja.

Ich haette gerne eine Loesung, was die Regeln per Code sicherstellt, ich will nicht taeglich schauen, dass jemand alles was fuer DateTime::Event::Sunrise benoetigt wird, eingecheckt hat und ausliefert.
Einchecken alleine ist nicht so schlimm: wenn es nicht ausgeliefert wurde, kann man es leicht entfernen.
Update kann keine Dateien (mehr) loeschen, nur verschieben, und selbst dabei habe ich ein schlechtes Bauchgefuehl.

Zitat von: rudolfkoenig am 12 April 2020, 17:08:18
Ja.

Ich haette gerne eine Loesung, was die Regeln per Code sicherstellt, ich will nicht taeglich schauen, dass jemand alles was fuer DateTime::Event::Sunrise benoetigt wird, eingecheckt hat und ausliefert.

Ich hätte im Angebot:

* geradezu faschistische SVN pre-commit, post-commit und pre-vomit  ;) hooks. Aber ich bezweifle, dass die FHEM kulturkompatibel sind
* Die Möglichkeit für CI/CD Pipelines - https://gl.petatech.eu/root/HomeBot/pipelines (selber für HoBo noch nicht eingerichtet, aber das Werkzeug ist da)
https://docs.gitlab.com/ee/ci/introduction/

Sollte FHEM e.V. doch noch über eine self-hosted GitLab Infrastruktur nachdenken: https://www.turnkeylinux.org/gitlab
Läuft bei mir unter Proxmox, war in 30 Minuten eingerichtet. Updates seit Version 11 problemstlos.

Jaja - ich weiß - gestern erst noch von CVS auf SVN migriert und jetzt wieder so neumodisches Zeug.  ;)

Um auf das DateTime::Event::Sunrise zurückzukommen:

da gibt es natürlich ein

t/DateTime/Event/Sunrise/00_smoke.t

Das kann ein einfaches use auf das Modul machen.
und wenn das in so einer CI pipeline auf die Schnauze fliegt, kann man ja dem Modulautor um 2 Uhr früh via SMS Bescheid geben.

Zitat
Update kann keine Dateien (mehr) loeschen, nur verschieben, und selbst dabei habe ich ein schlechtes Bauchgefuehl.

Tja. Rollback is king. Statt:

my $destdir="/var/www/html/fhem.de";

eben

my $destdir="/var/www/html/fhem.de/active";

und unter /var/www/html/fhem.de sieht es eben aus wie

active -> 6.0
6.0
6.1
6.2

wenn einer putt ist, schaltet man zurück.

Ich brauche mal kurz einen Anstoß.
Wie kann man das PMD-CPD Analysetool aufrufen ?

Ein paar Stellen in meinen Modulen die ich diesbezüglich schon einige Zeit verbessern will kenne ich auch ohne das Ding,
aber nicht alle.

Grüße,
Heiko

Zitat von: DS_Starter am 16 Mai 2020, 18:17:42
Ich brauche mal kurz einen Anstoß.
Wie kann man das PMD-CPD Analysetool aufrufen ?

Ein paar Stellen in meinen Modulen die ich diesbezüglich schon einige Zeit verbessern will kenne ich auch ohne das Ding,
aber nicht alle.

z.B.

/usr/bin/pmd-cpd --minimum-tokens 100 --files FHEM/ --language perl


im FHEM root-Verzeichnis. Dann geht er rekursiv alle "Module" in FHEM durch.

Danke für die Info Richard.