Requirements von Logiken und Userfunctions installieren beim Start?

[bmxp]

Ab und zu gibt es Bibliotheken, die in Logiken oder Userfunctions genutzt werden. Diese Abhängigkeiten werden derzeit nicht berücksichtigt bei der Installation von Abhängigkeiten beim Systemstart. Vielleicht könnte man das auf irgendeine Art berücksichtigen?

[msinn]

Meinst Du eine Lösung wie:

• Auf dem Parameter Tab ein Feld für die Requirements hinzufügen
• beim Start von shng Die Logik Paremeter auf die Requirements hin durchsehen und
• die Requirements der requirements/conf_all.txt und der requirements/all.txt hinzufügen bevor die Requirements geprüft werden ?

[Morg42]

Wenn das auf dem Parameter-Tab eingetragen werden kann, müsste es ja irgendwo gesichert werden - im Header der Logics- bzw. userfunctions-Datei?

In dem Fall wäre das ein Wechsel der bisherigen Konvention, Metadaten in gesonderten Dateien zu speichern. Möglich wäre ggf.

# requirements: foo im Header der Python-Datei (z.B.: ununterbrochener Kommentarblock von Dateibeginn an)

Eine zusätzliche yaml-Datei wäre möglich, müsste aber von Hand gepflegt werden und gilt dann jeweils für alle Logiken bzw. UF, da scheint mir Variante 1 besser handlebar.

[msinn]

Wenn das auf dem Parameter-Tab eingetragen werden kann, müsste es ja irgendwo gesichert werden - im Header der Logics- bzw. userfunctions-Datei?

Ich wäre für weder-noch. Meiner Meinung nach, würde die Information in die etc/logic.yaml gehören.

Einen direkten Zusammenhang mit den Userfunctions sehe ich erstmal nicht. Logiken können ja einfach ein import Statement enthalten.

Bei den Userfunctions Requirements zu hinterlegen ist noch mal ein weiteres Thema. Da muss ich noch mal drauf rumdenken. Eine Datei unter etc (analog zur etc/logic.yaml) könnte für Userfunctions auch noch ein anderes Problem lösen, das ich habe: Wenn ich eine Userfunctions Datei disablen möchte, muss ich bisher die .py Datei umbenennen (andere Endung dran). Es gibt bisher dafür keinen "Schalter".

[msinn]

Nei den Userfunctions könnte man das auch analog zu Plugins, dem lib Verzeichnis, … lösen.

In das functions Verzeichnis könnte man eine requirements.txt legen und shpypi könnte diese Datei mit in den Aufbau der Gesamt-Requirements aufnehmen.

[msinn]

Ich habe lib.shpypi erstmal so erweitert, dass in den Verzeichnissen ../logics und ../functions gespeicherte requirements.txt Dateien mit ausgewertet werden. In den generierten Dateien werden die Einträge als **user-defined'' gelistet. In der requirements/conf-all.txt sieht das z.B. dann so aus:

# configured plugin 'piratewthr'
# configured plugin 'darksky'
# configured plugin 'avm'
# configured plugin 'enigma2'
# SmartHomeNG-lib
# user-defined 'functions'
# user-defined 'logics'
requests>=2.20.0

Das ist noch nicht die eleganteste Version (da Logiken ja häufig in der Admin GUI geschrieben/modifiziert werden und man für die Requirements noch in den Maschinenraum muss, aber es ist erstmal eine praktikable Lösung.

Die requirements.txt Dateien werden im Konfigurations-Backup mit gesichert.

[CannonRS]

Macht es nicht Sinn die requirements direkt in die User-Funktion oder Logik auszulagern. Also irgendwie als Kommentar oder in einer Variable im Code? Also so z.B.:

requirements: pymodbus>='3.5.2'

oder requirements = 'pymodbus>=3.5.2'

VIelleicht denke ich da zu naiv. Aber wäre die Auswertung aufwändig?

[Morg42]

Ich glaube, die meisten Ideen, die nicht auf einer requirements.txt basieren, dürften einfach daran scheitern, dass die requirements bei Laden von shng geprüft werden, die Logiken aber erst beim Starten geladen werden. Die notwendigen Informationen (nicht zuletzt die notwendigen/konfigurierten Verzeichnisse) stehen zu dem Zeitpunkt noch gar nicht zur Verfügung.

Ich halte es da für praktikabler, eine logics/requirements.txt (und analog) zu lesen, und wenn im Admin-UI die Logiken bearbeitet werden, könnte man die ggf. dort auf eine solche Zeile hin parsen, die dann an die requirements.txt angefügt wird. Das scheint mir aber noch ein langer Weg zu sein; und persönlich halte ich das nicht für dringlich über die schon vorhandene Implementation der requirements.txt hinaus.