FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: Loredo am 19 Februar 2019, 11:43:50

Titel: Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 19 Februar 2019, 11:43:50
Hi,

bei der Recherche zu externen Abhängigkeiten von FHEM Modulen ist mir mal wieder bewusst geworden, wie unterschiedlich das dokumentiert ist und wie schwer es für Nutzer und auch Entwickler ist, diese verlässlich zusammenzutragen oder gar maschinenlesbar auszuwerten. Jetzt, wo André und Co. eine ganze Reihe von Modulen neu bereitgestellt haben, die eine starke Abhängigkeit zu Node.js bzw. NPM Paketen haben, wollte ich das zum Anlass nehmen das ganze zu verbessern.

Für die Installation an sich habe ich als erstes Beispiel einmal das npmjs.pm Modul geschrieben, welches nun Node.js Pakete installieren/deinstallieren/aktualisieren kann. Andrés Module reagieren sogar darauf, wenn NPM was an den Node.js Pakete macht. Allerdings fehlt noch immer die maschinenlesbare Info, dass zum FHEM Modul "alexa" das Node.js Paket "alexa-fhem" gehört und dass beide nur zusammen funktionieren.

Meta.pm ermöglicht es nun, dass man Meta-Informationen als zusätzlichen Pod im JSON Format in eine Moduldatei mit ablegt. Das JSON Format folgt dabei der Spezifikation von CPAN::Meta::Spec (https://metacpan.org/pod/CPAN::Meta::Spec) und wurde um einige Custom Attribute (beginnend mit x_) für FHEM erweitert. Wenn ein Modul Meta.pm implementiert hat, dann gibt es im $modules{<PKG>}{META} Hash die entsprechenden Informationen über die Moduldatei.

Beispiel:


{
  'ORDER' => '42',
  'UndefFn' => 'FHEM::npmjs::Undef',
  'GetFn' => 'FHEM::npmjs::Get',
  'DefFn' => 'FHEM::npmjs::Define',
  'NotifyFn' => 'FHEM::npmjs::Notify',
  'NAME' => 'npmjs',
  'LOADED' => 1,
  'AttrFn' => 'FHEM::npmjs::Attr',
  'SetFn' => 'FHEM::npmjs::Set',
  'AttrList' => 'disable:1,0 disabledForIntervals updateListReading:1,0 npmglobal:1,0 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading',
  'META' => {
              'description' => 'commandref.html#npmjs',
              'x_fhem_maintainer_github' => [
                                              'jpawlowski'
                                            ],
              'author' => [
                            'Julian Pawlowski <julian.pawlowski@gmail.com>'
                          ],
              'x_prereqs_os' => {
                                  'runtime' => {
                                                 'suggests' => {},
                                                 'requires' => {},
                                                 'recommends' => {
                                                                   'debian|ubuntu' => 0
                                                                 }
                                               }
                                },
              'x_prereqs_os_debian' => {
                                         'runtime' => {
                                                        'requires' => {},
                                                        'suggests' => {},
                                                        'recommends' => {
                                                                          'openssh-client' => 0
                                                                        }
                                                      }
                                       },
              'x_file' => [
                            './FHEM/42_npmjs.pm',
                            './FHEM/',
                            '42_npmjs.pm',
                            '42',
                            'npmjs',
                            'pm',
                            [
                              2049,
                              576456,
                              33188,
                              1,
                              6061,
                              6061,
                              0,
                              53269,
                              [
                                1550565749,
                                '2019-02-19 09:42:29',
                                '2019-02-19',
                                '2019',
                                '02',
                                '19',
                                '09:42:29',
                                '09',
                                '42',
                                '29'
                              ],
                              [
                                1550565676,
                                '2019-02-19 09:41:16',
                                '2019-02-19',
                                '2019',
                                '02',
                                '19',
                                '09:41:16',
                                '09',
                                '41',
                                '16'
                              ],
                              [
                                1550565746,
                                '2019-02-19 09:42:26',
                                '2019-02-19',
                                '2019',
                                '02',
                                '19',
                                '09:42:26',
                                '09',
                                '42',
                                '26'
                              ],
                              4096,
                              112
                            ],
                            'META.json',
                            undef
                          ],
              'x_prereqs_permissions_filemod' => {
                                                   'runtime' => {
                                                                  'recommends' => {},
                                                                  'requires' => {},
                                                                  'suggests' => {}
                                                                }
                                                 },
              'x_prereqs_permissions_fileown' => {
                                                   'runtime' => {
                                                                  'recommends' => {},
                                                                  'suggests' => {},
                                                                  'requires' => {}
                                                                }
                                                 },
              'resources' => {
                               'license' => [
                                              'https://fhem.de/#License'
                                            ],
                               'repository' => {
                                                 'x_branch_dev' => 'trunk',
                                                 'x_branch_master' => 'trunk',
                                                 'type' => 'svn',
                                                 'url' => 'https://svn.fhem.de/fhem/',
                                                 'web' => 'https://svn.fhem.de/'
                                               },
                               'bugtracker' => {
                                                 'x_web_title' => 'Sonstige Systeme',
                                                 'web' => 'https://forum.fhem.de/index.php/board,29.0.html'
                                               },
                               'homepage' => 'https://fhem.de/'
                             },
              'name' => 'FHEM::npmjs',
              'meta-spec' => {
                               'url' => 'https://metacpan.org/pod/CPAN::Meta::Spec',
                               'version' => 2
                             },
              'prereqs' => {
                             'runtime' => {
                                            'recommends' => {},
                                            'requires' => {
                                                            'perl' => '5.014',
                                                            'GPUtils qw(GP_Import)' => 0,
                                                            'Data::Dumper' => 0,
                                                            'JSON' => 0
                                                          },
                                            'suggests' => {}
                                          }
                           },
              'x_prereqs_binary_exec' => {
                                           'runtime' => {
                                                          'recommends' => {},
                                                          'requires' => {
                                                                          '/usr/bin/npm|/usr/local/bin/npm' => 0,
                                                                          '/usr/bin/node|/usr/local/bin/node' => 0
                                                                        },
                                                          'suggests' => {
                                                                          '/usr/bin/ssh|/usr/local/bin/ssh' => 0
                                                                        }
                                                        }
                                         },
              'keywords' => [
                              'fhem-core',
                              'fhem-mod',
                              'fhem-mod-device',
                              'nodejs',
                              'node',
                              'npm'
                            ],
              'dynamic_config' => 1,
              'x_lang' => {
                            'DE' => {
                                      'description' => '/./docs/commandref_DE.html#npmjs',
                                      'abstract' => 'Modul zur Bedienung der Node.js Paket Installation und Updates'
                                    },
                            'de' => {
                                      'description' => 'commandref.html#npmjs',
                                      'abstract' => 'Modul zur Bedienung der Node.js Installation und Updates'
                                    }
                          },
              'generated_by' => 'FHEM::Meta v0.0.1, 2019-02-19 09:42:29',
              'license' => 'GPL_3',
              'release_status' => 'stable',
              'x_prereqs_os_ubuntu' => {
                                         'runtime' => {
                                                        'suggests' => {},
                                                        'requires' => {},
                                                        'recommends' => {
                                                                          'openssh-client' => 0
                                                                        }
                                                      }
                                       },
              'x_fhem_maintainer' => [
                                       'loredo'
                                     ],
              'abstract' => 'Module to control Node.js package installation and update',
              'version' => 'v0.10.3',
              'x_prereqs_nodejs' => {
                                      'runtime' => {
                                                     'recommends' => {},
                                                     'suggests' => {},
                                                     'requires' => {
                                                                     'node' => '8',
                                                                     'npm' => 0
                                                                   }
                                                   }
                                    },
              'x_vcs' => [
                           '$Id: 42_npmjs.pm 18636 2019-02-19 02:26:02Z loredo $',
                           '42_npmjs.pm',
                           '42',
                           'npmjs',
                           'pm',
                           '18636',
                           '2019-02-19 02:26:02',
                           '2019-02-19',
                           2019,
                           '02',
                           '19',
                           '02:26:02',
                           '02',
                           '26',
                           '02',
                           'loredo',
                           1550543162
                         ],
              'x_prereqs_python' => {
                                      'runtime' => {
                                                     'suggests' => {},
                                                     'requires' => {},
                                                     'recommends' => {}
                                                   }
                                    },
              'x_prereqs_sudo' => {
                                    'runtime' => {
                                                   'suggests' => {
                                                                   'ALL=NOPASSWD: /usr/local/bin/npm install *' => 0,
                                                                   'ALL=NOPASSWD: /usr/bin/npm install *' => 0
                                                                 },
                                                   'requires' => {},
                                                   'recommends' => {
                                                                     'ALL=NOPASSWD: /usr/bin/npm update *' => 0,
                                                                     'ALL=NOPASSWD: /usr/local/bin/npm update *' => 0
                                                                   }
                                                 }
                                  },
              'x_version' => '42_npmjs.pm:v0.10.3-s18636/2019-02-19'
            }
}



Das npmjs.pm Modul nutzt Meta.pm einmal beispielhaft zur Anzeige der Versionsinformation als INTERNAL (siehe Screenshot anbei). Die Paketabhängigkeiten werden noch nicht ausgewertet, sollen aber in einem widerum separaten Installer Modul einmal dem Benutzer verfügbar gemacht werden, um idealerweise diese auch per Klick auflösen zu können.

Was man auch schon machen kann ist die Meta Informationen für alle Module zu laden, entweder für alle, die auch aktuell geladen sind oder auch für die, die derzeit nicht in der FHEM Instanz verwendet werden. Bei Modulen, die noch keinen META.json Pod haben, werden die Informationen so gut es geht aus anderen Quellen zusammengetragen (SVN Info, Dateiname, etc.).

André hat sich das ganze auch gewünscht, weil der für sein geplantes Discovery Modul ebenfalls die Möglichkeit braucht Informationen über ein Modul abzufragen, obwohl es noch nicht geladen wurde.

Das ganze ist jetzt mal eine erste Version, wahrscheinlich ändern sich Funktionsaufrufe nochmal hier und dort. Besser also nichts überstürzen :-)



Gruß
Julian
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 20 Februar 2019, 08:57:00
In diesem Zusammenhang habe ich noch eine Frage an @Rudi:


Findet sich die aktuelle Major Versionsnummer von FHEM noch woanders als im Makefile, insbesondere in einer Datei, die auch über den Update Mechanismus aktualisiert wird?


Danke und Gruß
Julian
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 20 Februar 2019, 09:03:35
Meinst du featurelevel?
"Major Versionsnummer" ist bei dem Entwicklungsmodell von FHEM wenig aussagekraeftig.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 20 Februar 2019, 09:08:43
Nein, ich meine nicht Feature Level.


Du hast mir schon einige Male erklärt, dass der Major Versionsstand nicht so aussagekräftig ist. Allerdings wird die Version ja trotzdem auf der Website und auch beim Namen des Debian Paketes genannt, sie spielt also trotzdem eine gewisse Rolle und Menschen (TM) sind halt daran gewöhnt, dass sie die Version, die sie auf der Website finden, dann auch irgendwo in der Software nachkontrollieren können. Zumindest mir leuchtet dann nach wie vor nicht ein, warum es dann überhaupt noch eine Version in diesem Format geben muss. Warum dann nicht sowas wie <2-stelliges Jahr>.<Releasemonat>? Oder eben komplett auf die Versionsnummer verzichten.


Aber solange die Versionsnummer irgendwo herumschwirrt, würde ich sie auch als Meta-Information verstehen und bereitstellen.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 20 Februar 2019, 09:11:25
Naja so wie ich das verstanden habe ist es ja gerade eben keine Versionsnummer, sondern ein Featurelevel. Sprich ab diesem Level gibt es einige "gravierende" Änderungen. Meistens im Standardverhalten von Funktionen in der fhem.pl


Grüße
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 20 Februar 2019, 09:21:32
Ok dann frage ich anders: Wo kann ich das aktuell höchste Feature Level auslesen, was der Benutzer einstellen kann?
Ist die Attributauswahl da verlässlich genug?
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: nils_ am 20 Februar 2019, 09:37:35
Zitat von: Loredo am 20 Februar 2019, 09:21:32
Ok dann frage ich anders: Wo kann ich das aktuell höchste Feature Level auslesen, was der Benutzer einstellen kann?
Ist die Attributauswahl da verlässlich genug?

https://forum.fhem.de/index.php/topic,97528.0.html

das höchste steht doch in $featurelevel, der user kann doch nur weniger einstellen. (spezialfall: 99.99)
so hab ich es verstanden.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 20 Februar 2019, 09:43:56
Am besten ist Du liest die globale Variable $featurelevel aus.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 20 Februar 2019, 09:47:36
Da sind wir genau bei dem Dilemma.
Die globale Variable $featurelevel gibt an, was der User eingestellt hat. Der Inhalt der Datei fhem.pl ist aber trotzdem nicht auf dem Stand von featurelevel 5.7 oder ähnliches.


Ich lese jetzt die Auswahlliste für featurelevel aus $modules{'Global'}{AttrList} aus. Ich wollte nur sicherstellen, dass diese Auswahlliste dann das einzig wahre Indiz dafür ist, welches der aktuellste Featurelevel ist und es dann richtig ist diesen als Major Version zu interpretieren.


Edit: Danke @nils_, den Beitrag kannte ich nicht. Dann macht das ganze jetzt auch Sinn für mich :-)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: nils_ am 20 Februar 2019, 09:58:49
Zitat von: Loredo am 20 Februar 2019, 09:47:36
Edit: Danke @nils_, den Beitrag kannte ich nicht. Dann macht das ganze jetzt auch Sinn für mich :-)
es gibt in letzter zeit gehäuft fragen dazu (warum weiß ich auch nicht....), da hab ich mal einen der letzten beiträge dazu rausgesucht. und dann natürlich mit der hoffnung etwas licht ins dunkel zu bringen (hat ja anscheinend funktioniert :) )
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 20 Februar 2019, 10:07:18
Zitat von: nils_ am 20 Februar 2019, 09:58:49
es gibt in letzter zeit gehäuft fragen dazu (warum weiß ich auch nicht....)


Meine Interpretation: Viele haben erkannt, dass FHEM inzwischen eine kritische Komponente ist und damit kommen Themen wie Backup und vor allem ein sauberer/einfacher/schneller Restore ins Spiel. Zwangsläufig wird man dann mit Fragen zur Versionierung konfrontiert und stößt dann auch darauf, wie man eigentlich damit bei FHEM umgeht. Bei anderen Projekten kann man einen komplett fixen Versionsstand adressieren und hat dann einen fest definierten Zustand. Das kriegt man bei FHEM derzeit leider nicht so einfach hin (siehe auch Diskussionen zum Docker Image).
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 20 Februar 2019, 10:26:44
Daher ja auch mein neues backupME Perl Skript. Ich habe es endlich mal geschafft mein Bash Skript zum Sichern in ein schönes Perl Skipt zu gießen.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: betateilchen am 20 Februar 2019, 10:40:36
um auf die ursprüngliche Frage zurückzukommen:

Zitat von: Loredo am 20 Februar 2019, 08:57:00
Findet sich die aktuelle Major Versionsnummer von FHEM noch woanders als im Makefile, insbesondere in einer Datei, die auch über den Update Mechanismus aktualisiert wird?

Die "Versionsnummer" 5.9, die für die Erzeugung beispielsweise des Namens für das  Debian Paket verwendet wird, kommt ausschließlich aus dem Makefile.
Das Makefile selbst ist - wenn ich es richtig in Erinnerung habe - nicht Bestandteil der ausgelieferten Installationspakete und wird somit auch nicht per Update verteilt.

Du wirst also das Makefile auf einem typischen, aus einem Installationspaket stammenden FHEM System, gar nicht vorfinden.

Zitat von: Loredo am 20 Februar 2019, 10:07:18
Bei anderen Projekten kann man einen komplett fixen Versionsstand adressieren und hat dann einen fest definierten Zustand. Das kriegt man bei FHEM derzeit leider nicht so einfach hin (siehe auch Diskussionen zum Docker Image).

Einen fest definierten Zustand (ohne die Nutzung von svn) hast Du bei FHEM immer nur für den Zeitpunkt, an dem Rudi ein neues "Major Release" freigibt, also z.B. 5.8 oder 5.9. Im nightly build des Debian Paketes wird an die Versionsnummer 5.9 deshalb immer noch die svn Rev-Nummer angehängt, die in diesem nightly build enthalten ist.

Vor einer ähnlichen Frage wie der von Dir gestellten, standen Markus und ich im Rahmen des Neubaus der FHEM Statistik. "Wie bekommen wir raus, wie "alt" eine FHEM Installation beim Anwender ist?"

Die REV Id einer FHEM Installation befindet sich in der ersten Zeile der Datei /opt/fhem/controls_fhem.txt - und diese Datei wird per Update ausgeliefert!
Aus dieser Information kann man feststellen, wann die Installation zum letzten Mal ein Update erfahren hat, somit steht auch fest, welches "Major Release" die Installation hat.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: nils_ am 20 Februar 2019, 11:14:38
Zitat von: Loredo am 20 Februar 2019, 10:07:18
Bei anderen Projekten kann man einen komplett fixen Versionsstand adressieren und hat dann einen fest definierten Zustand. Das kriegt man bei FHEM derzeit leider nicht so einfach hin (siehe auch Diskussionen zum Docker Image).
da kannste dich ja eigentlich nur auf die svn-revision beziehen, um einen definierten zustand aller dateien zu diesem zeitpunkt adressieren zu können.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 10 März 2019, 15:52:03
Ich habe das Meta.pm Paket jetzt denke ich in einem solchen Status, dass man damit etwas anfangen kann.
Als erster Showcase habe ich begonnen den FHEM Installer (https://forum.fhem.de/index.php/topic,98381.0.html) zu schreiben, mit dem man die Metadaten entsprechend auswerten kann.


@justme1968/André, wir könnten jetzt beispielsweise auch die Node.js Abhängigkeiten als Metadaten in deine Module hängen und entsprechend mit anzeigen. Das npmjs Modul kann dann entsprechend dynamisch die Installationsliste generieren anstatt wie bisher statisch über einen Hash, der bei mir im Modul liegt.
Außerdem kannst du glaube ich anfangen dein Service Discovery Modul hervorzukramen :-)


@Rudi @Jörg und andere: Mir erschien es sinnvoll auch einige Compliance Dinge mit anzuzeigen bzw. zu verlinken (z.B. Copyright, Datenschutzerklärung).
Natürlich kann man die Links ändern, aber derzeit gibt es z.B. keine dedizierte Datenschutzerklärung für FHEM als Software. Ggf. bitte einen gesonderten Thread für die inhaltliche Diskussion zu Compliance/Privacy/Legal Themen aufmachen, wenn ihr euch dabei angesprochen fühlt.




Gruß
Julian
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 10 März 2019, 16:15:51
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?
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 10 März 2019, 23:23:37
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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag 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:               
=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 :)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 11 März 2019, 22:07:46
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 (https://metacpan.org/pod/CPAN::Meta::Spec#Version-Formats)


Ich habe mich hier für die Dotted-integer Variante entschieden (also dem Semantic Versioning (https://semver.org)), 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 (https://svn.fhem.de/trac/changeset/18872/) 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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag 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.


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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 März 2019, 12:40:11
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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 März 2019, 22:37:30
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
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 März 2019, 23:26:05
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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 März 2019, 23:45:05
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
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 März 2019, 23:55:01
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).
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 14 März 2019, 00:02:27
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  ;)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 14 März 2019, 00:14:30
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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 14 März 2019, 00:18:11
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
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 14 März 2019, 15:59:46
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 (https://forum.fhem.de/index.php/topic,97589.15.html). Ich habe speziell dich explizit angesprochen (https://forum.fhem.de/index.php/topic,97589.msg917221.html#msg917221) und um Review gebeten und kann daher deinen verärgerten Unterton absolut nicht nachvollziehen.
Auch hatte ich hier ganz explizit gesagt (https://forum.fhem.de/index.php/topic,97589.msg917512.html#msg917512), 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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 14 März 2019, 17:02:21
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.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 14 März 2019, 17:13:50
Zitat von: rudolfkoenig am 14 März 2019, 17:02:21
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.

Du hast überhaupt gar keine Aufgaben bekommen. Soweit ich weiß, bist du der eingetragene Maintainer für fhem.pl und in dieser Funktion habe ich dich darüber informiert, dass ein anderes Modul dessen Daten analysiert und deren Ergebnisse zur Kenntnis und Durchsprache vorgelegt. Du kannst da frei entscheiden, wie du deine Rolle als Maintainer definierst und wahrnimmst.
Dafür, dass ich offenbar bisher ungeklärte Fragestellungen des FHEM e.V. bei dir aufgeworfen habe, kann ich nichts. Ich nehme also zur Kenntnis, dass Transparenz und eine gewisse Rechtssicherheit für dich und den FHEM e.V. nicht von Bedeutung sind. Das ist absolut in Ordnung und hier ja nun auch dokumentiert.


Für mich bleibt aber die Frage: Wo ist denn dein "Continuous Development", wenn man nicht einen Arbeitsstand einchecken darf, um ihn dann stetig weiterzuentwickeln? Ich habe ja überhaupt nichts in Stein gemeißeltes getan und dich auch brav nach Rückmeldung gefragt. Sicherlich hätte ich auch hier einige Tausend Zeilen Quellcode hochladen können und dann nächstes Jahr nochmal nachfragen, ob sich das wer angesehen hat... ich handelte und handele nach bestem Wissen und Gewissen und wenn ich mich einmal getäuscht haben sollte, dann kann ich das ja im Rahmen des Continuous Development Gedanken jederzeit und direkt korrigieren.

Zitat von: rudolfkoenig am 14 März 2019, 17:02:21Alternativ verwendet man das Modul nicht. fhem.pl ist weder stable noch unstable oder testing sondern wird per "continuous development" gebaut.


Korrekt. Niemand wird gezwungen Meta.pm in sein Modul einzubauen oder 98_Installer zu verwenden. Das habe ich immer betont.
Aber wie mir scheint hast du dich gar nicht über CPAN::Meta::Spec informiert. Sonst wüsstest du, dass das gar kein Modul ist, sondern eine Spezifikation (wie der Name am Ende schon vermuten lassen könnte...).


Zitat von: rudolfkoenig am 14 März 2019, 17:02:21
Ich habe lange gegen Stable und Development branches gekaempft, und faende es nicht gut, wenn sie durch eine Hintertuer eingefuehrt werden.


Ich lese nur, dass du etablierte Standards und Best Practices, nach denen andere arbeiten und auch gerne arbeiten möchten, nicht gut findest.
Und nach einer solchen Aussage wunderst du dich noch darüber, dass du meinst hier würde ein "Opt-Out" durchgeführt?  ::)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: justme1968 am 14 März 2019, 17:18:37
bitte atmet doch beide mal tief durch und schaukelt euch nicht hoch.

es wäre schade wenn das hier wegen aneinander vorbei reden oder anderen missverständnissen  im sande verläuft.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 14 März 2019, 17:20:55
Zitat von: justme1968 am 14 März 2019, 17:18:37
bitte atmet doch beide mal tief durch und schaukelt euch nicht hoch.

es wäre schade wenn das hier wegen aneinander vorbei reden oder anderen missverständnissen  im sande verläuft.


Mich nervt einfach dieses unkonstruktive und respektlose Herumgemaule.
Dass es mich trotzdem wenig kratzt, sieht man ja daran, dass Rudi mich auch nach all den Jahren noch nicht vergrault hat.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 14 März 2019, 17:37:08
Hallo Julian, Hallo Rudi,

Eventuell hilft es Euch beiden wenn der Julian versucht kleinere Sprünge zu machen (nicht gleich email Adressen rein nehmen oder Verlinkungen zu machen zum Verein) und wartet bis sich der Verein oder Rudi auf explizite Anfragen gemeldet hat. Es ist nicht einfach alle Stimmberechtigten innerhalb von ein paar Tagen zu bekommen.

Und vielleicht mag Rudi einfach mal kurz erzählen was er von der derzeitigen Entwicklung der beiden Module hält und die Idee die Julian für die Zukunft hat. Er hat ja schon so einiges geschrieben. Die Nutzer finden es jedenfalls bis jetzt eine gute Entwicklung sagen sie.
Ich verstehe aber auch Rudi der nun Aufgaben bekommen hat (in Form von Anfragen und Bitten) aber anscheinend noch keine wirkliche Zeit gefunden hat dafür.
Julian Du stemmst da eine ziemlich große Sache und ich finde sie super, aber eshängt auch einiges an Entscheidungen von Rudi ab die Du vielleicht erstmal bitte abwartest, oder halt in Deinen Modulen vorerst verschiebst oder mit Dummys belegst. Es hilft weder dem wundervollen Projekt von Julian noch FHEM mit Rudi wenn das jetzt ausarten sollte. Daher wie Andre schon sagte bitte tief durchatmen und versuchen einen gemeinsamen Konzens zu finden.


Entspannte Grüße
Marko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 14 März 2019, 18:54:36
ZitatUnd vielleicht mag Rudi einfach mal kurz erzählen was er von der derzeitigen Entwicklung der beiden Module hält und die Idee die Julian für die Zukunft hat.
Ich habe jetzt versucht die beiden Themen durchzulesen, evtl. habe ich was uebersehen.

Ich sehe auch das Problem der externen Abhaengigkeiten, meine persoenliche Loesung ist diese soweit wie moeglich zu vermeiden, siehe FHEMWEB, MQTT2, usw.

Ein Modul zu schreiben, was die benoetigten Module oder Programme installiert, ist loeblich, das richtig zu machen ist viel Entwicklungsarbeit und noch mehr Supportaufwand. Ich verstehe, dass eine Kooperation der Module, die sowas brauchen, die Sache erleichtert, aber (noch?) nicht, wozu copyright, oder privacy-statements dabei notwendig sind, oder was Installer.pm mit fhem.pl anfangen will (installieren ja nicht).

Aber das ist ja auch egal, ich bin kein Visionaer, und lasse mich gerne ueberraschen, wenn ich dafuer nichts tun muss. Ich will nur meine Emailadresse nicht in einem mailto: Link sehen, ich kriege jetzt schon ausreichend Zuschriften der Sorte "Mein letztes FS20RSU ist kaputt, haben sie noch was auf dem Lager", und jetzt sind noch die ausgefiltert, die kein Copy&Paste beherrschen. Mit einem mailto: Link ist das auch keine Voraussetzung mehr.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 14 März 2019, 19:02:41
Danke Dir Rudi für Dein Statement. Ich denke auf Basis Deiner Aussage kann Julian seine Module weiter voran bringen und weiß nun erstmal wo er ganz auf Angaben verzichtet oder eben einfach noch mal nach fragt.

@Julian
Da ich nun auch festes FHEM e.V. Mitglied bin biete ich mich gerne als Vermittler bei weiteren Fragen an.
@ Rudi wäre das auch in Deinem Interesse?


Grüße
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 14 März 2019, 19:16:22
ZitatDa ich nun auch festes FHEM e.V. Mitglied bin biete ich mich gerne als Vermittler bei weiteren Fragen an.
Gerne.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 14 März 2019, 19:20:38
Danke sehr, Rudi. Diese Art der Formulierung ist die Art von Umgang, den ich mir wünsche und auch selbst pflegen möchte, wenn man ihn mir so entgegen bringt.


Von meiner Seite aus ist es lediglich ein Anreiz gewesen, auch nicht-technische Informationen mit anzuzeigen. Data Privacy bewegt eben viele und wenn man alle Informationen über den Anbieter (FHEM e.V., nach meinem Verständnis) sowie auch ein Statement zu Thema Datenschutz an einer zentralen Stelle (und so verstehe ich den Installer) finden kann, dann trägt das zur Transparenz bei. Meiner Meinung nach muss man sich da auch nicht viel Aufwand mit machen (außer dann vielleicht der Frage "wem gehört jetzt FHEM bzw. wer ist der Diensteanbieter für das Gesamtprodukt?"). Diese Fragen will und kann ich euch auch gar nicht beantworten, beruflich bedingt weiß ich aber, dass diese Dinge oft ein notwendiges Übel sein können. Da es bisher aber auch kein Thema für FHEM war, soll es nun auch dann dabei belassen sein. Modulautoren haben nach wie vor die Möglichkeit für ihre eigenen Module solche Informationen zu hinterlegen, wenn sie das für wichtig halten.


Zu der Frage, was der Installer mit fhem.pl tut: Der Installer bildet ein vollumfängliches Bild der Abhängigkeiten ab, FHEM intern wie extern und auch über Perl hinaus. Grundlage ist alles, was in %modules steht. Dort gibt es eben auch 'Global' als Modul, also ein Alias für fhem.pl. Ich fand bisher nicht, dass deine Arbeit am zentralen Herzstück nun weniger Aufmerksamkeit verdient hätte als alle anderen Module, deren Abhängigkeiten und Details angezeigt werden können.


Man muss aber natürlich auch sagen: Der Getter showModuleInfo ist jetzt natürlich das einzige Feature, was man sehen kann. Das bleibt aber ja nicht so und es ist keinesfalls der Dreh und Angelpunkt wenn es darum geht, einfach nur zu schauen, was fehlt und diese fehlenden Abhängigkeiten nachzuinstallieren. Da fhem.pl wahrscheilich niemals etwas fehlen wird, wird es auch eher unwahrscheinlich in der Liste mit fehlenden Abhängigkeiten auftauchen  ;)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: justme1968 am 14 März 2019, 21:42:02
ich habe eben eine alexa version mit den ersten meta infos eingecheckt. du kannst also anfangen die node modul info auszuwerten und auch in npmjs einzubauen.

ich hatte versucht die perl version als v5.14.x anzugeben. dann gibt es aber einen fehler aus Meta.pm mit is not numeric.

Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 15 März 2019, 08:38:39
Zitat von: justme1968 am 14 März 2019, 21:42:02
ich habe eben eine alexa version mit den ersten meta infos eingecheckt. du kannst also anfangen die node modul info auszuwerten und auch in npmjs einzubauen.


Prima, mache ich! Wird dann aber erstmal noch ein Mix sein müssen, weil die anderen ja noch nachziehen müssen :-)


Zitat von: justme1968 am 14 März 2019, 21:42:02
ich hatte versucht die perl version als v5.14.x anzugeben. dann gibt es aber einen fehler aus Meta.pm mit is not numeric.


Ja, das ist richtig. Du musst von semver auf nummerisch umrechnen. Das geht ganz einfach:


5 -> bleibt so
14 -> 014 (3-stellig machen)
x -> 00x (3-stellig machen)


Was du also angeben musst ist 5.01400x (ich weiß nicht, wofür x bei dir stehen sollte).




Gruß
Julian
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: justme1968 am 15 März 2019, 08:48:48
das x war nur ein platzhalter :)

wir haben doch computer. warum muss man dann etwas selber umrechnen? wäre toll wenn das modul das macht :).

Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 15 März 2019, 09:20:16
Zitat von: justme1968 am 15 März 2019, 08:48:48
das x war nur ein platzhalter :)

wir haben doch computer. warum muss man dann etwas selber umrechnen? wäre toll wenn das modul das macht :) .


Jaein, dann ist der META.json nicht mehr standard konform und kann von anderer Software nicht mehr ausgewertet werden.
Alle Datenfelder, die nicht mit x_ anfangen, sind schon vordefiniert in ihrem Datenformat und ich würde gerne zu der bestehenden CPAN Spezifikation kompatibel bleiben, ohne dass FHEM zwangsläufig gestartet werden muss.


Dass so viele Dinge von jedem anders gemacht werden, damit kämpfe ich ja gerade extrem beim zusammensammeln und harmonisieren aller Datenquellen. Da würde ich das nicht noch fördern wollen ;-)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: justme1968 am 15 März 2019, 09:22:17
ok. trotzdem doof :)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 15 März 2019, 12:12:04
Ich hab dir da Quark erzählt.
Habe vergessen, dass später auch noch die Auswertung als ">=x.xx,<y.yy" und so weiter notwendig ist. Von daher baue ich eine Normalisierung ein, im generierten JSON wird dann immer der nummerische Wert hinterlegt, damit man ihn direkt für Vergleiche hernehmen kann. Für eine Anzeige im Userinterface rechnet man es dann bedarfsweise um oder nicht.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 15 März 2019, 16:29:17
Hi Julian,

ich hatte dir doch in #21 berichtet, dass das Internal FVERSION bei meinem Versuchen nicht gesetzt wurde.
Inzwischen habe ich mich intensiver damit und deinem Meta.pm befasst und nun klappt es.
Das Problem lag in der $Id - Zeile. Nur wenn sie komplett gefüllt ist, wie z.B.

  $Id: 76_SMAPortal.pm 00000 2019-03-14 22:03:37Z DS_Starter $

wird {x_version} gesetzt was dann ja mit FHEM::Meta::SetInternals auf das Internal abgebildet wird.
Da mein contrib-Modul nicht eingecheckt ist und diese Zeile nicht komplett gefüllt hatte, klappte das eben nicht.
Weiß nicht ob du für noch nicht eingecheckte Module diesbezüglich etwas ändern möchtest.
Das nur nochmal als Feedback, ansonsten klappte bisher alles super bei meinen Tests.  :)

Grüße,
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Martin Fischer am 15 März 2019, 20:39:41
Hallo Zusammen,

ich bitte im Zusammenhang mit "Meta.pm" folgenden Sachverhalt zu prüfen:

Seit ~11 Jahren liegt meine "fhem.pl" unter "/usr/bin/fhem.pl". Entsprechend ist "attr global modpath /opt/fhem" gesetzt. Diese seit langem funktonierende Konstellation führt nun dazu, dass das System mit allen Modulen, die "use FHEM::Meta" beinhaltet, crashed ("Can't locate FHEM/Meta.pm in @INC").

In "fhem.pl" wird "@INC" gesetzt:
    my $modpath = "$val/FHEM";

    opendir(DH, $modpath) || return "Can't read $modpath: $!";
    push @INC, $modpath if(!grep(/\Q$modpath\E/, @INC));


"Meta.pm" wird via "use FHEM::Meta;" eingebunden, was insofern funktoniert, wenn "attr global modpath ." gesetzt ist und sich "fhem.pl" im selbigen Pfad wie "modpath" befindet. Das funktioniert, weil in "@INC" immer auch "." enthalten ist.

Da Perl davon ausgeht, dass das Modul relative zum "Hauptprogramm" ("fhem.pl") geladen werden soll, schaut Perl also unabhängig von "modpath" eben auch in das Verzeichnis wo "fhem.pl" liegt und findet dann auch "./FHEM/Meta.pm".

Das "use FHEM::Meta" funktioniert demnach nicht, wenn "fhem.pl" eben nicht mehr im selben Verzeichnis wie das Verzeichnis "FHEM" liegt. "@INC" wird in "fhem.pl" auf "$modpath = "$val/FHEM";" gesetzt. Jetzt sucht Perl per-se in "." (im obigen Fall "/usr/bin/") sowie den Standardsuchpfaden plus dem "modpath" aus "fhem.pl" (hier jetzt: "/opt/fhem/FHEM") und schon knallt es, da "use FHEM::Meta;" dann eigentlich "use Meta;" lauten müsste, analog zu anderen "Hilfsmodulen" wie "HttpUtils", "Blocking", "SetExtensions", etc.

Ich freue mich, wenn dies beim nächsten Update berücksichtigt wird.

Danke und viele Grüße
Martin

Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 16 März 2019, 12:13:37
Hi Julian,

nach einem update heute ist mir der Eintrag


2019.03.16 11:50:40.674 3: FHEM::Meta::__GetMetadata WARNING: Unregistered core module or package:
  FHEM/57_ABFALL.pm has defined VCS data but is not registered in MAINTAINER.txt


im Log meines Systems aufgefallen.
Das Modul ABFALL ist aber kein eingechecktes Modul und hat in seinem Initialize auch nicht FHEM::Meta eingebunden.
Ich verwende es aber, d.h. durch Verwendung wird Meta veranlasst es auszuwerten.
Meiner Meinung nach dürfte aber dieser Log-Eintrag nicht kommen weil es keine {x_vcs} Daten gibt.


{
  'version' => '0.000000001',
  'name' => 'ABFALL',
  'generated_by' => 'FHEM::Meta v0.1.8, 2019-03-16 11:50:39',
  'dynamic_config' => 1,
  'license' => 'unknown',
  'x_prereqs_src' => 'scanner',
  'x_file' => [
                'FHEM/57_ABFALL.pm',
                'FHEM/',
                '57_ABFALL.pm',
                '57',
                'ABFALL',
                'pm',
                [
                  2049,
                  786693,
                  33279,
                  1,
                  999,
                  20,
                  0,
                  9873,
                  [
                    1552726674,
                    '2019-03-16 09:57:54',
                    '2019-03-16',
                    '2019',
                    '03',
                    '16',
                    '09:57:54',
                    '09',
                    '57',
                    '54'
                  ],
                  [
                    1548017748,
                    '2019-01-20 21:55:48',
                    '2019-01-20',
                    '2019',
                    '01',
                    '20',
                    '21:55:48',
                    '21',
                    '55',
                    '48'
                  ],
                  [
                    1552726661,
                    '2019-03-16 09:57:41',
                    '2019-03-16',
                    '2019',
                    '03',
                    '16',
                    '09:57:41',
                    '09',
                    '57',
                    '41'
                  ],
                  4096,
                  24
                ],
                'generated/blank',
                undef
              ],
  'meta-spec' => {
                   'version' => 2,
                   'url' => 'https://metacpan.org/pod/CPAN::Meta::Spec'
                 },
  'author' => [
                'unknown <>'
              ],
  'description' => 'n/a',
  'x_version' => '57_ABFALL.pm:?/2019-01-20 UNSTABLE',
  'prereqs' => {
                 'runtime' => {
                                'requires' => {
                                                'Time::Piece' => '0',
                                                'Time::Local' => '0',
                                                'ABFALL_setUpdate' => '0',
                                                'POSIX' => '0',
                                                'warnings' => '0',
                                                'strict' => '0'
                                              }
                              }
               },
  'release_status' => 'unstable'
}


Solltest vllt. nochmal checken.

LG,
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 18 März 2019, 08:57:20
Zitat von: DS_Starter am 15 März 2019, 16:29:17
Das Problem lag in der $Id - Zeile. Nur wenn sie komplett gefüllt ist, wie z.B.

  $Id: 76_SMAPortal.pm 00000 2019-03-14 22:03:37Z DS_Starter $

wird {x_version} gesetzt was dann ja mit FHEM::Meta::SetInternals auf das Internal abgebildet wird.
Da mein contrib-Modul nicht eingecheckt ist und diese Zeile nicht komplett gefüllt hatte, klappte das eben nicht.
Weiß nicht ob du für noch nicht eingecheckte Module diesbezüglich etwas ändern möchtest.

Das Modul versucht in der Tat sehr streng zu unterscheiden, welche Module tatsächlich zu FHEM Core gehören und welche lokal sind.
Ich hatte die Auswertung der Update Daten noch nicht fertig, inzwischen sollte es jedoch kein Problem mehr sein lokale Module zu verwenden. Auch Module aus anderen Quellen, die über den Update Befehl geladen werden, werden unterschieden. Zu erkennen sollte das jeweils an den automatisch hinzugefügten Keywords "fhem-mod-local" bzw. "fhem-3rdparty" sein.

Zitat von: DS_Starter am 16 März 2019, 12:13:37
Das Modul ABFALL ist aber kein eingechecktes Modul und hat in seinem Initialize auch nicht FHEM::Meta eingebunden.
Ich verwende es aber, d.h. durch Verwendung wird Meta veranlasst es auszuwerten.
Meiner Meinung nach dürfte aber dieser Log-Eintrag nicht kommen weil es keine {x_vcs} Daten gibt.

Doch, die VCS Daten gibt es, sie wurden aber bis dato verworfen (nicht in den generierten META Hash verlinkt), weil eben die Integration der Update Files noch nicht fertig war. Inzwischen sollte das gehen, ich habe aber mit externen Modulen noch nicht viel probiert, nur mit lokalen und Kopien von FHEM Modulen. Bei letzteren werden auch absichtlich die VCS Daten ignoriert, weil sie nicht mit dem Dateinamen übereinstimmen. Was ich nun noch versuchen möchte ist irgendwie zu erkennen, ob man ein FHEM Modul lokal geändert hat, sprich ob es nicht mehr mit den Update Daten überein stimmt und ein neueres Änderungsdatum hat. Lokale Änderungen sollen dann auch im x_version Attribut bzw. FVERSION Internal deutlich angezeigt werden, wenn ein Modul über ein Repository verwaltet wird.

Zitat von: Martin Fischer am 15 März 2019, 20:39:41
Seit ~11 Jahren liegt meine "fhem.pl" unter "/usr/bin/fhem.pl". Entsprechend ist "attr global modpath /opt/fhem" gesetzt. Diese seit langem funktonierende Konstellation führt nun dazu, dass das System mit allen Modulen, die "use FHEM::Meta" beinhaltet, crashed ("Can't locate FHEM/Meta.pm in @INC").

In "fhem.pl" wird "@INC" gesetzt:
    my $modpath = "$val/FHEM";

    opendir(DH, $modpath) || return "Can't read $modpath: $!";
    push @INC, $modpath if(!grep(/\Q$modpath\E/, @INC));


Eigentlich tendiere ich dazu zu sagen, dass in fhem.pl eine Reihe von Pfadangaben für @INC fehlen. Das sieht man auch in GPUtils.pm:


#add FHEM/lib to @INC if it's not allready included. Should rather be in fhem.pl than here though...
BEGIN {
  if (!grep(/FHEM\/lib$/,@INC)) {
    foreach my $inc (grep(/FHEM$/,@INC)) {
      push @INC,$inc."/lib";
    };
  };
};


Abgeleitet von $attr{global}{modpath} sollten deshalb folgende Pfade in @INC aufgenommen werden:

$attr{global}{modpath}
$attr{global}{modpath}.'/FHEM'
$attr{global}{modpath}.'/FHEM/lib'

Übrigens nutzt auch WinService.pm den Paketnamen FHEM::WinService.
@Rudi, siehst du eine Möglichkeit das in fhem.pl einzubauen?

@Martin, du kannst den INC Pfad auch über Systemvariablen steuern und an deine Umgebung anpassen. Versuch mal in ~/.profile des Nutzers, unter dem FHEM läuft, dies hier aufzunehmen:


export FHEM_DIR=/opt/fhem
export PERL5LIB=${FHEM_DIR}:${FHEM_DIR}/FHEM:${FHEM_DIR}/FHEM/lib:${FHEM_DIR}/local/lib/perl5:/usr/local/lib/perl5:$PERL5LIB







PS: @Martin
Mich würde der Use Case dahinter interessieren, weshalb man die fhem.pl separat von den anderen Dateien ablegt. Wo liegen denn dann die Config Files, im selben Verzeichnis wie fhem.cfg und kann man beim globalen configfile Attribut dann auch einen entsprechenden Pfad angeben? (ich vermute du hast deine Konfiguration nicht in /usr/bin liegen ;-)).
Wie machst du da ein Update, funktioniert der Update Befehl dann überhaupt?
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Martin Fischer am 19 März 2019, 19:35:59
Hallo Julian,

Zitat von: Loredo am 18 März 2019, 08:57:20
@Martin, du kannst den INC Pfad auch über Systemvariablen steuern und an deine Umgebung anpassen. Versuch mal in ~/.profile des Nutzers, unter dem FHEM läuft, dies hier aufzunehmen:

Danke für den Hinweis! Nun, es ist mir durchaus bekannt, dass das über environment variables möglich ist. Das wäre aber zu einfach!  ;)

Es geht hier doch eher darum, dass sich das Verhalten, wenn auch nur durch einen Zufall, seit Einsatz der Meta.pm verändert hat. Hier ist meine Bitte: Macht es so, das es kompatibel bleibt.

Die (vermeintliche) Annahme, das ich der Einzige bin, der "fhem.pl" nicht unter "/opt/fhem" liegen hat(te), mag hier vielleicht trüben:
Es gibt sogar noch ein entsprechendes init Script im contrib Verzeichnis, das "fhem.pl" unter "/usr/bin" erwartet. Auch gab es von mir einen Beitrag https://forum.fhem.de/index.php?topic=9777.0

Was der Ursprung war, mag ich heute nicht mehr nachvollziehen können. Vielleicht durch den damaligen Debian Maintainer, der versuchte FHEM aufzunehmen oder wegen LSB bzw. FHS, oder, oder, oder...

Zitat von: Loredo am 18 März 2019, 08:57:20
Mich würde der Use Case dahinter interessieren, weshalb man die fhem.pl separat von den anderen Dateien ablegt. Wo liegen denn dann die Config Files, im selben Verzeichnis wie fhem.cfg und kann man beim globalen configfile Attribut dann auch einen entsprechenden Pfad angeben? (ich vermute du hast deine Konfiguration nicht in /usr/bin liegen ;-)).
Wie machst du da ein Update, funktioniert der Update Befehl dann überhaupt?

Use Case dahinter? Nun, das mag durchaus eine philosophische Sichtweise sein, in die ich jetzt nicht abtauchen möchte. Es gab jedoch eine Zeit, da war die GUI von FHEM "Beiwerk" und da war es nicht "verpönt händisch" in der "fhem.cfg" zu editieren.  ;)

Vielleicht stammt es noch daher und in Anlehnung an FHS, das "ausführbare Befehle" oft auch dort liegen. Ich kann es heute nicht mehr nachvollziehen. Bei meinem Hauptsystem handelt es sich um ein über die Jahre gewachsenes System noch auf fhz1000 Zeiten. Da mag das eine oder andere vielleicht ein Überbleibsel sein.  ;D

Meine Konfigurationsdatei "fhem.cfg" liegt natürlich nicht in "/usr/bin" sondern in "/etc/fhem/". Und dort werden via "include" weitere Dateien aus "/etc/fhem/conf.d/" eingebunden.

Ich habe letzte Woche noch mein Startscript angepasst und "fhem.pl" startet nun aus "/opt/fhem/". Und dennoch verhält es sich, wie eingangs beschrieben. Ein "use lib '/opt/fhem';" in z.B. "99_myUtils.pm" behebt das Problem. Ich habe aus diversen privaten und zeitlichen Gründen, noch keine Möglichkeit eines Updates gehabt. Auch habe ich aktuelle (nach meinem Post) Codeänderungen nicht auf dem Schirm. Vielleicht wart ihr ja schon fleissig  ;)

Ich teile Deine Meinung, das es sinnvoll wäre, "@INC" in "fhem.pl" zu ergänzen. Zumindest sehe ich nicht, dass das was brechen würde, wenn es direkt dort landet.

Viele Grüße
Martin
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: betateilchen am 19 März 2019, 20:19:14
Bei mir gibt es auch FHEM Installationen, in denen fhem.pl ausserhalb der eigentlichen FHEM Installation liegt. Warum sollte man das auch nicht tun (dürfen) ?

Hintergrund bei mir ist, dass Teile von FHEM per nfs eingebunden sind, was aber nicht für alle Verzeichnisse von FHEM Sinn macht, insbesondere aus Performancegründen.



Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 19 März 2019, 20:59:50
ZitatWas der Ursprung war, mag ich heute nicht mehr nachvollziehen können.
Urspruenglich (4.0 bis 4.9) wurde fhem.pl nach /usr/local/bin und der Rest nach /usr/local/lib installiert.
Mit 5.0 wollte ich FHEM "deblint"-fest machen, d.h. alles nach LFS Vorgaben installieren (d.h. /usr/bin,/usr/share/lib,/var/log/fhem,/usr/share/doc,/usr/share/man,/etc)
Ab 5.3 wird (optional!) alles nach /opt/fhem geschoben, da das vieles vereinfacht, wie Backup, Systemwechsel von/nach Exoten wie FritzBox/Windows, feste Pfade in den Anleitungen, etc.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Martin Fischer am 19 März 2019, 22:50:36
Zitat von: rudolfkoenig am 19 März 2019, 20:59:50
Mit 5.0 wollte ich FHEM "deblint"-fest machen, d.h. alles nach LFS Vorgaben installieren (d.h. /usr/bin,/usr/share/lib,/var/log/fhem,/usr/share/doc,/usr/share/man,/etc)

Danke Rudi! Ich habe es nicht mehr nachvollziehen können... lag dann aber doch richtig...
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 21 März 2019, 18:27:13

Danke für eure Erläuterungen.

Zitat von: Martin Fischer am 19 März 2019, 19:35:59
Ich teile Deine Meinung, das es sinnvoll wäre, "@INC" in "fhem.pl" zu ergänzen. Zumindest sehe ich nicht, dass das was brechen würde, wenn es direkt dort landet.


Sollte ich dafür einen Patch einreichen, @Rudi?
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 21 März 2019, 18:34:37
ZitatSollte ich dafür einen Patch einreichen, @Rudi?
Ist die von allen anderen Modulen verwendete Methode ("use DevIo;") fuer Meta.pm keine Alternative?

Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 21 März 2019, 19:32:22
Wenn man Perl Packages korrekt als FHEM::package benennen möchte, wohl nicht.
Modul Autoren müssten zusätzlich vorher selbst den INC Pfad erweitern. Ich denke, damit ist der Sinn eines Packages nicht mehr gegeben.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 21 März 2019, 20:19:50
ZitatWenn man Perl Packages korrekt als FHEM::package benennen möchte, wohl nicht.
Warum ist FHEM::Meta korrekter als Meta?
FHEM:: ist konstant (NichtFhem::Meta oder FHEM2::Meta geht ja auch nicht), was wiederum denn Sinn von diesem Namenszusatz fuer mich fraglich macht. Mann kann nicht mal Meta neben FHEM::Meta haben, weil beide diesselbe Datei referenzieren.

Ich habe Angst, dass irgenwann Leute mit "use FHEM::DevIo" anfangen, und es gibt Theorien, warum das Eine besser ist, als das Andere.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 21 März 2019, 21:17:18
Das entspricht dem Standard, wenn man Perl Pakete schreibt, die in Abhängigkeit zu einem Parent Paket bzw. einer Parent Applikation stehen (fhem.pl).
Meta.pm funktioniert nicht ohne fhem.pl. Ich nahm an, dass du genau aus diesem Grund auch "./FHEM" als Verzeichnisnamen für die Pakete gewählt hast (das entspricht dem Standard). Auch dein eigenes Paket WinService.pm verwendet als Namen FHEM::WinService (und ist übrigens so ebenfalls nicht voll mit modpath kompatibel). Beide sind auch tatsächlich mit "package NAME;" deklarierte eigenständige Perl Pakete. Das ist bei anderen Dateien nicht unbedingt der Fall und zur Unterscheidung, in welchem Namespace das jeweilige Modul läuft, erscheint es mir durchaus passend, dass man "FHEM::" als Präfix hat, wenn mit einem eigenen Namespace gearbeitet wird, und keinem Präfix, wenn einfach nur der main Namespace erweitert wird.
Nicht zuletzt ist in der Abhängigkeitsliste auch viel einfacher zu erkennen, wenn es sich um eine FHEM interne Abhängigkeit handelt.


Bei FHEM Modulen, die ein FHEM Gerät sind, verstehe ich, weshalb der Dateiname anders ist und auch warum dort der Modulname keine Rolle spielt. Warum das bei echten Perl Paketen aber zwingend auch so sein soll, erschließt sich mir nicht.


Wieso soll FHEM besonders sein und sich nicht an Perl Programmierstandards halten, wenn es dafür keinen plausiblen Grund gibt? Dein Argument, jemand könnte plötzlich anfangen "use FHEM::DevIo" zu schreiben, kann ich nicht nachvollziehen. Erstens sprechen wir hier ja nicht von Benutzern, sondern von Modulautoren. Zweitens ist es überhaupt nicht schlimm, denn solange eine Moduldatei nur im selben Namespace läuft wie fhem.pl, dient der Name lediglich dazu zu beeinflussen, wie Perl nach der Moduldatei sucht. Erst wenn es sich um ein echtes Perl Package handelt, dann ist der Name relevant, da ansonsten die import() Subroutine nicht ausgeführt wird.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 21 März 2019, 21:39:29
Da ich ein großer Fan von packages bin unterstütze ich Julians Vorhaben. Die Argumentation bezüglich FHEM:: ist einleuchtend und kenne ich so auch aus dem Perl Module Bereich.
Jetzt muss man halt schauen das man dies sauber für FHEM adaptieren kann.
Werden denn bei der Umsetzung von Julians Vorschlag Inkompatibilitäten erwartet Rudi?
Ich hatte bereits 2 meiner Module auf FHEM:: umgestellt als der liebe Martin kam, bin dann erstmal wieder zurück gewichen.


Grüße
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 21 März 2019, 21:51:59
Gerade gesendet das es anscheinend immer mehr Autoren gibt welche auf packages umsteigen. Eben wurden 2 weitere Module umgestellt  ;D

Es scheint für die Entwickler ein immer interessanteres Thema zu werden.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: rudolfkoenig am 22 März 2019, 09:17:58
ZitatAuch dein eigenes Paket WinService.pm verwendet als Namen FHEM::WinService
Zur Klarstellung: das ist nicht "mein" Paket, ich habe es "as is" eingecheckt, um Windows Anwendern das Leben zu vereinfachen.

Die Argumentation bezueglich FHEM:: ist fuer mich nicht einleuchtend, es klingt nach "das machen zunemehnd mehr Leute, weil es anderswo Sinn macht".
Da aber "Kosten/Nutzen" einer Aenderung niedrig ist, habe ich modpath in fhem.pl zu @INC hinzugefuegt.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 22 März 2019, 09:59:12
Danke Dir Rudi. Dann kann ich ja im laufe der Tage meine Packagenamen wieder entsprechend an passen.


Grüße
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 22 März 2019, 20:06:24
Vielen Dank für die Unterstützung, Rudi.

Ich habe nun den FHEM Package Support auch entsprechend eingebaut.
Damit ist die Auswertung aller vorhandenen Datenquellen nun wohl soweit vollständig denke ich.

Als Modulentwickler ist es interessant, wenn man im FHEM Installer ein "Get search .+" ausführt. Vorausgesetzt man hat auch Perl::PrereqScanner::NotQuiteLite installiert, kann man nun beispielsweise sehen, welche externen Perl Module von welchem FHEM Modul oder FHEM Package verwendet werden. Das dürfte vielleicht für die zukünftige Wahl, welchen XML Parser man beispielsweise nehmen möchte, helfen, damit man nicht noch einen anderen nimmt  8)  (siehe Screenshot "xml.png").

Man sieht aber natürlich auch, welche FHEM Packages von welchen FHEM Modulen verwendet werden.
Außerdem lassen sich FHEM Packages genauso dokumentieren, wie FHEM Module.

Hier einmal eine Liste aller Infos, die die Suche berücksichtigt:

- Device Namen
- Module Namen
- Package Namen
- Keywords und die Modules/Packages, welche dieses Keyword führen (inkl. einigen generierten Standard Keywords, bspw. aus der Forum Kategorie oder der Update Quelle, aber auch dem Module Type device/command/helper)
- Maintainer Namen und die von ihnen verwalteten FHEM Modules und FHEM Packages
- Perl Packages, die von FHEM Modulen und/oder FHEM Packages verwendet werden

Interessehalber: Das hier ist wahrscheinlich eine ziemlich vollständige Liste aller externen Perl Pakete für FHEM Core:


Authen::OATH
Authen::SASL
AutoLoader
B
base
bignum
bytes
Compress::Zlib
Config
constant
Convert::Base32
Crypt::CBC
Crypt::Cipher::AES
Crypt::ECB
Crypt::Mode::CBC
Crypt::Mode::CTR
Crypt::MySQL
Crypt::OpenSSL::AES
Crypt::OTR
Crypt::Random
Crypt::Rijndael
Crypt::Rijndael_PP
Crypt::URandom
Cwd
Data::Dumper
Data::UUID
Date::Parse
DateTime
DBI
DBI::Const::GetInfoType
Devel::Size
Device::SerialPort
Device::SMBus
Device::USB
Digest::CRC
Digest::MD5
Digest::SHA
Digest::SHA1
Encode
Encode::Guess
Exporter
Fcntl
feature
File::Basename
File::Copy
File::Find
File::Path
File::Spec
File::Spec::Functions
File::stat
File::Temp
GD
GD::Text::Align
GD::Text::Wrap
Getopt::Std
HiPi::Device::I2C
HTML::Entities
HTML::Parser
HTML::TreeBuilder::XPath
HTTP::Cookies
HTTP::Request
HTTP::Request::Common
Image::Info
Image::LibRSVG
Inline
Inline::Python
IO::Compress::Gzip
IO::File
IO::Handle
IO::Interface::Simple
IO::Select
IO::Socket
IO::Socket::INET
IO::Socket::INET6
IO::Socket::Multicast
IO::Socket::Multicast6
IO::Socket::SSL
IO::Socket::Timeout
IO::Socket::UNIX
IO::Uncompress::Gunzip
IO::Uncompress::Unzip
JSON
JSON::XS
lib
Linux::Inotify2
Lirc::Client
List::MoreUtils
List::Util
longer
LWP
LWP::Simple
LWP::UserAgent
Mail::GnuPG
Mail::IMAPClient
Math::Round
Math::Trig
MIME::Base64
MIME::Lite
MIME::Parser
Mojolicious
Net::Address::IP::Local
Net::Bonjour
Net::Domain
Net::FTP
Net::FTPSSL
Net::MQTT::Message
Net::OAuth
Net::Ping
Net::SIP::Packet
Net::SMTP
Net::SMTP::SSL
Net::SNMP
Net::SSLeay
Net::Telnet
Net::UPnP::AV::MediaRenderer
Net::UPnP::AV::MediaServer
Net::UPnP::ControlPoint
Net::UPnP::Device
Net::UPnP::Service
Net::XMPP::Namespaces
Nmap::Parser
OW
Path::Tiny
perl
Perl::PrereqScanner::NotQuiteLite
PerlIO::encoding
POSIX
RiveScript
RPC::XML::Client
RPC::XML::Server
Scalar::Util
SOAP::Lite
Socket
Socket6
Storable
strict
Switch
Symbol
Sys::Hostname
Sys::Statistics::Linux::DiskUsage
Sys::Statistics::Linux::LoadAVG
Text::Balanced
Text::Diff
Text::ParseWords
Thread::Queue
threads
threads::shared
Time::HiRes
Time::Local
Time::Piece
Try::Tiny
UPnP::ControlPoint
URI::Escape
utf8
vars
version
warnings
Win32::Console
Win32::Daemon
Win32::SerialPort
WWW::Jawbone::Up
XML::LibXML
XML::Simple
XML::XPath
XML::XPath::XMLParser
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 23 März 2019, 17:14:44
Hallo Julian,

Frage zum Wiki-Eintrag. Der Installer verweist meines Wissens immer zu einem Wiki-Eintrag der ganauso heißt wie das Modul.
Das trifft zumindest bei meinen Modulen nicht so zu. Die Wiki Seiten sind ergänzt.
Kann man als Autor einen x_ Eintrag in Meta.json auf die richtige Wiki-Seite hinterlegen ?

Grüße
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 24 März 2019, 14:40:32
Zitat von: DS_Starter am 23 März 2019, 17:14:44
Frage zum Wiki-Eintrag. Der Installer verweist meines Wissens immer zu einem Wiki-Eintrag der ganauso heißt wie das Modul.
Das trifft zumindest bei meinen Modulen nicht so zu. Die Wiki Seiten sind ergänzt.
Kann man als Autor einen x_ Eintrag in Meta.json auf die richtige Wiki-Seite hinterlegen ?


Ja, sobald du in deinem META.json selbst einen Wert setzt, wird dieser nicht mehr automatisch generiert oder überschrieben.
Wie du einen Eintrag setzt, siehst du am einfachsten, wenn du in $modules{TYPE}{META} bzw. im FHEM Installer mit "Get zzModuleMETA.json" nachschaust. Im konkreten Fall für das Wiki wäre der Eintrag wie folgt:



{
"resources": {
   "x_wiki": {
     "web": "https://wiki.fhem.de/wiki/MeineWikiSeite",
     "title": "Wenn ich noch einen besonderen Titel haben möchte"
   }
}
}



'title' ist optional und bekommt, wenn gesetzt, automatisch "FHEM Wiki:" als Präfix, wenn die URL wiki.fhem.de enthält.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 24 März 2019, 14:43:31
Danke Julian, schau ich mir an.

LG,
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 24 März 2019, 18:12:47
Hi Julian,

habe x_wiki für DbRep mal ausprobiert. So definiert:


  "resources": {
    "x_wiki": {
      "web": "https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten",
      "title": "DbRep - Reporting und Management von DbLog-Datenbankinhalten"
    }
  }

Der Link im Installer verweist aber auf die Seite:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten/

was nicht funktionert. Richtig wäre wie angegeben:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten

Also ohne "/" am Ende.

Grüße,
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 24 März 2019, 19:11:12
Den Fix dafür habe ich vorhin schon eingecheckt  ;D
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 25 März 2019, 08:35:39
Moin Julian,

habe gerade upgedated. Das Wiki-Verhalten ist aber immer noch so wie in #65 beschrieben.

Grüße
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 25 März 2019, 22:30:38
Ups, hab ich offenbar nicht eingecheckt  :-[
Ist beim jetzigen Update mit dabei.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 25 März 2019, 23:13:47
Ja, jetzt sieht es gut aus ... gleich probiert  :D
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 02 April 2019, 14:59:41
Ich habe auf Anregung von André nun 2 META.json Beispieldateien unter contrib eingecheckt:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/META.json.txt (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/META.json.txt)
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/META.json.full.txt (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/META.json.full.txt)






Die erste Datei soll einen einfachen Einstieg für die Definition des JSON Baums liefern.

Sie ist darauf ausgelegt, dass ein Modul im SVN liegt und mit zusätzlichen Daten ergänzt werden soll. Man muss aber auch davon nicht alles setzen, wirklich wichtig ist nur die Sektion "prereqs" - alles andere kann im Falle eines FHEM Core Moduls auch über SVN ermittelt werden. Beim befüllen von prereqs ist im Grunde nur darauf zu achten, dass es hierbei um sämtliche "use xyz" und "require xyz" Anweisungen geht, die man im Modul an irgendeiner Stelle verwendet. Der Vollständigkeit halber dürfen das auch explizit Dinge wie "use strict" sein. 98_Installer berücksichtigt das entsprechend bei Anzeige und Auswertung. Ein Querverweis auf andere FHEM Module sollte hier nur erfolgen, wenn dieses FHEM Modul tatsächlich mit "package FHEM::modulname" arbeitet und das eigene Modul eine Funktion aus dem anderen Package aufruft. Sprich, eine rein logische Beziehung zwischen zwei FHEM Modulen soll hier explizit _nicht_ hinein, dafür überlege ich mir noch eine separate Nomenklatur (und da gibt es ja auch durchaus mehr Fälle zu dokumentieren). FHEM Packages wie HttpUtils oder DevIO gehören hier selbstverständlich hinein, ganz gleich ob dieses FHEM Package auf "package main;" oder "package packagename;" oder "package FHEM::packagename;" setzt. Entscheidend ist dabei aber, dass wie gesagt der Eintrag so lautet, wie man das Package auch bei sich über use/require einbindet. Beispielsweise ist der Querverweis auf "FHEM::Meta" korrekt, nur "Meta" jedoch nicht (Bravo, Heiko!  8) ). Ich weiß, dass der Installer dabei noch einen Link ins leere setzt, das fixe ich demnächst noch. ;D

Die Einsortierung in "requires", "recommends" und "suggests" bleibt ganz dem Modulautor überlassen. Wenn etwas woanders als in "requires" einsortiert wird, sollte das FHEM Modul natürlich so geschrieben sein, dass es auch ohne diese Perl Module klarkommt. Nicht sinnvoll ist beispielsweise, dass ein Modul zwar eigentlich ein Perl Modul wie "XML::Simple" zwingend braucht, bei fehlender Installation jedoch ein eigenes Errorhandling hat wie beispielsweise der Textausgabe "please install XML::Simple first". In diesem Fall ist XML::Simple selbstverständlich unter "requires" einzutragen. Die automatische Erkennung in Meta.pm sortiert solche Abhängigkeiten in solchen Fällen in "suggests" ein, weil eben auch erkannt wird, dass das Modul ein Errorhandling macht und es aus dieser Sicht heraus ja eigentlich funktioniert.  ;)
Eigenes Errorhandling ist in diesem Fall also eher "schlimm", zumal fhem.pl ja schon seit geraumer Zeit nicht mehr abstürzt, sondern ebenfalls die (dann etwas kryptischere) Perl Fehlermeldung ausgibt. Außerdem ist langfristig mal vorgesehen, dass Meta.pm für den Modulautor die dort aufgelisteten Perl Module automatisch läd, so dass man sie auch nicht mehr doppelt und dreifach pflegen muss (aber natürlich kann). Das soll dann gekoppelt werden können damit, dass beim "define" eben auch geprüft wird, ob alle Abhängigkeiten vorhanden sind und falls nein, angeboten wird den Installer für die Installation zu starten.
Noch Zukunftsmusik, aber soviel zur Planung.

Wer der Übersicht etwas Gutes tun möchte, der definiert noch einige zusätzliche Keywords. Sie werden bei Benutzung der Suche im Installer (oder des FHEM Befehls "search") entsprechend mit durchsucht. So kann ein Modul beispielsweise den Hersteller als Schlüsselwort mit aufnehmen und es ist dann zusätzlich darüber auffindbar. Nicht sinnvoll ist hier einen String als Keyword zu wiederholen, der bereits im Modulnamen enthalten ist, da die Suche über den Modulnamen bereits zum gleichen Ergebnis führt. Auch nicht unbedingt notwendig ist, die mit "fhem-" automatisch von Meta.pm generierten Keywords zu wiederholen. Sie werden bei im SVN dem Core zugehörigen Modulen ohnehin automatisch ermittelt. Solange wir die "legacy POD" Definitionen unter "=item [helper|device|command]" noch haben, muss man nicht unbedingt doppelt pflegen (wer aber die Meinung teilt, dass das statische JSON im File auch schon möglichst aussagekräftig sein sollte, darf das natürlich trotzdem machen  ;) ).

Die Datei META.json.txt enthält nur reines JSON, um der Einfachkeit halber auch direkt JSON Validatoren direkt anwenden zu können.






Die zweite Datei META.json.full.txt soll eine Blaupause sämtlicher möglicher Angaben sein, die man so für ein FHEM Modul (oder FHEM Entwickler-Package, natürlich) machen kann. Deshalb ist dort der gesamte "=pod ... =cut" Abschnitt mit enthalten. Er zeigt auch, wie META.json.txt sich im Gesamtkonstrukt einbindet (z.B. welche POD Definition man innerhalb der Moduldatei braucht). Ich konnte bisher kein Template für die CommandRef finden und habe daher mal versucht selbst das HTML Grundgerüst dort hinein zu schreiben. Ich habe dabei bei Modulen von Rudi gespickt und wollte eigentlich ein Template haben, was dann auch ermöglicht, dass die Beschreibung von Attributen in FHEMWEB in der Detailübersicht mit angezeigt werden kann, wenn man das Attribut ausgewählt hat. Aber irgendwie gibt es da glaube ich einen Konflikt zwischen dem Ankerpunkt für die Seitennavigation (Name ist mit # am Anfang) und der Kennzeichnung, wo die Attribut Beschreibung beginnt (Name hat kein # am Anfang, beispielsweise in der CommandRef von FHEMWEB).

Wie man an der Gesamtübersicht aller META.json Attribute gut erkennen kann, sind viele vor allem darauf ausgelegt, dass ein Modul auch nicht zu FHEM Core gehört (also nicht im SVN liegt). Aber natürlich kann es auch für ein FHEM Core Modul sinnvoll sein z.B. einen Verweis auf einen Bugtracker zu hinterlegen, wenn der Maintainer seine Todo Liste irgendwo pflegt (z.B. Github Issues, aber natürlich auch sonstwo anders). Auch der Verweis auf ein zweites Repository für die Dev-Version kann man machen (theoretisch auch auf einen separaten/neuen Branch im FHEM SVN).

Der Repository Bereich ist derzeit noch etwas mit Vorsicht zu genießen, ich bin noch nicht ganz sicher, welche Rolle bspw. x_raw (Verweis auf die Moduldatei im reinen Textformat) mal für das Update eines extern gehosteten 3rd-party FHEM Moduls spielen kann (wäre dann aber auch ein komplett separater Update Mechanismus neben dem contrib_*.txt Format, welches dann eher auf META.json setzen würde). Auch hier: Zukunftsmusik.

Vielleicht auch momentan eher von theoretischer Natur ist der Verweis auf den Support-Status (x_support_status) und die Markierung/Verlinkung eines kommerziellen FHEM Moduls (x_support_commercial). Ich habe diese Möglichkeit einfach mal vorgesehen, auch vor dem Hintergrund, dass es im Forum ja inzwischen Sektionen für kommerzielle Produkte gibt. Ein Modul kann somit ebenfalls entsprechend gekennzeichnet werden.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: nils_ am 03 April 2019, 09:41:14
Zitat von: Loredo am 02 April 2019, 14:59:41
Ich konnte bisher kein Template für die CommandRef finden und habe daher mal versucht selbst das HTML Grundgerüst dort hinein zu schreiben.
vorab: ich hab mir deine dateien nicht angeschaut  ::)

aber meinst du mit template für die cref dieses hier:
https://svn.fhem.de/trac/browser/trunk/fhem/docs/commandref_frame.html
bzw. https://svn.fhem.de/trac/browser/trunk/fhem/docs/commandref_frame_DE.html
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 03 April 2019, 10:31:20
Nee, das ist ja nur der Header.
Gemeint ist schon der Teil, der in den Moduldateien drin steht.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 03 April 2019, 23:49:14
Hallo Julian,

im DbLog-Modul braucht man unterschiedliche, Datenbank spezifische Perl-Bibliotheken, je nach dem Typ der DB die man einsetzen möchte.
Nun überlege ich wie man die Requirements hinterlegen könnte um nur den jeweils benötigten Treiber bei Installer anzuzeigen. Momentan fällt mir nichts dazu ein. Hast du eine Idee ?
Sonst müsste ich alle angeben, was aber wiederum unschön ist weil der User dann u.U. etwas nachinstalliert was er nicht braucht. Naja, wäre jetzt auch nicht so dramatisch.

LG,
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 04 April 2019, 00:57:24
Da man für das Modul mindestens einen Datenbanktyp braucht, würde ich den am häufigsten verwendeten Connector als "requires" definieren (z.B. SQLite). Vielleicht macht auch MySQL noch Sinn.
Die restlichen würde ich quasi gleichberechtigt als "recommends" hinterlegen.


Der Installer wird später ohnehin anbieten, requires + recommends zusammen zu installieren. So differenziert nach unterschiedlichen Datenbanktypen muss das IMHO wirklich nicht sein... Die 'suggests' Items wird der Installer dann wie "recommends" behandeln, wenn das Modul keine Metadaten geliefert hat und die Information über den Scanner kommt. Ansonsten wird 'suggests' nur nach explizitem User Wunsch installiert werden.
Das alles betrifft natürlich hauptsächlich die automatisierte/gescriptete Installation (z.B. im Docker Container später). Die interaktive Installation über den Browser soll flexibler sein.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 07 April 2019, 07:42:31
Danke Julien,

eine weitere Frage ist mir aufgekommen.
Es sind für DbLog auch Datenbankbinaries nötig wie sqlite3 oder mysql-server bzw. mysql-client. Macht es Sinn dies ebenfalls irgendwie mit anzugeben ?

Grüße
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 April 2019, 10:21:16
Zitat von: DS_Starter am 07 April 2019, 07:42:31
Danke Julien,

eine weitere Frage ist mir aufgekommen.
Es sind für DbLog auch Datenbankbinaries nötig wie sqlite3 oder mysql-server bzw. mysql-client. Macht es Sinn dies ebenfalls irgendwie mit anzugeben ?


Cher H*eiko  ;)


Ja, angedacht ist sowohl die Angabe von APT Paketen als auch das Vorhandensein bestimmter Binärdateien zu prüfen.
Ich bin mir noch nicht 100% sicher wie ich dabei mit redundanten Angaben umgehe, auch die Angabe von Perl Libs als Apt Pakete zusätzlich zur eigentlichen Perl Abhängigkeit ist etwas problematisch. Nicht umbedingt für die spätere Auflösung/Installation, aber vor allem für eine verständliche Darstellung. Schließlich ist es in der Regel keine "und", sondern eine "oder" Angabe. Aber wenn es dann doch mal eine "und" Angabe ist, dann weiß ich eben noch nicht, wie ich damit umgehen soll :-/


Ebenfalls angedacht ist die Angabe von notwendigen sudo Berechtigungen, File Ownerschaft (chown) und File Berechtigungen (chmod). Jedoch möchte ich zunächst einmal die reinen Perl Abhängigkeiten End-to-End fertig haben, also inkl. Installation und als ersten Use Case für die Kooperation mit einem Schwester-Modul die Auflösung der Node.js Abhängigkeiten.


Ich muss glaub ich mal den Bugtracker befüllen, um die offenen Punkte auch präsent zu haben ;)




LG
Julian
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 April 2019, 12:58:48
Hi Julian,

na da wird sich ja noch einiges tun.  ;)
Mit der Angabe vom Binaries warte ich mal bis du soweit bist um sie dann in der richtigen Art und Weise angeben zu können.

Für die Verlinkung zur DEV-Version von DbLog habe ich jetzt einen solchen Eintrag zum contrib erstellt:


  "resources": {
    "x_wiki": {
       .....
    },
    "repository": {
      "url": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter",
      "web": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter/93_DbLog.pm",
      "type": "svn"
    }
  }


Wäre das richtig so, oder würdest du es anders tun ?

LG,
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 April 2019, 13:05:55
Ich habe mir jetzt nochmal überlegt, wie man das Changelog mit integrieren kann.
Hier mal ein Vorschlag fürs Format:




  "x_changelog": {
    "2019-04-13": {
      "version": "v0.4.3",
      "release_notes": [
        ""
      ],
      "upgrade_notes": [
        ""
      ],
      "bugfixes": [
        ""
      ],
      "changes": [
        ""
      ],
      "new_features": [
        ""
      ]
    },
    "2019-04-12": {
      "version": "v0.4.2",
      "release_notes": [
        ""
      ],
      "upgrade_notes": [
        ""
      ],
      "bugfixes": [
        ""
      ],
      "changes": [
        ""
      ],
      "new_features": [
        ""
      ]
    }
  }



Als Major Key muss hier wohl das Datum her, damit die Angabe der Versionsnummer optional bleiben kann.
Angedacht ist aber, dass, wenn man die Versionsnummer im Changelog führt, die Angabe der Version als Metadata optional sein kann. Allerdings ist man dann natürlich gezwungen bei _jedem_ Update auch den Changelog zu führen. Wer das nicht möchte, könnte dann die unabhängige Versionsnummer extra pflegen. Wenn man nirgends eine Versionsnummer angibt und sich ganz auf die SVN Versionierung verlässt, ist es quasi ein kompletter Ersatz für die CHANGED Datei, nur auf Modulebene. Allerdings wertet der FHEM Update Befehl natürlich keine Metadaten aus, das wird dann nur der FHEM Installer tun. Wahrscheinlich muss man dann trotzdem noch die Infos auch in die CHANGED Datei packen, wenn man möchte, dass auch Nutzer des Update Befehls die Information sehen.


Die unterschiedlichen Kategorien sind dann alle optional, aber mindestens eine der Kategorien muss mit mindestens einem Text befüllt sein.
Dabei hatte ich - angelehnt an dem, was in CHANGED schon so getan wird - folgende Gedanken:


release_notes --> verständliche Erklärung/Zusammenfassung in Form eines Fließtextes für den User
upgrade_notes --> zusätzliche Erklärung über Implikationen von inkompatiblen Änderungen. Womöglich muss der User etwas von Hand tun und der Installer würde später wahrscheinlich verlangen, dass diese Hinweise vor dem Update/Upgrade bestätigt würden.
bugfixes --> einzelne Bugfixes; kann VCSLOG(SVNLOG) entsprechen, ist aber manuell zu pflegen und muss somit nicht so übermäßig detailliert sein (immerhin gibt es dafür ja das VCS).
changed --> Änderungen/Verbesserungen an bestehenden Funktionalitäten
new_features --> Neue Funktionalitäten




Any comments?
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 April 2019, 13:12:43
Zitat von: DS_Starter am 13 April 2019, 12:58:48
Für die Verlinkung zur DEV-Version von DbLog habe ich jetzt einen solchen Eintrag zum contrib erstellt:


  "resources": {
    "x_wiki": {
       .....
    },
    "repository": {
      "url": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter",
      "web": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter/93_DbLog.pm",
      "type": "svn"
    }
  }


Wäre das richtig so, oder würdest du es anders tun ?


Nee, damit würdest du die produktive Version anders verlinken.
Schau mal hier im META.json.full.txt Beispiel.


Bei mir nutzt das DockerImageInfo Modul diese Funktion bereits, da es mein bisher einziges komplett extern gehostetes Modul ist:
https://github.com/fhem/fhem-docker/blob/dev/src/99_DockerImageInfo.pm (https://github.com/fhem/fhem-docker/blob/e8ab165f086cd95aaa72d932f5692c6d536b0068/src/99_DockerImageInfo.pm#L260-L266)


Da hast du ein gutes Praxis Beispiel, wenn ein Modul gar keine Daten über das SVN verwaltet. Wenn man also ein im SVN verwaltetes Modul so wie deins um weitere Metadaten anreichern möchte, ist sowas ein gutes Beispiel, um sich inspirieren zu lassen.
Der FHEM Installer soll später für solche Module auch ermöglichen anzugeben, von welchem Modul man die Entwicklerversion statt der Produktivversion verwenden möchte. Noch ist aber wie gesagt noch nicht ganz raus, ob dann für das Update auf die controls_*.txt komplett verzichtet wird oder ob es noch alternativ oder gar parallel unterstützt wird... Für den Moment ist es also nur eine einfache Möglichkeit in der Modul Informationsseite anzeigen zu lassen, wo man die Entwicklerversion laden kan.

Für dich wäre also richtig:



  "resources": {
    "x_wiki": {
       .....
    },
    "repository": {
      "x_dev": {
        "type": "svn",
        "url": "https://svn.fhem.de/fhem",
        "web": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter/93_DbLog.pm",
        "x_branch": "trunk",
        "x_filepath": "fhem/contrib/DS_Starter/",
        "x_raw": "https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
      }
    }
  }


Hoffe das hilft :-)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 April 2019, 13:23:07
Ich verwende zur Zeit in fast allen von mir betreuten Modulen eine solche Struktur:


# Version History extern:
our %DbRep_vNotesExtern = (
  "8.19.0" => "04.04.2019 The \"explain\" SQL-command is possible in sqlCmd ",
  "8.18.0" => "01.04.2019 New aggregation type \"year\" ",
  "8.17.0" => "20.03.2019 With new attribute \"sqlCmdVars\" you are able to set SQL session variables or SQLite PRAGMA every time ".
              "before running a SQL-statement with sqlCmd command.",
  "8.16.0" => "17.03.2019 allow SQLite PRAGMAS leading an SQLIte SQL-Statement in sqlCmd ",
  "8.15.0" => "04.03.2019 readingsRename can now rename readings of a given (optional) device instead of all found readings specified in command ",
  "8.13.0" => "11.02.2019 executeBeforeProc / executeAfterProc is now available for sqlCmd,sumValue, maxValue, minValue, diffValue, averageValue ",
.....


Die Versionierung und den Text pflege ich bei jeder Veränderung die für den User relevant ist. Links können ebenfalls mit integriert werden.
Die Versionsnummern mappe ich dann mit einer Sub in deine Meta-Struktur beim Restart von FHEM.
Dadurch muß ich nicht jedesmal alles doppelt pflegen.

Außerdem hat der User ein "get ... versionNotes" zur Verfügung um nachschauen zu können was sich in den einzelnen Versionen geändert hat.
In dem Text nach dem Datum steht dann alles drin, Bugfixes, neue Features etc. Aus einem zweiten Hash werden noch wichtige Infos wie Links zu Online-Hilfesystemen oder RFC-Dokumentationen angeboten.

Also ich würde "x_changelog" nicht so stark aufgliedern und außerdem die "version" als führende Information nehmen und dieses außerdem als "x_version" verwenden. Dann hat man keine Mehrarbeit (und ich könnte mein Mapping weiterhin nutzen  ;) ).

Danke für das DEV-Beispiel mit META.json.full.txt, studiere ich mal ...  :)

Grüße,
Heiko
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 April 2019, 13:35:23
Zitat von: DS_Starter am 13 April 2019, 13:23:07
Danke für das DEV-Beispiel, studiere ich mal ...


Hab dir das für dein Beispiel oben noch ergänzt.


Zitat von: DS_Starter am 13 April 2019, 13:23:07
Ich verwende zur Zeit in fast allen von mir betreuten Modulen eine solche Struktur:


Ich hab mir deine Struktur auch schon angesehen, aber es fehlen halt einige Use Cases zur Kompatibilität, siehe oben. Die manuelle Angabe der Versionsnummer möchte ich nicht als zwingende Voraussetzung verankern, nur um ein Changelog zu führen. Auch die Abhängigkeit zu x_version macht gar keinen Sinn, weil x_version eine generierte Angabe ist und das auch bleiben soll. Das manuell einzutragen ist sehr fehlerträchtig und auch gar nicht möglich, weil man die SVN Revision gar nicht im Voraus gesichert eintragen kann.


Habe auch schon länger vernommen, dass du die Versionierung manipulierst - keine gute Idee und generell keine Garantie, wie üblich, ne ;-p
(beispielsweise können Reload- und Update Situationen ggf. problematisch werden).


Die Aufteilung in verschiedene Änderungs-Kategorien erscheint mir äußerst hilfreich und insbesondere die *_notes Angaben dürften - wenn sie denn dann richtig befüllt sind - viel hilfreicher für den Nutzer sein als alles andere bisher. Links zu weiteren Infoquellen halte ich - ganz ehrlich - eher für überflüssig. Das sind keine Informationen, die einen Benutzer interessieren, sondern vielmehr einen Entwickler (oder wahrscheinlich sogar nur den Modul-Author selbst, um zu einem späteren Zeitpunkt die Entwicklung nachvollziehen zu können).
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 April 2019, 13:44:28
ZitatLinks zu weiteren Infoquellen halte ich - ganz ehrlich - eher für überflüssig.
Kommt darauf an. Für die Nutzerverwaltung in der Synology Surveillance Station gibt es eine entsprechende Online-Hilfe des Herstellers. Der Nutzer sollte diese zur Verfügung haben, weil es eine wichtige Info zur Handhabung der Userrechte ist (SSCam).
Will damit sagen, so pauschal kannst du nicht einfach verneinen  ;)

ZitatHabe auch schon länger vernommen, dass du die Versionierung manipulierst - keine gute Idee und generell keine Garantie, wie üblich...
Naja, mag sein ... aber ich nutze es schon lange. Da war an ein Meta.pm noch nicht zu denken.  ;)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 April 2019, 14:05:03
Zitat von: DS_Starter am 13 April 2019, 13:44:28
Kommt darauf an. Für die Nutzerverwaltung in der Synology Surveillance Station gibt es eine entsprechende Online-Hilfe des Herstellers. Der Nutzer sollte diese zur Verfügung haben, weil es eine wichtige Info zur Handhabung der Userrechte ist (SSCam).


Ich denke du vermischt hier zwei unterschiedliche Use Cases. Bezogen auf einen einzelnen Release braucht es IMHO wahrscheinlich eher keine Links.
Die Verlinkung auf generell weiterführende Informationen wie beispielsweise Hersteller Dokumentation ist absolut sinnvoll und kann z.B. als "Homepage" als Teil des sogar offiziell spezifizierten Zweigs resources (https://metacpan.org/pod/CPAN::Meta::Spec#resources) angegeben werden. Aber natürlich ist "Homepage" streng genommen auf das FHEM Modul selbst zu beziehen, von daher könnte ich mir vorstellen, dass man noch einen x_vendor Bereich mit einführt und dann auch gesondert anzeigt (also Hersteller Homepage für die Hardware und dedizierter Doku-Link). Wäre das was?
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 April 2019, 14:13:09
ZitatIch denke du vermischt hier zwei unterschiedliche Use Cases. Bezogen auf einen einzelnen Release braucht es IMHO wahrscheinlich eher keine Links.
Gebe dir recht ... allerdings hatten wir uns diesbezüglich etwas missverstanden bzw. ich vermutlich nicht eindeutig geschrieben. Diese für den User hilfreiche Links kommen aus einem zweiten Hash und werden über ein "get ... userVersion hints" aufrufbar angeboten. Mit der eigentlichen Versionierung hat das auch bei meiner bisherigen Verwaltung nichts zu tun.

Zitat...von daher könnte ich mir vorstellen, dass man noch einen x_vendor Bereich mit einführt und dann auch gesondert anzeigt (also Hersteller Homepage für die Hardware und dedizierter Doku-Link). Wäre das was?
Klingt nicht schlecht. Meiner Meinung nach sollte es aber möglich sein nicht nur einen Link zu hinterlegen, sondern mehrere für die das Modul tangierende Themen/Infos.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 April 2019, 14:48:34

Die Frage ist, ob solch ausführliche Infos nicht eigentlich (zumindest bisher) in die commandRef gehörten?


Aber mir ist auch schon durch den Kopf gegangen, dass der eigentlich ursprüngliche Zweck der commandRef als wirkliche Referenz, wie ich die set/get Befehle nutze, Attribute setze und Readings richtig deute, verloren gegangen ist. Von daher finde ich das hier tatsächlich gut aufgehoben. Für den breiten Nutzen wäre es aber langfristig hilfreich, wenn dann auch andere Modulautoren ihre commandRef aufräumten und die Zusatzinfos an die dann dafür geschaffenen Stellen verschiebten. Ich weiß, utopisch das zu glauben, aber vielleicht gehen wir mit gutem Beispiel voran. Schließlich versuchen wir es ja hier allen möglichst leicht zu machen alle Infos über/zu ein/em Modul zentral und maschinenlesbar zu hinterlegen. Ich sehe aber schon, dass für die Wiki Doku zusätzliche Hilfe notwendig ist...  :-[
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 April 2019, 15:01:45
ZitatIch sehe aber schon, dass für die Wiki Doku zusätzliche Hilfe notwendig ist...  :-[
Für den Anfang ja, später hat man das irgendwann "gefressen"  :D

Nochmal zum Thema DEV ...
Habe deinen Hinweis soweit übernommen, aber sollte es nicht

"x_branch": "dev",

heißen statt "trunk", weil mit trunk wird der Link zum Dev-File nicht erzeugt, mit "dev" klappt das wie es soll.
Weiterhin ist mir die Bedeutung von

"url":  ....

unklar. Denn egal was ich dort eintrage, sehe ich keinen Unterschied oder Veränderung zu generierten Links etc.
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: DS_Starter am 13 April 2019, 16:23:54
@Julian, kleiner Nachtrag von weiter oben.

ZitatAuch die Abhängigkeit zu x_version macht gar keinen Sinn, weil x_version eine generierte Angabe ist und das auch bleiben soll....
Das war meinerseits natürlich Blödsinn. Was ich meinte, dass du IMHO die "version", die du auch jetzt bereits integriert hast dort verwenden solltest bzw. dann diese im changelog integrierst damit man nicht doppelt pflegen muss.
Sorry für die Verwirrung  :)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 13 April 2019, 18:26:42
Zitat von: DS_Starter am 13 April 2019, 15:01:45
sollte es nicht

"x_branch": "dev",

heißen statt "trunk", weil mit trunk wird der Link zum Dev-File nicht erzeugt, mit "dev" klappt das wie es soll.


Nee schon "trunk", weils ja wirklich darum geht, in welchem Branch das File liegt. Wenns der selbe ist wie für die produktive Version und nur in einem anderen Verzeichnis, dann ist x_branch bei beiden Angaben natürlich gleich. Hatte ich aber irgendwie in 98_Installer komisch drin - jetzt sollte es passen.


Zitat von: DS_Starter am 13 April 2019, 15:01:45
Weiterhin ist mir die Bedeutung von

"url":  ....

unklar. Denn egal was ich dort eintrage, sehe ich keinen Unterschied oder Veränderung zu generierten Links etc.



Ja, das stimmt. "url" ist offiziell spezifiziert und ist der Link, unter dem das Repository Root liegt. Das muss nichtmal https:// sein, sondern kann auch svn://, git://, svn+ssh://, git+ssh:// etc sein. Zusammen mit x_branch und x_filepath kann man dann in der Tat das File im Repository adressieren. Das ist auch der Grund, weshalb die Repository Adresse im Installer in der zweiten Zeile nur angezeigt, jedoch nicht als HTML Anker verlinkt ist. Andere Protokolle als http sind stark vom Client abhängig und die Unterschiede mit "+ssh" Zusatz können die Browser dann sowieso schon nicht mehr richtig umsetzen...

Der Installer deckt nun aber noch zwei weitere Use Cases ab, weshalb der Link für die prod und dev Webansicht nicht generiert werden kann.
Beim Use Case "Web Ansicht" kann man (je nach Tool) nicht immer die ganze URL voraussagen. Deshalb hatte ich mich der Einfachheit dazu entschlossen, dass man dafür eine komplette URL hinterlegt statt in Einzelteilen.
Ähnlich ist es auch beim zweiten Use Case "Raw/Textansicht": Da "url" ja nicht unbedingt eine Variante über HTTP/S liefern muss, ist die RAW URL auch separat. Das hat auch den Vorteil, dass man im Prinzip für das Deployment nicht zwangsläufig den VCS Server hernehmen muss (aber natürlich kann). Dedacht war ja wie gesagt auch, dass man zukünftig möglicherweise auf controls_*.txt verzichtet und direkt die Haupt-Moduldatei zieht, META.json darin auswertet und dann entscheidet, was man weiter beim Update tut (ja, eine Liste mit dazugehörigen Dateien wäre dann natürlich auch im META.json unterzubringen). die "x_raw" Einträge könnten also dann zukünftig die URLs sein, die man als Einstiegspunkt in ein FHEM 3rd-party Source Repository nimmt.

Zitat von: DS_Starter am 13 April 2019, 16:23:54
@Julian, kleiner Nachtrag von weiter oben.
Das war meinerseits natürlich Blödsinn. Was ich meinte, dass du IMHO die "version", die du auch jetzt bereits integriert hast dort verwenden solltest bzw. dann diese im changelog integrierst damit man nicht doppelt pflegen muss.
Sorry für die Verwirrung  :)


Stand auch in einem Nebensatz von mir so bereits, aber ist nicht so offensichtlich bzw. wohl zu klausuliert :-)


Zitat von: Loredo am 13 April 2019, 13:05:55
Angedacht ist aber, dass, wenn man die Versionsnummer im Changelog führt, die Angabe der Version als Metadata optional sein kann. Allerdings ist man dann natürlich gezwungen bei _jedem_ Update auch den Changelog zu führen.


Betonung liegt hier auf "optional" ;)
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: CoolTux am 23 April 2019, 08:49:22
Hallo Julian,

Die letzten Tage gab es ja einige Probleme mit Meta.pm und ganz alten Installationen. Konnte den ein oder anderen auf heute vertrösten und das funktioniert nun auch wieder.
Allerdings gibt es bei Hue noch Meldungen


2019.04.23 08:33:04 1: PERL WARNING: Argument "2.91_01" isn't numeric in numeric lt (<) at FHEM/Meta.pm line 1791.
2019.04.23 08:33:39 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/31_HUEDevice.pm line 1293.


Vielleicht magst Du da mal schauen.



Grüße
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 23 April 2019, 20:41:54
Yes - done
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Prof. Dr. Peter Henning am 11 Juli 2019, 11:54:18
Habt Ihr jetzt irgendwo eine lesbare Anleitung für die Verwendung von Meta.pm ?

LG

pah
Titel: Antw:Meta.pm: Metadaten über FHEM Module
Beitrag von: Loredo am 11 Juli 2019, 14:54:02
Hallo pah,


ich habe jetzt hier mit einem Wiki Eintrag begonnen:
https://wiki.fhem.de/wiki/Meta (https://wiki.fhem.de/wiki/Meta)


Selbiger ist auch über den FHEM Installer als Informationsquelle auffindbar. Um das hier einmal zu demonstrieren, habe ich 3 Screenshots mit angehängt.




LG zurück,
Julian