#38 Modifier la gestion de la config

Closed
opened 2 months ago by Darks · 4 comments
Darks commented 2 months ago

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 2 months ago
Lephenixnoir commented 2 months ago
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.

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 2 months ago
Collaborator

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 2 months ago
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 2 months ago
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.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.