Das deutsche Python-Forum

@Sirius3: Ich habe mir eben einige Konfigurationsdateien angeschaut. Dort findet man keine Kommentare. Im Grunde hat auch ein Anwender dort auch nichts zu suchen. Experten trauen sich an solche Dateien, aber im Grunde lässt man die Finger davon. Von daher bräuchte man keine Kommentare, wie ich finde, Aber nochmal zurück: Ich als Anwender kriege erstens sowieso nichts mit, was unter der Haube abläuft. Interessiert auch die wenigstens. Um Missverständnis vorzubeugen: Mir geht es nicht darum, zu argumentieren "Mache ich was ich will." Nein, was ich nur meine, ist, solange alles wie beim Alten bleibt, und die Konfigurationsdatei nur aktualisiert wurde, sind alle Anwender zufrieden. Ich schau als Anwender auch nicht jedesmal in die diese Datei nach, sobald eine neue Version eingespielt wurde. Ich versuche gerade nur dieses "Ärgernis" nachzuvollziehen. Früher oder später werden die neuen Optionen sowieso in die INI-Datei geschrieben, sobald der Anwender sich von den neuen Einstellmöglichkeiten gebraucht macht. Ob sie Optionen und Section erst DANN geschrieben werden oder schon im VORFELD eingeschrieben werden. Ich will keineswegs "rebellisch" wirken, aber ich als Anwender sehe nun keinen Unterschied.

@Sophus: Experten brauchen auch keine Konfigurationsdateien. Sie ändern einfach den Source Code.

@Sophus: Dann verwendest du kein Linux. Natürlich kann es Konfigurationsdateien geben an denen der Benutzer üblicherweise nichts zu suchen hat, aber unter Linux läuft vieles über Konfigurationsdateien (Nginx, Apache, Tor, Fail2Ban, Pacman, rc.conf, ...).

@Dav1d: Aber selbst unter Linux ist dann immer Vorsicht geboten. Ich weiß nicht mehr in welchem Zusammenhang ich das mal las. Aber als ich etwas in der INI-Datei ändern wollte, meine ich zu glauben, gelesen zu haben, dass man am besten die Finger lassen soll. So nach dem Leitsatz: "Schuster bleib bei deinen Leisten".

@Sophus: Wozu sind die Dateien denn sonst da wenn man die Finger davon lassen soll? Wenn man einen Dienst konfigurieren will *muss* man die entsprechende(n) Datei(en) ändern. Für einige Programme gibt es grafische Front-Ends, aber da sind dann nicht immer alle Einstellungen abgebildet oder man ist in den Möglichkeiten gegenüber Konfigurationsdateien eingeschränkt.

@BlackJack: Korrekt. ich sage ja nicht, dass man die Dateien nicht anrühren soll - nur eben mit Bedacht. Man sollte also schon wissen was man da macht. Aber auf der Windows-Plattform werden die INI-Dateien überwiegend über die grafische Benutzeroberfläche modifiziert. In seltensten Fälle muss man manuell die Dateien bearbeiten. Die meisten Anwender haben sowieso keine Ahnung oder keine Lust, manuell die Dateien zu ändern. Aber diese Angelegenheit lässt sich noch verschärfen. Es gibt durchaus Anwendungen, die ihre Einstellungsdateien "verunstalten", so dass die Datei für ein menschliches Auge nicht mehr "lesbar" ist. In diesem Fall möchte dann der Entwickler gar nicht erst, dass man dort als Anwender "herumspielt".

Textbasierte Konfigurationsdateien sind ein UI. In einigen Fällen das einzige UI. Gleichzeitig können sie sehr schnell so komplex werden dass Kommentare sinnvoll oder sogar erforderlich sind.

Wenn du an einer Anwendung arbeitest bei der dies nicht der Fall sein soll, biete dieses UI nicht an und speichere deine Einstellungen einfach in einem binär Format ab. Das spart dir auch einiges an Aufwand beim Support.

@DasIch: unverschönertes JSON lädt auch schon nicht zum Editieren ein und ist ein passendes und einfach zu verwendendes Format.

@Sirius3: Das Arbeiten mit JSON ist mir noch nicht vertraut. Aber mir geht es auch nicht darum die Konfigurationsdatei zu verunstalten. Die Ausgangssituation war ja, dass angemerkt wurde, dass Anwender (ich schreibe mal mit Absicht in Konjunktiv) "verärgert" seien, sobald eine neue Programmversion ohne weiteres eine Konfigurationsdatei aktualisiert. Für mich war es insofern nicht nachvollziehbar, da diese Datei sowieso im Laufe der Zeit geändert wird. Wir gehen davon aus, dass Anwender sich von neuen Einstellungsmöglichkeiten früher oder später Gebrauch machen werden. Ergo: Ist es Jacke wie Hose, ob man eine Konfigurationsdatei erst DANN aktualisiert, wenn der Benutzer sich an neuen Einstellungsmöglichkeiten bedient oder ob man schon im VORFELD aktualisiert. Ich betrachte das aus Sicht des Anwenders - schließlich bin ich ja selbst Anwender. Wenn ein Entwickler aber dazu übergeht eine Konfigurationsdatei zu "verunstalten", sollte er/sie sich nicht wundern, wenn man als Anwender skeptisch wird, sobald das auffällt.

Sophus hat geschrieben:Für mich war es insofern nicht nachvollziehbar, da diese Datei sowieso im Laufe der Zeit geändert wird. Wir gehen davon aus, dass Anwender sich von neuen Einstellungsmöglichkeiten früher oder später Gebrauch machen werden.

Anwender ändern Konfigurationsdateien. Konfigurationsdateien werden ansonsten nie geändert außer vielleicht von Package Managern die sehr nett nachfragen und eine Option bieten etwas anderes zu tun.

Im Zweifel kann deine Anwendung die Konfigurationsdatei auch gar nicht ändern weil sie die notwendigen Rechte gar nicht hat.

@DasIch: Ich hatte ja auch vor, dass der Anwender mittels der Messagebox informiert wird, dass die Konfigurationsdatei veraltet ist und somit aktualisiert wird. Natürlich ohne die Option wie: Ja, Nein Vielleicht.

@Sophus: nur dass dieses Erweitern der Konfigdatei weder dem Programm noch dem Anwender irgendeinen Vorteil bietet. Der Anwender ärgert sich im günstigsten Fall und das Programm wird dadurch nur unnötig komplex (YAGNI).

@Sirius3: Interessant. Ich muss gestehen, dass ich bisher - aus Sicht als Anwender - nie soweit gedacht habe. Würde ich in meiner Messagebox die Option offen lassen, dass dem Anwender die Möglichkeit einräumt, sich mit "Nein" entgegen zu entscheiden - also dass die Config-Datei nicht aktualisiert werden soll. Dann müsste diese Entscheidung ja in eine INI-Datei hinterlegt werden, damit mein Programm dem Anwender nicht bei jedem Start mit der Meldung nervt. Das würde ja dann bedeuten, sobald die Entscheidung des Anwenders gespeichert wird, könnte man gleich in diesem Zuge sowieso aktualisieren. Denn die Entscheidung muss ja eh hinterlegt werden. Mit anderem Worten "Alles in einem Rutsch erledigen."

Aber seien wir mal ehrlich. Interessiert das dem Anwender überhaupt? Bitte dabei nicht systemnah denken, also nicht wie ein Entwickler denken. Der Anwender ist doch heilfroh, wenn das Programm funktioniert und das tut, was er sich wünscht. Denn ich als Autofahrer mache auch nicht die Motorhaube auf, und schaue mal nach, ob alles seinen Gang geht. Wenn mein Auto fährt, bin ich froh darüber. Wenn nicht, dann kommt es in die Werkstatt. Und so denke ich auch beim Programm. Vielleicht habe ich auch eine falsche Sicht?

Den Anwender interessiert es natuerlich, es sind ja seine Entscheidungen die da drin stehen. Wenn du die mit der Default-Konfiguration ueberschreibst, dann verliert er seine.
Und selbst wenn du seine alte irgendwohin sicherst, dann kann es passieren, dass er das nicht merkt und dann wieder den Default benutzt. Auch wenn du ihn es ins Gesicht schreist, muss er das ja nicht realisieren, dass er dann etwas tun muss. Dann gibt es auch noch den Fall, dass der Anwender gar nicht der Administrator ist und gar nicht dein Programm eingerichtet hat.

Kurzum, jeder verliert, wenn du eine Konfiguration aktualisierst, denn was du hinzufuegen kannst, wuerde ja sowieso der Default sein und sollte damit akiv sein, wenn die Konfiguration dem nicht widerspricht.

@cofi: Das mit den Administratorrechten verstehe ich nicht ganz. Ich will meine Anwendung in einer Setup-Routine ausliefern, also so wie man es unter Windows üblicherweise kennt. Mein Programm soll man einfach ganz normal entpacken und gleich benutzen können - ohne Installation. Demzufolge liegt dann das Programm auf das entsprechende Benutzerkonto. Und die INI-Datei schwirrt auch nicht im Programm(x86)-Ordner. Ich denke, auf diese Weise werde ich mit den Rechten nicht in eine Verlegenheit kommen? Und zu den "Überschreiben". Also DAS wäre ärgerlich, wenn eine neue Programmversion meine alten Einstellungen einfach überschreibt. Genau das will ich nicht. Es werden nur fehlende Sections und Options hinzugefügt - nicht mehr und nicht weniger.