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

Offline Christoph Morrison

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

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

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

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

« Letzte Änderung: 16 Mai 2020, 14:41:00 von Christoph Morrison »
Maintainer von:
holidays · 59_Twilight · contrib/sacha_gloor · Buienradar

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #61 am: 16 Mai 2020, 14:38:07 »
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.  ;)
« Letzte Änderung: 16 Mai 2020, 14:41:24 von RichardCZ »

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #62 am: 16 Mai 2020, 14:44:48 »
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

Offline Christoph Morrison

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

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25323
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #64 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?
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 Christoph Morrison

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

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25323
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #66 am: 16 Mai 2020, 15:31:01 »
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?

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

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1127
  • Maintainer von 12 Modulen + holiday-Files
    • Private Website
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #67 am: 16 Mai 2020, 15:32:24 »
Also brauchen wir eine andere Idee.

Darüber diskutieren wir doch gerade. Ich glaube, dass Rudi Richard nur falsch verstanden hat.
Maintainer von:
holidays · 59_Twilight · contrib/sacha_gloor · Buienradar
Informativ Informativ x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #68 am: 16 Mai 2020, 16:12:15 »
@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.

Offline rudolfkoenig

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

Verstehe ich also richtig: lib/FHEM ist OK, und in t/FHEM gibt es "Gedraenge"?

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

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 558
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #70 am: 16 Mai 2020, 17:08:42 »
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.

Zitat
Verstehe 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.  ;)

Offline rudolfkoenig

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

Gefällt mir Gefällt mir x 2 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25323
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #72 am: 21 Mai 2020, 13:40:30 »
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://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net
Gefällt mir Gefällt mir x 1 Zustimmung Zustimmung x 1 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25323
Antw:Anfrage Erweiterung der Verzeichnisstruktur
« Antwort #73 am: Heute um 18:15:12 »
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://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

 

decade-submarginal