Meta.pm: Metadaten über FHEM Module

Begonnen von Loredo, 19 Februar 2019, 11:43:50

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Zitatderzeit gibt es z.B. keine dedizierte Datenschutzerklärung für FHEM als Software.
FHEM sammelt keine Daten im Auslieferungszustand, nur wenn man explizit "attr global sendStatistics" setzt.
Braucht man trotzdem eine Datenschutzerklaerung? Warum? Was muss drinstehen?

Loredo

Zitat von: rudolfkoenig am 10 März 2019, 16:15:51
FHEM sammelt keine Daten im Auslieferungszustand, nur wenn man explizit "attr global sendStatistics" setzt.
Braucht man trotzdem eine Datenschutzerklaerung? Warum? Was muss drinstehen?


Dann fällt die Erklärung wohl sehr kurz aus :-)
"Brauchen" - ich würde sagen ja, der Transparenz wegen. Ich vermute da genügen 3 Sätze, in denen erklärt wird, dass keinerlei Daten übermittelt werden.
Da wir das ganze pro Modul betrachten und Update schon ein eigenes Command-Modul ist, kann dort auch eine separate Datenschutzerklärung hinterlegt oder verlinkt werden. In der CommandRef ist zwar ein Hinweis, aber der ist nicht eindeutig unter dem Schlagwort Datenschutz/Privacy auffindbar. Auf der Modul-Infoseite vom Installer gäbe es dafür einen prominenten Platz. Du kannst die Daten auch selbst in 98_update.pm pflegen, indem du dort einen META.json Pod anlegst. Ich kann da gerne mal einen Vorschlag fabrizieren, den du übernehmen könntest.


Für fhem.pl pflege ich das gerade direkt in Meta.pm, aber auch dieser Pod könnte früher oder später nach fhem.pl, wenn gewünscht.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

#17
habe eben angefangen das ganze für das alexa modul mal einzubauen.

wenn ich alles richtig verstehe brauche ich eigentlich nur return FHEM::Meta::InitMod( __FILE__, $hash ); am ende von Initialize und einen solchen block:               
=for :application/json;q=META.json 39_alexa.pm
{               
  "abstract": "Module to control the FHEM/Alexa integration",
  "x_lang": {   
    "de": {     
      "abstract": "Modul zur Konfiguration der FHEM/Alexa Integration"
    }           
  },           
  "keywords": [
    "fhem-mod",
    "fhem-mod-device",
    "alexa",
    "alexa-fhem",
    "nodejs",   
    "node"   
  ],           
  "release_status": "stable",
  "x_fhem_maintainer": [
    "justme1968"   
  ],           
  "x_fhem_maintainer_github": [
    "justme-1968"
  ],           
  "x_prereqs_nodejs": {
    "runtime": {     
      "requires": {   
        "node": 8.0, 
        "alexa-fhem": 0     
      },             
      "recommends": {
      },             
      "suggests": {   
      }               
    }                 
  }
}
=end :application/json;q=META.json
im pos teil.

richtig?

das scheint so weit zu funktionieren.

was mir aber auffällt: die svn version wird dann zum patchlevel der version: v0.0.18863. schöner wäre einfach nur v18863. oder vielleicht noch besser etwas in der art: vSVN-18863.

was auch noch etwas unhandlich ist: abstract und summary enthalten eigentlich das gleiche. lässt sich vermeiden das zwei mal hin zu schreiben?

das Installer modul zeigt die nodejs info noch nicht an. ist das korrekt?

wie soll mit den indirekten node abhängigkeiten umgegangen werden? ich habe ja oben nur alexa-fhem aufgeführt. das ist die einzige direkte abhängigkeit. ich denke das ist so gedacht?



das discovery modul kommt... aber das dauert noch etwas :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

#18
Zitat von: justme1968 am 11 März 2019, 20:38:01
habe eben angefangen das ganze für das alexa modul mal einzubauen.

wenn ich alles richtig verstehe brauche ich eigentlich nur return FHEM::Meta::InitMod( __FILE__, $hash ); am ende von Initialize und einen solchen block [...] im pos teil.

richtig?


Ja, das ist der essentielle Teil.




Edit: Du kannst (und solltest) noch den Pod
  =encoding utf8
am Anfang hinzufügen, wenn du im Text entsprechende Zeichen verwendest. Ansonsten wird Latin1 verwendet (so wie es FHEM an der Stelle selbst sonst auch tut).



Wenn man das Modul schon als Perl Package erstellt hat, kann man in DefFn außerdem die Modulversion aus den Metadaten setzen:



use version 0.77; our $VERSION = FHEM::Meta::Get( $hash, 'version' ); # seems it must be a one-liner



Dann kann standardkonform per MODULNAME->VERSION() die Version abgefragt werden. Soweit ich weiß nutzen das einige Perl Module. Eigentlich sollte damit auch die Angabe der Versionsnummer bei einem "use MODULNAME 1.234567" möglich sein, aber das scheint wohl nicht zu klappen. Bisher ist mir nichts anderes eingefallen, ohne dass man die Versionsnummer doppelt pflegen muss.


Außerdem kann man in DefFn noch




    return $@ unless ( FHEM::Meta::SetInternals($hash) );



einfügen. Derzeit bewirkt das, dass FVERSION als Internal gesetzt und auch bei einem Modul Reload aktualisiert wird. Darin stehen dann die essentiellen Infos zu einem Modul in der Form:


<Dateiname>:<Version>[-s|gCOMMIT]/<Release Date>


Also z.B.
98_Installer.pm:v0.0.1-s18855/2019-03-11


So ähnlich hat Rudi das auch bereits für fhem.pl im global Attribut "version" verwendet.
Die ergänzende Notation der Version ist an den Output von 'git describe --tags --dirty' angelehnt. "-s" steht dabei für Subversion, "-g" würde für Git stehen.
Das ist ein Standard, der einem inzwischen häufig so begegnet (Git sei Dank). Er findet auch beim Docker Image Anwendung.


Zitat von: justme1968 am 11 März 2019, 20:38:01
was mir aber auffällt: die svn version wird dann zum patchlevel der version: v0.0.18863. schöner wäre einfach nur v18863. oder vielleicht noch besser etwas in der art: vSVN-18863.


Das verwendete Format ist hier spezifiziert:
https://metacpan.org/pod/CPAN::Meta::Spec#Version-Formats


Ich habe mich hier für die Dotted-integer Variante entschieden (also dem Semantic Versioning), weil es auch dem entspricht, was viele FHEM Modulentwickler intern in ihren Modulen bereits anwenden (und auch selbst in das Internal VERSION schreiben). Meta.pm extrahiert aus dem Sourcecode eine mögliche semantische Versionsnummer (Erfolgsquote geschätzt 99%). Die Art, wie die Version extrahiert wurde, ist in $modules{<TYPE>}{META}{x_file}[7] abrufbar.
Zur einfacheren Einsicht der Roh-Metainformationen habe ich gerade noch einen Getter zzGetMETA.json in den FHEM Installer eingebaut.

EDIT: Nachdem ich jetzt nochmal darüber nachgedacht habe, habe ich es jetzt hier wie folgt geändert:
Sofern der Modulautor keine semantische Version hinterlegt hat, wird eine Dezimalversion der Form 0.<COMMIT> generiert (also ohne "v" vorne und nur als Fließkommazahl). Der Modulautor kann entscheiden über META.json zusätzlich eine semantische Versionierung vorzunehmen, welche bei einem externen Repository zwingend erforderlich ist, da keine VCS Informationen aus $Id$ auslesbar sind. In diesem Fall wird die Version als "v1.2(.\d+)*" angelegt.
Die Dezimalversion als <COMMIT> oder <COMMIT>.0 darzustellen geht nicht, weil man ansonsten bei einem späteren Wechsel zur semantischen Versionierung nicht kompatibel sein kann (bzw. eine enorm hohe Major Version wie v18234.0.0 wählen müsste...).


Zitat von: justme1968 am 11 März 2019, 20:38:01
was auch noch etwas unhandlich ist: abstract und summary enthalten eigentlich das gleiche. lässt sich vermeiden das zwei mal hin zu schreiben?


Summary ist im META.json nicht enthalten, die oben verlinkte Spezifikation sieht das Datenfeld 'abstract' für die Zusammenfassung vor. 'abstract' wird aus dem =summary Pod gefüllt, wenn es nicht vorhanden ist. Man kann es aber natürlich auch separat pflegen und befüllen. Für FHEM 3rd-Party Module, die nicht im Subversion gehostet sind, ist vorgesehen, dass alle Metadaten über das META.json angegeben werden können. Ob das mal für alle FHEM Module möglich sein soll, lasse ich offen.
Der Grundsatz ist: Meta.pm extrahiert alle Infos und nimmt diese, die im META.json fehlen. Ansonsten haben die Daten aus META.json Priorität.
Es kann aber sinnvoll sein, dass diejenigen Datenfelder, die die CPAN::Meta::Spec als zwingend erforderlich vorsieht, trotzdem immer im META.json Pod mit anzugeben, denn dann wäre das File als solches vollständig und Standard konform und muss nicht erst über (ein laufendes) FHEM generiert werden.


Zitat von: justme1968 am 11 März 2019, 20:38:01
das Installer modul zeigt die nodejs info noch nicht an. ist das korrekt?


Du meinst die Prereqs? Ja, das ist richtig. Ich wollte mir die Arbeit erst machen, wenn ich nicht mehr der einzige bin, der daran arbeitet. Baue ich ein. Ich bin mir aber noch nicht sicher, wie ich die Brücke zum npmjs.pm Modul schlagen will, mal sehen.
Du kannst aber über den neuen Getter schon sehen, ob alles richtig drin ist.


Zitat von: justme1968 am 11 März 2019, 20:38:01
wie soll mit den indirekten node abhängigkeiten umgegangen werden? ich habe ja oben nur alexa-fhem aufgeführt. das ist die einzige direkte abhängigkeit. ich denke das ist so gedacht?


Ja, das ist so gedacht. Es bleibt dir als Modulautor überlassen die richtigen Abhängigkeiten zu nennen. Der Installer wird natürlich bei jeder auf das Vorhandensein prüfen und später auch die Installation je nach Importance vornehmen oder vorschlagen. Da der npm Paketmanager aber ja alles andere erledigt, brauchst du nur alexa-fhem angeben und managt alle Node Abhängigkeiten lieber in deinem eigenen npm Paket.


Zitat von: justme1968 am 11 März 2019, 20:38:01
das discovery modul kommt... aber das dauert noch etwas :)


Macht nichts, ich wollte dich nur etwas ermutigen  :)
Und natürlich wollte ich wissen, ob dein Anwendungsfall nun damit auch abgedeckt werden kann, oder ob noch etwas fehlt.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

so weit so gut. ich würde dann die nächste alexa modul version mit der meta info einchecken.


die änderung bei der version finde ich gut. aber ich glaube direkt die svn version zu verwenden geht schon :) :

- für 'normale' fhem module die im svn sind ist die svn version doch die einzig relevante. das so ein modul
  auf semver wechselt ist doch eher unwarscheinlich. d.h. es macht nichts wenn es zwei unterschiedliche systeme sind.

- ich möchte auf jeden fall vermeiden für die svn module noch mal eine zusätzlich version zu pflegen die von hand
  geändert werden muss. das wird früher oder später vergessen.


ich möchte ganz allgemein nur vermeiden irgend etwas an mehr als einer stelle einzugeben. das gibt früher oder später zweideutigkeiten.


ZitatDu kannst aber über den neuen Getter schon sehen, ob alles richtig drin ist.
das get hat bei meinem ersten versuch nur die perl abhängigkeiten angezeigt. node noch nicht. oder war das da noch nicht drin?


für das discovery modul sollte das bei den default protokollen mit  einem eigenen eintrag im json so gehen. für die custom protokolle bei denen ein oder zwei funktionen deklariert werden müssen vermutlich auch. teste ich noch.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

#20
Zitat von: justme1968 am 13 März 2019, 11:00:53
so weit so gut. ich würde dann die nächste alexa modul version mit der meta info einchecken.

Cool  8)

Zitat von: justme1968 am 13 März 2019, 11:00:53
die änderung bei der version finde ich gut. aber ich glaube direkt die svn version zu verwenden geht schon :) :

- für 'normale' fhem module die im svn sind ist die svn version doch die einzig relevante. das so ein modul
  auf semver wechselt ist doch eher unwarscheinlich. d.h. es macht nichts wenn es zwei unterschiedliche systeme sind.

- ich möchte auf jeden fall vermeiden für die svn module noch mal eine zusätzlich version zu pflegen die von hand
  geändert werden muss. das wird früher oder später vergessen.

So wie es jetzt gerade ist, muss man keine Version manuell pflegen - aber man KANN ("Alles kann, nichts muss...").
Man kann jederzeit wechseln, wenn man sich irgendwelche Vorteile davon verspricht - die Gründe für semver haben ja einige Modulautoren für sich schon bewertet und andere bleiben eben dabei, dass die Revision der Version entspricht. Einzig wird die Version eben als 0.XXXX repräsentiert, aber damit kann man denke ich dann leben - man muss ja nix selbst machen.

Zitat von: justme1968 am 13 März 2019, 11:00:53
ich möchte ganz allgemein nur vermeiden irgend etwas an mehr als einer stelle einzugeben. das gibt früher oder später zweideutigkeiten.

Wie gesagt, es ist alles optional, wenn man mit dem SVN arbeitet, nichts ändert sich, wenn man das nicht möchte.
Ich arbeite noch daran, dass man die in META.json/Prereq definierten Perl Abhängigkeiten auch direkt am Beginn des eigenen Moduls für den Import dieser Pakete verwenden kann, damit man dann auch hier nicht doppelt pflegen muss. Da würde sich dann nur der Ort ändern, wo man eben seine Perl Module inkludiert und gleichzeitig dokumentiert man da seine Abhängigkeiten. Aber auch hier: Wer das nicht will, für dessen Modul gibt es eben keine auswertbaren Abhängigkeiten und der User kann auf das automatische Analyseverfahren zurückgreifen. Was dann aber eben ungenau sein kann und auch natürlich Performance frisst - nicht unerheblich, wenn der Installer später einmal eine ganze fhem.cfg auswertet und prüft, was so alles fehlt. Da bleibt es dem Modulautor überlassen wie wichtig ihm die Performance an dieser Stelle ist (bzw. was er den Nutzern zumuten will).

Wäre dann wahrscheinlich auch für dein Discovery Modul relevant, weil du da ja wahrscheinlich dann auch alle Metadaten von allen Modulen vorladen möchtest, um anschließend zu schauen, welches Modul welches Protokoll unterstützt. Aber damit ein Modul die Discovery Funktion anbieten kann, muss der Modulautor ja dann ohnehin das META.json anlegen und die Hoffnung ist natürlich, dass man dann auch seine anderen Abhängigkeiten mit reinschreibt. Im Grunde ist das auch kein Hexenwerk, denn wenn man selbst nicht sicher ist, kann man auch einfach die Ausgabe von "get zzGetMETA.json" als Vorlage nehmen (abzüglich einiger Knoten darin, die eh überschrieben würden - z.B. x_file).

Zitat von: justme1968 am 13 März 2019, 11:00:53
das get hat bei meinem ersten versuch nur die perl abhängigkeiten angezeigt. node noch nicht. oder war das da noch nicht drin?

Es ist alles mit im META.json drin, was du selbst im Pod hinterlegt hast - also dann auch deine Node Abhängigkeiten. Ich werte diese aber in 98_Installer noch nicht aus.
Du musst außerdem bedenken, dass die Metadaten zur Laufzeit aus Performancegründen nur ein einziges Mal eingelesen werden. Wenn du also Änderungen an den Metadaten machst, dann werden diese erst in FHEM verfügbar, wenn du FHEM neu gestartet hast. Aktuell habe ich noch keinen Reload-Mechanismus in 98_Installer eingebaut, aber es ist in Meta.pm schon entsprechend vorgesehen (du kannst also auch aus deinem eigenen Modul heraus deine eigenen Metadaten jederzeit neu laden, wenn es einen Grund für dich gibt).

Zitat von: justme1968 am 13 März 2019, 11:00:53
für das discovery modul sollte das bei den default protokollen mit  einem eigenen eintrag im json so gehen. für die custom protokolle bei denen ein oder zwei funktionen deklariert werden müssen vermutlich auch. teste ich noch.

Ja, es ist ja nur ein weiterer Baum im META.json :-)
Namen kannst du da frei wählen, allerdings beachten, dass die Schreibweise immer klein ist und weil es nicht in CPAN::Meta::Spec spezifiziert ist, am obersten Baumende mit "x_" beginnen muss.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

#21
Hallo Julian,

habe deine Entwicklung gespannt verfolgt und bin auch daran gegangen mich ein bisschen in die Problematik Packages und Meta.pm/Installer.pm einzuarbeiten.
Tolle Sache und ich bin gespannt was noch dabei herauskommt.  :)

Ich habe mal klein angefangen und ein Modul aus meinem contrib auf Package-Verwendung umgestellt und fit für Meta.pm gemacht. Funktioniert auch alles soweit und Installer.pm bringt auch die erwarteten Informationen.

Zwei Fragen habe ich aber.

Das Internal FVERSION wird nicht gesetzt obwohl    "version": "v1.2.3",  im pod eingetragen ist.  .FhemMetaInternals ist "1". Kann es sein, dass FVERSION erst dann gesetzt wird wenn das Modul eingecheckt ist bzw. es in der MAINTAINER.txt steht ?
Habe deinen Code versucht zu verstehen und bin deswegen auf die MAINTAINER.txt gekommen. Kann mich aber auch absolut irren  ;) ... deswegen diese Frage.

Dann hast du vlt. zu folgendem eine Idee.
Ich verwende in meinen Modulen einen für mich hilfreichen Mechanismus zur Versionsverwaltung über einen Hash:


# Versions History intern
our %SMAPortal_vNotesIntern = (
  "1.3.0"  => "13.03.2019  change module to use package name SMA-Portal ",
  "1.2.3"  => "12.03.2019  make ready for 98_Installer.pm ",
  "1.2.2"  => "11.03.2019  new Errormessage analyze added, make ready for Meta.pm ",
.....


Über eine Funktion:

$hash->{VERSION} = (SMAPortal_sortVersion("desc",keys %SMAPortal_vNotesIntern))[0];

setze ich dann das Internal VERSION. Das hat für mich den Charme, dass ich immer weiß was ich mit einer internen Version geändert habe, auch wenn diese Version nicht eingecheckt wurde sondern erst die übernächste etc.
Jetzt suche ich eine Möglichkeit nicht doppelt pflegen zu müssen und diesen Wert aus %SMAPortal_vNotesIntern irgendwie Installer.pm zur Verfügung zu stellen. Vllt. durch Überschreiben von "x-version" im META-Hash.
Siehst du evtl. eine Möglichkeit ?

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

#22
Zitat von: DS_Starter am 13 März 2019, 22:37:30
Das Internal FVERSION wird nicht gesetzt obwohl    "version": "v1.2.3",  im pod eingetragen ist.  .FhemMetaInternals ist "1". Kann es sein, dass FVERSION erst dann gesetzt wird wenn das Modul eingecheckt ist bzw. es in der MAINTAINER.txt steht ?


Nein, FVERSION wird auch ohne MAINTAINER.txt gesetzt. Allerdings wird FVERSION aktuell nur auf zwei Arten gesetzt:


1. Durch den Installer, wenn er die Metadaten erzeugt. Bei Modulen, die in Verwendung sind, sofort, auch nach einem Neustart. Bei Modulen, die nicht in Verwendung sind, nur beim lesen der Metadaten.
2. Durch Aufruf von FHEM::Meta::SetInternals($hash) aus der DefFn, sprich auf expliziten Wunsch des Modulautors. Dabei wird auch das Internal .FhemMetaInternals=1 gesetzt. Es sorgt dafür, dass bei einem Reload des Moduls, bei dem fhem.pl ja dann X_Initialize() wieder aufruft und bei dem du dann ja FHEM::Meta::InitMod() aufrufst, dann auch FVERSION für alle Geräte entsprechend aktualisiert wird. Wenn du also selbstständig einfach nur .FhemMetaInternals=1 setzt, dann müsstest du anschließend auch deine Moduldatei neu laden. Macht aber nicht so viel Sinn, oder :-)
Meta.pm handhabt das für dich transparent. Für Module, die tatsächlich ein eigenständiges Package sind und die in ihrem eigenen Namespace auch ein "use FHEM::Meta" machen (zusätzlich zum "use FHEM::Meta" im main Context), könnte ich natürlich auch implizit für den Modulautor FHEM::Meta::SetInternals() aufrufen. Ich war mir aber a) nicht sicher, ob FVERSION dann gewollt ist und b) sind viele Module ja keine eigenen Packages bisher. Wenn der Benutzer den Installer benutzt, gehe ich einfach davon aus, dass er dann diese Funktion so will. Aber man kann Meta.pm natürlich auch ohne den Installer verwenden und da bleibt es aktuell dem Modulautor überlassen, was er damit anfängt:

1. Er könnte nur die META.json Daten hinterlegen. Die sind dann bei Bedarf auslesbar, sind aber nicht automatisch im Speicher (es sei denn der User verwendet den Installer).
2. Er könnte zusätzlich auch "use FHEM::Meta" ausführen und in X_Initialize() "return FHEM::Meta::InitMod( __FILE__, $modHash );" aufrufen, um beim laden des eigenen Moduls auch die Metadaten mit in den %modules Hash zu laden.
3. Er könnte zusätzlich entscheiden, dass FVERSION auch im Device Hash angezeigt werden soll, indem er in der DefFn FHEM::Meta::SetInternals($hash) aufruft.
4. Er könnte zusätzlich entscheiden, dass er im Falle eines echten Perl Packages auch "our $VERSION" setzt: "use version 0.77; our $VERSION = FHEM::Meta::Get( $hash, 'version' );", damit dann auch __PACKAGE__->VERSION() als Funktionsaufruf für sein Modul funktioniert.

Die FHEM Module npmjs.pm und Installer.pm machen das beide schon so, das FHEM Package Meta.pm (als Device-loses Modul sozusagen) macht es ebenfalls für sich selbst.

Zitat von: DS_Starter am 13 März 2019, 22:37:30
Ich verwende in meinen Modulen einen für mich hilfreichen Mechanismus zur Versionsverwaltung über einen Hash:


# Versions History intern
our %SMAPortal_vNotesIntern = (
  "1.3.0"  => "13.03.2019  change module to use package name SMA-Portal ",
  "1.2.3"  => "12.03.2019  make ready for 98_Installer.pm ",
  "1.2.2"  => "11.03.2019  new Errormessage analyze added, make ready for Meta.pm ",
.....


Über eine Funktion:

$hash->{VERSION} = (SMAPortal_sortVersion("desc",keys %SMAPortal_vNotesIntern))[0];

setze ich dann das Internal VERSION.


Wenn du FVERSION setzt, brauchst du VERSION nicht mehr selbst zu setzen, sofern du die Version dann über das META.json bereitstellst.


Es ist weiterhin angedacht, dass im META.json auch eine Änderungshistorie analog zu HISTORY und CHANGED hinterlegt werden kann. Das soll vor allem auch dazu verleiten, dass Modulautoren von er Unsitte abkommen, ihre Änderungen in irgendeiner Freitextform als Kommentarzeilen am Anfang der Datei zu pflegen ;-)
Dort gibt es einige Nasen, die z.B. die Historie chronologisch von oben nach unten geschrieben und dabei auch eine Versionsnummer angegeben haben, weshalb ich dann aber beim versuch diese auszulesen immer auf die allererste Version statt der letzten Version stoße (einige andere haben es hingegen besser gemacht und schreiben die neuste Änderung zuerst hin - immerhin).


Die genaue Notation muss ich mir noch überlegen, aber es wird ähnlich sein wie du dir deinen Hash auch gebaut hast, sprich einen unmittelbaren Bezug zu einer bestimmten Versionsnummer und evtl. ein Datum, etc. Klar ist dann aber auch, dass diese Daten dann tatsächlich eine Momentaufnahme darstellen und somit danach unveränderbar sein sollen. Soll heißen, die Versionsnummer wird im Attribut "version" weiter hochgezählt, aber im History Zweig muss die Version zusätzlich gepflegt werden, damit sie als Historie erhalten bleiben kann.
Das hat auch damit zu tun, dass die CPAN::Meta::Spec keine Vermischung zwischen eigentlicher Versionskontrolle und der Historie bzw. Dokumentation von Änderungen vorsieht. Ich würde diese auch nicht mischen wollen, denn wie auch bei FHEM's HISTORY oder CHANGE gibt es nicht immer einen Grund auch eine Änderung zu dokumentieren.


Ich denke also, dass dies deine Anforderung dann wird abdecken können. Im META.json hinterlegt ist es auch schnell, wenn man sich auf ein Datenformat verständigt hat. Die Anzeige im Installer ist dann noch eine andere Geschichte ;-)


----


Davon abgesehen gibt es noch einige weitere Gedanken im Bezug auf lokal veränderte Moduldateien, die neuer sind als die, die über das Update kommen.
Ich habe noch nicht fertig analysiert, wie das FHEM Update Kommando nun tatsächlich festlegt, ob eine Datei geändert wurde, oder nicht. Die selbe Logik soll aber hier dann auch dazu dienen, dass sowohl in FVERSION als auch im Installer deutlich auf eine lokale Änderung hingewiesen wird.
Es ist noch nicht ganz entschieden, ob ich den Update Mechanismus im Installer neu implementieren werde oder ganz/teilweise auf den althergebrachten Update Befehl zurückgreifen werde. Das Ausnahmehandling über das globale Attribut, dass lokale Änderungen nicht überschrieben werden, ist mir so zu umständlich und das soll der Installer anders machen.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

Danke Julian für deine Erläuterungen.
"our $VERSION" habe ich auch schon gesetzt und funktioniert ... man kann im FHEMWEB  {SMAPortal->VERSION()} absetzen und bekommt die Version angezeigt. Klappt allerdings auch ohne "use version 0.77;" vorher.  Wozu braucht man das ?

FHEM::Meta::SetInternals($hash)  werde ich mal implementieren und den Rest durcharbeiten.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

Zitat von: DS_Starter am 13 März 2019, 23:45:05
Klappt allerdings auch ohne "use version 0.77;" vorher.  Wozu braucht man das ?


Naja, das klappt, weil dein Modul kein eigenes Perl Package ist und woanders im main Kontext schon "use version 0.77" aufgerufen wurde. Aber darauf solltest du dich eben nicht verlassen, da kommt es ja auch auf die Ladereihenfolge an und so ;-) Ein mehrfaches "use" macht aber nichts speichertechnisch, soweit ich weiß - einmal geladen ist geladen, es werden nur die vom Modul exportierten Subroutinen in den eigenen Kontext verlinkt (sofern noch nicht vorhanden).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

Hmm, kein eigenes Package sagst du.
Zugegeben, ich fange erst damit an mich etwas mit Packages zu üben, aber der nachfolgende Ausschnitt sollte doch für die Package Definition richtig sein (Läuft auch).


package main;
use strict;
use warnings;

###############################################################
#                  SMAPortal Initialize
# Da ich mit package arbeite müssen für die jeweiligen hashFn
# Funktionen der Funktionsname und davor mit :: getrennt der
# eigentliche package Name des Modules
###############################################################
sub SMAPortal_Initialize($) {
  my ($hash) = @_;

  $hash->{DefFn}     = "SMAPortal::SMAPortal_Define";
  $hash->{UndefFn}   = "SMAPortal::SMAPortal_Undefine";
  $hash->{DeleteFn}  = "SMAPortal::SMAPortal_Delete";
  $hash->{AttrFn}    = "SMAPortal::SMAPortal_Attr";
  $hash->{SetFn}     = "SMAPortal::SMAPortal_Set";
  $hash->{GetFn}     = "SMAPortal::SMAPortal_Get";
  $hash->{AttrList}  = "cookieLocation ".
                       "cookielifetime ".
                       "detailLevel:1,2,3,4 ".
                       "disable:0,1 ".
                       "getDataRetries:1,2,3,4,5,6,7,8,9,10 ".
                       "interval ".
                       "showPassInLog:1,0 ".
                       "timeout ".
                       "userAgent ".
                       $readingFnAttributes;

return FHEM::Meta::InitMod( __FILE__, $hash );           # für Meta.pm (https://forum.fhem.de/index.php/topic,97589.0.html)
}

###############################################################
#                    Begin Package
###############################################################
package SMAPortal;
use strict;
use warnings;
use GPUtils qw(:all);                   # wird für den Import der FHEM Funktionen aus der fhem.pl benötigt
use POSIX;
use FHEM::Meta;
use Data::Dumper;
use Blocking;
use Time::HiRes qw(gettimeofday);
use LWP::UserAgent;
use HTTP::Cookies;
use JSON qw(decode_json);
use MIME::Base64;

# Run before module compilation
BEGIN {
  # Import from main::
  GP_Import(
      qw(
          attr
          AttrVal
          addToDevAttrList
         ....


Habe bei Installer.pm und Cooltux gespickt  ;)
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

Jopps, da hast du ein eigenes Package - idealerweise nennst du es beim vollen Namen FHEM::SMAPortal, es soll sich doch zu FHEM dazugehörig fühlen und nicht so alleine  ;D
Voraussetzung ist, dass es auch in einem Verzeichnis mit dem selben Name (in diesem Fall "FHEM") liegt - ist ja hier der Fall dann.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

Jo, mach ich.
Wie gesagt ich übe an diesem Modul jetzt mal mit Packages und deinem Meta/Installer.  :D
Schaue morgen mal weiter.

Gute Nacht Julian ... feine Sache das  :)

Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

#28
Zitat von: rudolfkoenig am 14 März 2019, 13:59:03
Bitte meine Emailadresse umgehend entfernen.
Ich weiss auch nicht, ob der Link auf dem Verein "rechtens" ist, abgestimmt ist es jedenfalls nicht.

Rudi,

genau diese Abstimmung geschieht in diesem Thread. Ich habe speziell dich explizit angesprochen und um Review gebeten und kann daher deinen verärgerten Unterton absolut nicht nachvollziehen.
Auch hatte ich hier ganz explizit gesagt, dass du als Maintainer der jeweiligen Datei selbstverständlich auch das META.json rüber kopieren kannst und ich es derzeit für fhem.pl lediglich deshalb pflege, weil es ansonsten die Entwicklung behindert. Lass mich wissen, wenn du die Daten übernommen hast und ich passe das entsprechend an.

Deine Email Adresse entferne ich mit dem nächsten Update der Datei Meta.pm.

Zitat von: rudolfkoenig am 14 März 2019, 13:59:03
Ich weiss auch nicht, ob der Link auf dem Verein "rechtens" ist, abgestimmt ist es jedenfalls nicht.

Ich habe explizit in oben bereits erwähntem Beitrag nachgefragt und sogar das Schlagwort "Copyright" erwähnt. Ich denke der Verein gehört zu FHEM jetzt dazu, so habt ihr euch entschieden. Warum man diesen in einer Art "Impressum" beim zentralen FHEM/Global Modul nicht erwähnen sollte, erschließt sich mir nicht. Kann man gerne entfernen, _ich_ habe da nichts davon das drin zu behalten.

Zitat von: rudolfkoenig am 14 März 2019, 13:59:03
Die Privacy Erklaerung ist fraglich: auf der verlinkten Seite geht es um die fhem.de Seiten, und nicht um FHEM als Software.

Ich verweise abermals auf oben genannten Beitrag, bei dem ich auch explizit neben dich auch Jörg als Datenschutzbeauftragten angesprochen habe. Für eine Nicht-Reaktion kann ich nichts, zumal du hinterher auch geantwortet hast und die Themen dann aber offenbar ignoriert hast. Für Ignoranz kann ich keine Verantwortung übernehmen, tut mir leid.

Zitat von: rudolfkoenig am 14 März 2019, 13:59:03
Und ob man diese Version von fhem.pl als "stable" bezeichnen kann, muss auch noch nachgewiesen werden.

Dieses Datenfeld gehört zur offiziellen CPAN::Meta::Spec und ist daher zu befüllen. Wenn du meinst, dass fhem.pl noch in die Kategorie "testing" oder "unstable" fällt, dann hinterlege ich das gerne in META.json für fhem.pl, sofern du den Pod nicht selbst pflegen möchtest.
Noch eine Bemerkung zur Deutung: Das Datenfeld gibt nicht zwangsläufig den tatsächlichen Stabilitätsgrad einer Software an, sondern den gewollten Zustand und ist teil des Lifecycle Managements zur Veröffentlichung von Software.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

ZitatFür Ignoranz kann ich keine Verantwortung übernehmen, tut mir leid.
Nach meiner Erfahrung fuehrt "Opt-Out" haeufig zu Aerger. Ich frage mich, warum diese Angaben notwendig sind, und wieso ich ploetzllch eine Menge an Aufgaben bekomme.

ZitatDieses Datenfeld gehört zur offiziellen CPAN::Meta::Spec und ist daher zu befüllen.
Alternativ verwendet man das Modul nicht. fhem.pl ist weder stable noch unstable oder testing sondern wird per "continuous development" gebaut. Ich habe lange gegen Stable und Development branches gekaempft, und faende es nicht gut, wenn sie durch eine Hintertuer eingefuehrt werden.