Modifier la gestion de la config #38

New Issue

Closed

opened 2019-12-05 00:16:32 +01:00 by Darks · 4 comments

Darks commented

2019-12-05 00:16:32 +01:00

Owner

Actuellement c'est le dawa.

On a un objet de configuration classique, chargé dans app.config.
On a un autre objet, V5Config qu'on importe à chaque fois qu'on en a besoin.
On a des variables à l'arrache dans local_config.py

Ce que je propose :

Passer toute la config globale dans app.config. Je sais plus pourquoi on avait fait comme ça, mais ça me paraît être peu adapté.
Soit passer la config locale dans un objet de app (app.l_config par exemple), soit l'ajouter au chargement de l'app dans app.config.

Le but étant de tout avoir au même endroit, parce que l'appli étant la v5, la config de la v5 c'est la config de l'appli.

Je peux me charger de faire toutes ces modifications.

Actuellement c'est le dawa. - On a un objet de configuration classique, chargé dans `app.config`. - On a un autre objet, `V5Config` qu'on importe à chaque fois qu'on en a besoin. - On a des variables à l'arrache dans `local_config.py` Ce que je propose : - Passer toute la config globale dans `app.config`. Je sais plus pourquoi on avait fait comme ça, mais ça me paraît être peu adapté. - Soit passer la config locale dans un objet de `app` (`app.l_config` par exemple), soit l'ajouter au chargement de l'app dans `app.config`. Le but étant de tout avoir au même endroit, parce que l'appli étant la v5, la config de la v5 c'est la config de l'appli. Je peux me charger de faire toutes ces modifications.

Darks added the

proposal

label 2019-12-05 00:26:52 +01:00

Lephenixnoir commented

2019-12-05 08:35:58 +01:00

Owner

Pas d'objections, à condition que la gestion de la config locale se passe bien sur le Git. C'est pour ça qu'on a séparé en deux fichiers actuellement.

Eragon commented

2019-12-05 14:43:04 +01:00

Member

Ok, mais il faut garder à l'esprit que local_config.py contient les variables à ne pas partager(d’où son nom) il me semble donc normal de le garder.

Cependant mettre toute la conf au même endroit est une bonne idée.

Ok, mais il faut garder à l'esprit que `local_config.py` contient les variables à ne pas partager(d’où son nom) il me semble donc normal de le garder. Cependant mettre toute la conf au même endroit est une bonne idée.

Darks commented

2019-12-05 22:50:38 +01:00

Author

Owner

C'est là que l'héritage intervient.

# local_config.py
class LocalConfig():
    SOME_PROPS = 42

# config.py
from local_config import LocalConfig

class Config(LocalConfig):
    MORE_PROPS = "53cr37_7ok3n"

C'est là que l'héritage intervient. ``` # local_config.py class LocalConfig(): SOME_PROPS = 42 # config.py from local_config import LocalConfig class Config(LocalConfig): MORE_PROPS = "53cr37_7ok3n" ```

Darks commented

2019-12-05 23:00:37 +01:00

Author

Owner

Bon en fait je sais pourquoi on avait pas fait comme ça.

Do not write code that needs the configuration at import time.

Sauf que dans la déclaration des modèles, on a besoin de config. Donc finalement on va rester sur le modèle app.config et V5Config, mais en ajoutant l'héritage pour retirer une troisième couche de config.

Bon en fait je sais pourquoi on avait pas fait comme ça. > Do not write code that needs the configuration at import time. Sauf que dans la déclaration des modèles, on a besoin de config. Donc finalement on va rester sur le modèle `app.config` et `V5Config`, mais en ajoutant l'héritage pour retirer une troisième couche de config.

Darks referenced this issue from a commit

2019-12-05 23:09:02 +01:00

Premier passage à la configuration unifiée (#38)

Darks referenced this issue from a commit

2019-12-05 23:09:02 +01:00

Stage 2 pour le changement de config (#38)

Darks closed this issue

2019-12-05 23:11:49 +01:00