Nouvelles variables / variables non-existentes dans defs.py
Depuis !813 (merged) :
Est-ce qu'il ne faudrait pas aussi qu'on vérifie (aussi) l'existence de la variable ? Cela éviterait les erreurs serveurs pour les installations courantes qui ne la renseignerait pas.
Je me suis aussi posé la question... comme pour toutes les modifications que l'on a fait à
defs.py
. Pour l'instant on n'a jamais fait cela, voir récemment !666 (merged).
Garder la compatibilité peut mettre de la dette technique à la fois sur le code... mais surtout sur les
defs.py
des serveurs déployés : cela peut garder l'illusion que l'on peut ne pas mettre à jour et remettre à "plus tard' une détection de bug de configuration, alors que si on a "bientôt" un soucis dans une configuration cela reste frais.
Je préfère donc mettre beware-migration et qu'on soit plus rigoureux avec #4482 (et cette MR inclut dans ce sens e3b282d5).
Pour l'instant on n'a jamais fait cela, voir récemment !666 (merged).
Je disconviens : 04048ecb ;)
Dans certains cas cela se justifie, par exemple pour les emails on a besoin de connaître les informations ou pour définir les sets, patients, runs mais je pense que ça ne devrait pas être systématique.
Dans certains cas on s'est déjà retrouvé (ou des utilisateurs) avec des erreurs serveurs parce que certaines variables n'étaient pas définies alors que ce n'est pas bloquant pour utiliser le serveur (par exemple avec
DIR_PEAR
).
Et là on met le poids sur les utilisateurs qui doivent mettre à jour leurs
defs.py
pour ne pas se retrouver avec une erreur serveur.
@duez parle aussi de
DIR_PEAR
, et "ce n'est pas normal, on devrait avoir un mécanisme qui fait que tout variable non définie aie une valeur par défaut"
@duez : "on pourrait loader le
defs.py.sample
, puis ledefs.py
, pour que toutes les variables aient une telle valeur par défaut"