Feature/#41 user config #42
Conversation
|
|
||
| _write_config(default_settings, DEFAULT_SETTINGS_FILE) | ||
| logger.info( | ||
| "Settings file was created. Path: %s.", DEFAULT_SETTINGS_FILE |
There was a problem hiding this comment.
Guter catch, tatsächlich auch ne Linter Warnung aber sehr speziell. Ich hatte davor f-string und man bekommt den Hinweis, hier explizit das alte %-printf Format zu nutzen weil das lazy ist. Der Hintergrund ist, das logger. im Verleich zu print nicht immer ausgeführt wird, weil es vom LOG-LEVEL abhängt, das der user selbst bestimmen kann, indem er setLevel aufruft. Ein f-string wird jedoch immer ausgewertet, auch wenn die eigentliche Log-Nachricht gar nicht abgeschickt wird. Daher soll man bei logger tatsächlich wohl %-Format verwenden, da hier der String so an die Funktion geht und in der Funktion erst zusammengebaut wird.
| @@ -31,3 +30,10 @@ target-version = ['py39'] | |||
| [build-system] | |||
| build-backend = "poetry.core.masonry.api" | |||
| requires = ["poetry-core>=1.0.0"] | |||
|
|
|||
| [tool.pytest.ini_options] | |||
There was a problem hiding this comment.
das musst mir mal am Dienstag genauer erklären :-)
There was a problem hiding this comment.
sind Startoptionen für pytest. Die pyproject.toml ist ja die "neueste" zentrale Konfig für Python-projekte und gilt für so ziemlich alle Tools, sofern sie das neue File-Format unterstützen. Also Tools wie black, pylint etc. können auch hierüber konfiguriert werden, ich finde nur meist die alten Dateien einfacher zu lesen bzw. kenne da die Syntax oder man findet mehr Beispiele. Hier bewirkt "-s", dass auch print-Messages mit ausgegeben werden, ich starte also pytest quasi immer mit "pytest -s", damit ich auch die print-messages angezeigt bekomme, ist einfacher als immer die Tests per DebugModus auszuführen. Und -v ist für eine erhöhte Verbosität
implement a user config using configparser module upload created doc as artifact update module docstring
pmayd
force-pushed
the
feature/#41-user-config
branch
from
2f9bebe
to
a7a474a
Compare
Größerer PR, der eine user config einführt und die
.envdamit ablöst. Umstieg auf ConfigParser, damit keine dependency zupython-dotevnmehr.Zahlt ein auf #41
Im Detail:
import pygenesiswird einesettings.iniin~/.pygenesisangelegt. Diese brauchen wir, um den tatsächlichen Konfigpfad abzuspeichern. Der User kann selbst entscheiden, wo die eigentliche Config liegen soll, aber genau diese Entscheidung muss irgendwo festgehalten werden, persistent, auch nach Programmendesettings.inigibt es ein Keyconfig_dir, das per default auf~/.pygenesiszeigt.config.iniim Ordnerconfig_dirsein, auf die der Key insettings.inizeigt. Für neue Benutzer ist das noch nicht der Fall, daher kommt es beim Import vonpygenesis.cubebzw. beim Laden der config viapygenesis.config.load_configzu einem Fehler:Could not find <config>. Please make sure to run init_config() first.`init_config()ausführen, das habe ich inpygenesisdirekt verfügbar gemacht, siehe auch mein Notebook.init_config()ohne Argumente legt eine default config im config_dir an. Alternativ kann der Benutzer seinen eigenen Pfad angeben. Der Benutzer wird darauf hingewiesen, dass er noch Username und Password ergänzen muss.config.iniangelegt ist, kannload_config()zum Laden verwendet werden, siehecube.pyfür ein Beispiel. Wenn der Benutzer aber vergessen hat, seine credentials einzugeben, kommt erneut ein Logger Critical error:Username and/or password are missing!config.iniablegen. Danach ist er good to go und kannload_config()nutzen.TL;DR:
from pygenesis import init_configausführen undinit_config()mit oder ohne Pfad aufrufen, das erzeugt dann eineconfig.iniam angegebenen Pfad, default in~/.pygenesisconfig.iniUsername und Password eintragenfrom pygenesis.config import load_config(könnte auch noch in den root namespace).