Verzeichnisstruktur - zusätzliche Dateien für Modul unter "www"

Begonnen von Adimarantis, 13 September 2021, 14:59:55

Vorheriges Thema - Nächstes Thema

Adimarantis

thirdparty wird eben nicht verteilt (an dem Verzeichnis war ich mit Schuld :) )
Aber wenn lib verteilt wird (zumindest habe ich da drin Dateien neueren Datums) - warum nicht?
Bisher sind da nur .pm files drin. Gibt es da eine Verzeichnis-Konvention?
Schaut ein wenig nach "lib/FHEM" gefolgt von einem Modulnamen bzw. Oberbegriff aus

Wäre das dann lib/FHEM/Messenger?
oder eher doch lib/FHEM/Scripts?
oder sogar lib/Scripts da eben eigentlich kein FHEM Bestandteil?

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Falls Admins mitlesen, erstmal eine Bitte:
Könnt ihr den Signalbot Thread https://forum.fhem.de/index.php/topic,118370.0.html
von "Codeschnipsel" nach "Unterstützende Dienste" verschieben?
Ich wollte das Modul demnächst offiziell einchecken und Codeschnipsel ist wirklich nicht mehr passend - die Historie im Thread aber denke ich ist schon interessant.

Nachdem das mit den zusätzlichen Dateien hier jetzt nicht abschliessend behandelt wurde, habe ich mich für einen anderen Ansatz entschieden:
Die Dateien sind jetzt unter contrib/signal
Dort werden sie über https://svn.fhem.de/fhem/trunk/fhem/ referenziert bzw. nachgeladen.
Ein www/signal wird vom Modul lokal angelegt und verwendet.

Dadurch entsteht zwar eine Abhängigkeit zum SVN Server, aber ohne Internet funktioniert Signal sowieso nicht und die Dateien werden nur anfangs beim Einrichtungsprozess benötigt.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

rudolfkoenig

ZitatKönnt ihr den Signalbot Thread https://forum.fhem.de/index.php/topic,118370.0.html
von "Codeschnipsel" nach "Unterstützende Dienste" verschieben?
Erledigt.

Christoph Morrison


rudolfkoenig

Wenn wir mit bin anfangen, dann muessen wir OS und/oder CPU-Architektur beruecksichtigen, z.Bsp. ueber Unterverzeichnisse.
Ich will ungern damit anfangen, und empfehle stattdessen perl :)

Christoph Morrison

Zitat von: rudolfkoenig am 22 September 2021, 12:19:25
Wenn wir mit bin anfangen, dann muessen wir OS und/oder CPU-Architektur beruecksichtigen, z.Bsp. ueber Unterverzeichnisse.

Ja gut, ist ein Punkt.

Zitat von: rudolfkoenig am 22 September 2021, 12:19:25
Ich will ungern damit anfangen, und empfehle stattdessen perl :)

Das ja auch nicht völlig Plattform-/Archtitektur-unabhängig ist.

Der TE hat ja gefragt ob er seine Skripte in lib/ packen soll. Im CPAN ist es so, dass (Perl-)Executables in einem bin-Verzeichnis des Moduls liegen, z.B. hier von Perl::Critic (https://fastapi.metacpan.org/source/PETDANCE/Perl-Critic-1.140/bin/). Das finde ich eigentlich als Ort auch charmant.

lib/FHEM/Messenger/Signal/bin ist z.B. ein guter Ort für sowas, finde ich.


rudolfkoenig

ZitatDas ja auch nicht völlig Plattform-/Archtitektur-unabhängig ist.
Ich meine doch, man muss "nur" die Platform-abhaengigen Probleme im Code loesen, soweit das ueberhaupt sinnvoll moeglich ist.

Zitatlib/FHEM/Messenger/Signal/bin ist z.B. ein guter Ort für sowas, finde ich.
Die Haken dabei:
- wenn das per update verteilt werden soll, dann muss ich alle Verzeichnisse manuell in contrib/fhemupdate.pl einbauen, und ausrollen.
- ich bin nicht sicher, ob ich auf einem Linux-Rechner Windows-Binaries haben will, und andersherum => Architektur abhaengiges update noetig?

Ich habe kein Problem damit, wenn sowas einfach gemacht wird, eher damit, wenn das offiziell abgesegnet werden soll, weil ich dann alle weiteren Moeglichkeiten beruecksichtigen muss.

Christoph Morrison

Zitat von: rudolfkoenig am 22 September 2021, 13:39:22
Ich meine doch, man muss "nur" die Platform-abhaengigen Probleme im Code loesen, soweit das ueberhaupt sinnvoll moeglich ist.

Nur ist wirklich gut ;-)

Zitat von: rudolfkoenig am 22 September 2021, 13:39:22
Die Haken dabei:
- wenn das per update verteilt werden soll, dann muss ich alle Verzeichnisse manuell in contrib/fhemupdate.pl einbauen, und ausrollen.

Ich dachte $FHEMDIR/lib wird sowieso mitverteilt? Unter $FHEMDIR/FHEM/lib würde ich sowas eh nicht sehen.

Zitat von: rudolfkoenig am 22 September 2021, 13:39:22
- ich bin nicht sicher, ob ich auf einem Linux-Rechner Windows-Binaries haben will, und andersherum => Architektur abhaengiges update noetig?

Ist die Verteilung von Binaries nicht eh ein Problem im Lizenzkontext? Da müsste ja auch immer der Quellcode mitgeliefert werden, oder? An sich hätte ich eher weniger Sorge, Windows-Gedöns auf meinem Linux zu haben. Läuft dort vermutlich sicherer als auf Win ;-)

betateilchen

#23
Hey Kollegen - gehts noch?

Da werden plötzlich 4 * 23 MB als Debian-Pakete in die FHEM svn Struktur eingepackt, die 99% aller Anwender nicht brauchen und die nur unnötigen Traffic verursachen.
Wenn das wirklich ernst gemeint ist und so bleiben soll, werde ich den Betrieb von debian.fhem.de wahrscheinlich in den nächsten Tagen einstellen.

Kann man sich nicht im Vorfeld erstmal ein paar Gedanken machen, welche Auswirkungen an welcher Stelle solche Ideen haben, bevor man sowas einfach eincheckt?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Adimarantis

Sorry, an den Traffik, den das erzeugt, wenn es jeder auscheckt habe ich nicht gedacht.
Gelöscht. Ich finde einen anderen Platz.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)