Perlmodul als Configfile automatisch schreiben

[Beat]

Irgendwann wird jemand die Konfiguration manuell ändern müssen, da ist dann ein bekanntes, einfaches Format meistens weniger anfällig als ein Modul, das als Perl-Code geparst wird.

Nein, für die Userkonfiguration soll es eine GUI geben.
Damit ich diese aber darstellen kann, muss das Script eine Basiskonfiguration bereitstellen.

Da ist also kein Problem mit dem Perlcode, denn nur Perl sieht ihn.

Ist es nun notwendig, dass eine Basiskonfiguration erstellt wird [1]
( dazu gehören
  --erfasse das verfügbare Filesystem, und die Files
  --erfasse eine eventuell vorliegende Userkonfiguration
)
... so soll eine Scriptroutine das Perlmodul schreiben.
Das setzt voraus, dass ich natürlich das Modul als print Text beschreiben
kann, während es via use eingebunden ist.

Das geht problemlos. use X ist equivalent zu BEGIN { require X; X->import(); }, wobei require die Datei auf einen Schlag einliest. Wenn das Modul dann abgearbeitet wird, ist die Datei beschreibbar.

Ich habe jetzt den ersten Test durch:
Lade das Modul mit use, lies dann aber in einer Routine unten den Content ein, und schreibe ihn wieder in die pm Datei. Soweit ok. Also das Verfahren sollte problemlos möglich sein.

Beim nächsten Script-Run würde dann aus dem Modul ein aktualisierter Hash eingelesen, der die aktualiserte gültige Konfiguration darstellt.

Warum so umständlich?

Starte das Script, suche nach Updates, installiere Updates, aktualisiere die Konfiguration, starte die eigentlich angeforderte Aufgabe. Das geht in einem Programmlauf.

...Elend langsam. Das machst du nicht bei einer komplexeren Anwendung für jeden HTTP Request.

Updates gibt es verschiedener Art:
Softwareupdates (selten)
Userdataupdates (wohl häufig)
Aber in der Regel kann aus einer konstanten Konfiguration bedient werden, die eben möglichst geradlinig Perl bereitstehen soll.

Bei jedem Scriptrun ein nicht optimiertes Format, egal welcher Art einzulesen, ist eindeutig ein NoGo.

Wenn Du eine Grundkonfiguration und eine User-Konfiguration haben willst, benutze zwei Konfigurationsdateien: Eine, sagen wir mal system.ini, fängt mit der dicken fetten Warnung an, in der Datei nicht herumzupfuschen, die zweite, user.ini, ist anfänglich leer. Die system.ini wird zuerst gelesen und legt die Defaults fest, die user.ini überschreibt dann die selbe Datenstruktur mit den Werten, die der User gerne hätte. Updates manipulieren dann nur die system.ini. (Außer bei wirklich üblen Fehlerfällen, wo ein Eintrag aus der user.ini gelöscht werden muß.)

Wie gesagt. alles woran man nicht rumfuchteln darf ist derzeit
<quote>
1;

</quote>
Dieses mit Sinn zu füllen soll nicht bei jedem Run, sondern nach Updates, Inhaltsaktualisierungen durch den Admin geschehen, via Push-Button

Wenn Du ohnehin eine SQL-DB benutzt, kannst Du die Konfiguration natürlich auch in eine DB-Tabelle schreiben, und Du brauchst nur eine Mini-Datei, die die Verbindung zur DB beschreibt (DBI-Connect-String, User-Name, Passwort).

Warum das wichtige in Datenbanken verstecken, um es dann drei/viermal umzuformen?
Ich verfolge eine Absicht wenn ich die notwendige Konfiguration in ein .pm stecken will.

Das was ich eventuell in mein eigenes Datenbank System speichere, sind die Konfigurationsabschnitte für den Admin, für die Bearbeitung, GUI, Helpfiles etc...

mfg Beat