Anfrage Erweiterung der Verzeichnisstruktur

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

Vorheriges Thema - Nächstes Thema

Christoph Morrison

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

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 gemacht und dann diskutiert. Solche Regeln entstehen doch gerade erst in der Diskussion.


RichardCZ

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

RichardCZ

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.

Stimmt - bis auf $modpath.
Statt $modpath nimmst Du $projectroot
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Christoph Morrison

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.

CoolTux

@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?
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: 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?

CoolTux

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

RichardCZ

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

rudolfkoenig

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.

RichardCZ

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

rudolfkoenig

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.


CoolTux

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

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

StefanStrobel

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