Autor Thema: Meta.pm: Metadaten über FHEM Module  (Gelesen 4953 mal)

Offline Martin Fischer

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 1931
    • www.fischer-net.de/
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #45 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

--
Gründungsmitglied des FHEM e.V.

mehrere produktive FHEM Instanzen mit mehr als 300 aktiven Aktoren / Sensoren (1wire, FHT, FS20, HMS, Homematic, Z-Wave, IPCam, JeeLink, KS300, LaCrosse, RFXtrx,  SqueezeBox, etc.)

Online DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3806
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #46 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
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
Kaffeekasse: https://www.paypal.me/HMaaz

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3459
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #47 am: 18 März 2019, 08:57:20 »
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.

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.

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?
« Letzte Änderung: 18 März 2019, 11:12:53 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline Martin Fischer

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 1931
    • www.fischer-net.de/
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #48 am: 19 März 2019, 19:35:59 »
Hallo Julian,

@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...

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

mehrere produktive FHEM Instanzen mit mehr als 300 aktiven Aktoren / Sensoren (1wire, FHT, FS20, HMS, Homematic, Z-Wave, IPCam, JeeLink, KS300, LaCrosse, RFXtrx,  SqueezeBox, etc.)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15913
  • s/fhem\.cfg/configDB/g
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #49 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.



-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #50 am: 19 März 2019, 20:59:50 »
Zitat
Was 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.

Offline Martin Fischer

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 1931
    • www.fischer-net.de/
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #51 am: 19 März 2019, 22:50:36 »
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...
--
Gründungsmitglied des FHEM e.V.

mehrere produktive FHEM Instanzen mit mehr als 300 aktiven Aktoren / Sensoren (1wire, FHT, FS20, HMS, Homematic, Z-Wave, IPCam, JeeLink, KS300, LaCrosse, RFXtrx,  SqueezeBox, etc.)

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3459
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #52 am: 21 März 2019, 18:27:13 »

Danke für eure Erläuterungen.

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?
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #53 am: 21 März 2019, 18:34:37 »
Zitat
Sollte ich dafür einen Patch einreichen, @Rudi?
Ist die von allen anderen Modulen verwendete Methode ("use DevIo;") fuer Meta.pm keine Alternative?


Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3459
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #54 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.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #55 am: 21 März 2019, 20:19:50 »
Zitat
Wenn 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.

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3459
  • ~ Challenging Innovation ~
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #56 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.
« Letzte Änderung: 21 März 2019, 21:33:18 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1
Zustimmung Zustimmung x 2 Liste anzeigen

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20245
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #57 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
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.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20245
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #58 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.
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.me/MOldenburg
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:Meta.pm: Metadaten über FHEM Module
« Antwort #59 am: 22 März 2019, 09:17:58 »
Zitat
Auch 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.

 

decade-submarginal