Meta.pm: Metadaten über FHEM Module

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

Vorheriges Thema - Nächstes Thema

Martin Fischer

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

--
Admin, Developer, Gründungsmitglied des FHEM e.V.

DS_Starter

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

Loredo

#47
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?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

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

Martin Fischer

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
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

betateilchen

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.



-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

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.

Martin Fischer

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...
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

Loredo


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?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

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

rudolfkoenig

ZitatSollte ich dafür einen Patch einreichen, @Rudi?
Ist die von allen anderen Modulen verwendete Methode ("use DevIo;") fuer Meta.pm keine Alternative?


Loredo

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.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

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

rudolfkoenig

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.

Loredo

#56
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.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

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

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

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.