PATCH 98_update.pm

[Sidey]

Hi Rudi,

ich habe einen Patch für den Update Befehl entwickelt und ein neues Kommando damit realisiert.

Derzeit ist es ja so, das man alle Dateien die über eine controls Datei aktualisiert haben will unter dem gleichen Pfad erreichen muss, die zu aktualisierenden Dateien relativ zur controls Datei geladen werden.

Das Kommando habe ich "REM" für Remote abgekürzt und folgend kann eine weitere contols Datei angegeben werden, welche anschließend auch geladen wird.

Damit es es möglich, über eine controls Datei weitere 3rd Party Lokationen mit einzubeziehen.
Z.B. wenn jemand Abhängigkeiten hat oder seine Daten in eine andere Lokation migriert.


Grüße Sidey

[rudolfkoenig]

Ich bin (noch?) nicht fuer den Einbau dieser Patch:
- der Benutzer holt damit Dateien von einer ihm zunaechst unbekannten Seite.
- das Feature verstaerkt die Tendenz der dezentralen Modulentwicklung, was sowohl fuer mich, wie auch fuer den Benutzer ein Problem ist: ich kann nicht pruefen, wer welche Framework-Funktionen verwendet, und der Benutzer muss manuell an seiner controls_fhem.txt basteln.

[Sidey]

- der Benutzer holt damit Dateien von einer ihm zunaechst unbekannten Seite.

Stimmt, für den Anwender wird es ohne Beteiligung übernommen.
Ohne den Patch muss er manuell die Quellen hinterlegen und vom Entwickler geeignet informiert werden.

- das Feature verstaerkt die Tendenz der dezentralen Modulentwicklung, was sowohl fuer mich, wie auch fuer den Benutzer ein Problem ist:

Was ist daran genau das Problem des Benutzers?
Die Alternative für meinen Anwendungsfall wäre, dass ich alle Dateien an einen Ablageort zusammen kopieren um über einen Updatebefehl alles zu erschlagen.
Ansonsten gibt's auch häufig angepasste Versionen im Forum. Das lässt sich meiner Meinung nach noch schlechter im Griff behalten.

Die Menge an Repositorys im GIT belegt meiner Ansicht nach auch, dass für die Entwicklung einzelne Repos einen Mehrwert bringen.

ich kann nicht pruefen, wer welche Framework-Funktionen verwendet, und der Benutzer muss manuell an seiner controls_fhem.txt basteln.

Ich verstehe deine Bedenken so, dass das Risiko besteht, dass Module dann nicht mehr ins SVN kommen?

Das Risiko existiert prinzipiell ja auch heute schon, allerdings ist das meiner Meinung nach eher gering.
Wer sein Modul anbieten möchte, der packt es schon alleine deshalb ins SVN, damit es auch in den Installations Paketen enthalten ist und in der Commandref.

Mein Fall dreht sich darum, dass ich erst einmal was entwickeln möchte, das aber nicht ins SVN packe, da ich mit der Entwicklung nicht fertig bin.
Aktuell sind dadurch um die 10 Module in einem Repository gelandet, damit die Test Anwender mit nur einem Befehl alles updaten können.
Das führt nur leider zu längeren Wartezeiten bis auch mal wieder was ins SVN kommt.

Wenn man die Quellen über https einbindet, dann weiss man zumindest als Entwickler, dass die Daten von der richtigen Quelle geladen wurden.


Was der Anwender an seiner Controls Datei basteln muss habe ich nicht verstanden.
So war der Patch jedenfalls nicht gedacht.


Grüße Sidey



Gesendet von meinem Moto Z (2) mit Tapatalk

[rudolfkoenig]

Ich verstehe deine Bedenken so, dass das Risiko besteht, dass Module dann nicht mehr ins SVN kommen?

Nein, mein Bedenken ist, dass wenn ich eine Framework Funktion aendere, und vorher pruefe, wer/wie die Funktion verwendet, ich Module, die nicht in SVN sind, uebersehe.

[HomeAuto_User]

Hallo,
an einer Lösung wäre ich ja auch interssiert um das von @Sidey79 genannte auch nutzen zu können und es auch den Entwicklern ein wenig Erleichterung bringt.

@Rudi, welche Möglichkeiten siehst du denn, um das von Sidey genannte ggf umzusetzen?

Schöne Weihnachtszeit

[rudolfkoenig]

Koennt Ihr mir bitte das Problem konkret benennen?

[Sidey]

Das Problem ist, dass man alle Dateien, die mit einem Update Befehl aktualisiert werden sollen, in dem gleichen Pfad/ URL ablegen muss.

Das führt dazu, dass man sich alles in einer Fhem kompatiblen Ablagestruktur zusammen bauen muss, damit es mit einem Update Befehl funktioniert oder man es halt direkt so ablegt.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

[rudolfkoenig]

Und warum ist das ein Problem?

[Sidey]

Hi Rudi,

Das Problem ist, weil es dazu führt, dass Workarounds angewendet werden.

z.B. In dem Code der aufeinander Aufbaut / Abhängig ist entweder

a) in einem gemeinsamen Repository entwickelt wird
- Verzögert die Veröffentlichung von Entwicklungen

b) oder umständlich das ganze vor Auslieferung an einen Anwender zusammengepackt werden muss

- Changelog zusammenfügen ist Handarbeit
- Lizenzen beachten, nicht alle sind kompatibel
- Fehleranfällig

c) Einzeldateien im Forum oder über andere Wege bereitgestellt werden
- Umständlich und aufgeräumt wird da ja auch nie



Grüße Sidey

[rudolfkoenig]

Ich frage mich, warum staendig um den heissen Brei herumgeredet wird, und das Problem nicht konkret genannt wird.

[curt]

Auch ich (ok, ich bin nicht wichtig) habe das Problem nicht ansatzweise verstanden.

Auf den ersten Blick klingt die wolkige Beschreibung wie ein schönes Einfallstor für Viren, Trojaner und Malware.

Einerseits mag man denken, dass FHEM als Angriffsziel viel zu klein sei. Andererseits will ich bei niemandem gucken kommen: Wir alle haben sackweise Devices, die nicht auf dem neuesten Patchlevel sind, mal ganz abgesehen davon, dass die Devices (also die Hardware am Fenster usw.) selbst typischerweise grottenschlecht sind. Alternative Update-Wege für Module ist aus diesem Blickwinkel im Grunde das Letzte, was man brauchen könnte.

Ja, ich vermische damit die Ebenen. Ich weiß.

(Ein konkret erlebtes Beispiel [Thermostat sendet Mails] löschte ich, das führt zu weit.)

[Sidey]

Ich frage mich, warum staendig um den heissen Brei herumgeredet wird, und das Problem nicht konkret genannt wird.

Ich habe drei Gründe genannt a) b) und c).
Mit detailierteren Rückfragen wäre es für mich leichter, eine Antwort zu schreiben.
Hauptgrund den Patch zu schreiben war Fall a): Mit einem Logischen Modul die passende "Bibliotheken" eines Physischen Moduls mit ausliefern zu können, wenn diese von unterschiedlichen Personen gepflegt werden / in unterschiedlichen Repositorys liegen.

Wenn Du dafür einen andere Idee hast, dann her damit.

Auf den ersten Blick klingt die wolkige Beschreibung wie ein schönes Einfallstor für Viren, Trojaner und Malware.

Pauschal sehe ich da derzeit kein zusätzliches Einfallstor. Mit update add ist es doch bereits möglich weitere Repositorys in FHEM zu hinterlegen.
Das Kommando kann auch von einem Modul ausgeführt werden.
Das ganze System mit open source funktioniert doch nur, weil wir einander vertrauen, dass niemand was "böses" einbaut und wenn doch, dass es dann jemand "findet".

Darüber hinaus gibt es noch etliche weitere Möglichkeiten code nachzuladen. Regelmäßig finden sich auch immer wieder Funktionen für eine 99_MyUtils, angepasste Modulversionen / Patches.

Ich wollte nur in einer controls Datei auf eine andere controls Datei verweisen können um nicht "Update" Befehle für den Anwender aus einem Modul auszuführen oder ihn Anzuweisen dass er mehrere dieser Updatebefehle benötigt um vorab einen Entwicklungsstand zu testen.

Ansonsten habe ich noch ein schickes Beispiel aus Anwendersicht:

FTUI wird auf github gehostet.
Das lässt sich leicht einbinden. Alles super.

Es gíbt Menschen, die erstellen anschauliche Vorlagen für FTUI.

Ich kann jetzt nur annahmen stellen, wieso letzteres als "komplettes" ZIP bereitgestellt wird, aber wenn ich mir jetzt eine Oberfläche entwickeln würde, dann würde es die Bereitstellung einer Oberfläche erleichtern, wenn ich diese in ein Repo mit controls Datei packe und dann FTUI in der kompatiblen Version verlinken kann.

Probleme mit zueinander nicht kompatiblen Lizenzen würden dadurch auch verringert. Teilweise sind Progamme ja mit GPL und andere mit MIT lizensiert. GGf. auch noch andere Varianten.


Grüße Sidey

[rudolfkoenig]

Ich habe drei Gründe genannt a) b) und c).

Wir haben offesichtlich ganz unterschiedliche Vorstellungen von konkret.

Wenn Du dafür einen andere Idee hast, dann her damit.

Der Entwickler des logischen Moduls beschreibt, was der Anwender in seine controls Datei eintragen soll.
Das muss er ja sowieso, und ob das eine Zeile oder zwei sind, ist es mAn egal.
Wenn es dem Entwickler wichtig ist, diesen Vorgang dem Endanwender zu ersparen, dann ueberzeugt er alle beteiligten Entwickler, die Module ins FHEM-SVN einzuchecken.

Mag sein, dass das zu naiv gedacht ist, vlt. liegt es daran, dass ich das Problem fuer die vorgeschlagene Loesung noch nicht kenne.

[Sidey]

Der Entwickler des logischen Moduls beschreibt, was der Anwender in seine controls Datei eintragen soll.
Das muss er ja sowieso, und ob das eine Zeile oder zwei sind, ist es mAn egal.

Das verstehe ich jetzt noch nicht. Was könnte der Anwender denn in der controls Datei eintragen und vor allem, wie macht er das?
Die Controls Datei liegt doch immer in einem Repository von dem aus der Update Befehl dann die darin hinterlegten "Befehle" ausführt.
Ich bin bislang immer davon ausgeganegen, die controls Datei wird in einem Repository bereitgestellt und der Anwender kann dort nichts sinnvolles anpassen.
Vielleicht hast Du ja ein Beispiel.

Wenn es dem Entwickler wichtig ist, diesen Vorgang dem Endanwender zu ersparen, dann ueberzeugt er alle beteiligten Entwickler, die Module ins FHEM-SVN einzuchecken.

Wie kann ich im SVN mehrere Versionsstände separat einchecken, so das dann nicht über das "normale" FHEM Update auch aktualisiert wird? Mehrere Branches existieren doch nicht oder doch?
Aktuell entwickele ich auf Github, da es einige Vorteile hat. Die Diskussion SVN oder GIT will ich aber an dieser Stelle nicht führen, da unerheblich für den Fall.

Ich möchte nicht, wenn eine neue Funktion noch in Entwicklung ist, das an jeden der ein normales Update ausführt auch verteilen.
Teilweise wäre das auch nicht möglich, wenn mehrere parallele Entwicklungsstänge bestehen.


Wenn Du mir eine Idee noch ein wenig weiter erläuterst fällt bei mir ja vielleicht noch der Groschen, wie ich das einsetzen könnte im meinen Fall zu lösen.

[OdfFhem]

Ich gebe zu, dass ich mangels eines konkreten Beispiels immer noch nicht ganz genau weiß, wofür man die vorgeschlagene Änderung brauchen könnte.

Aus meiner Sicht gibt es aber bereits mindestens 2 nutzbare Wege, die vielleicht zu Deinem Problem passen könnten:

• 
  Ich entwickle lokal mit einem temporären Zwischenstand; die dabei betroffenen Module nehme ich mittels exclude_from_update-Attribut vom Update aus und ich behalte den temporären Zwischenstand.
  
• 
  Ich entwickle auf GitHub mit einem temporären Zwischenstand; dort stelle ich ein eigenes update-Controlfile bereit. Einmalig muss dann dieses via "update add" der Repository-Verwaltung hinzugefügt werden. Da die Repositories der Reihe nach geladen werden, gewinnt am Ende immer das zuletzt hinzugefügte update-Controlfile.
  

Sollte keiner der geschilderten Wege zu einer Lösung beitragen, wäre es wahrscheinlich gut, einen echten (akut vorhandenen) Problemfall als Beispiel anzuführen ...