référer à des fichiers dans le répertoire "secrets" dans configuration

[gyom]

Voici une situation où on veut avoir cela dans la configuration.

    "ldap": {
        "local_private_key_file": "secrets/ldap/Google_2026_01_26_66827.key",
        "local_certificate_file": "secrets/ldap/Google_2026_01_26_66827.crt",
        "ldap_service_uri": "ldaps://ldap.google.com"
    },

Deux questions surviennent:

• La référence au répertoire "secrets" est relative, mais ça veut dire qu'il faudrait s'entendre sur une sorte de convention pour les références à des fichiers. Quel est le répertoire "racine" à partir duquel on représente les paths?
• Étant donné qu'on n'a pas ces fichiers dans la suite de test qui va rouler sur Github, c'est à se demander si on veut avoir "sarc-prod.json" en plus de "sarc-dev.json". Tant qu'à moi on peut mettre ça dans "sarc-dev.json" et simplement utiliser une version "mock" pour les tests au lieu de chercher pour les vrais fichiers, pour l'instant. Ça évite un bordel de prod-vs-dev pour l'instant.

[bouthilx]

C'est juste des paths, c'est pas les secrets en sois, mais ça fait pas très propre d'avoir ça direct dans le repo.

Ça serait plus simple à gérer si on pouvait donner 2 fichier json qui sont mergé. On pourrait avoir prod.json qui contient juste ce qu'on ne veut pas avoir dans le repo et les tests.

[breuleux]

J'aime bien l'idée de merger des configurations. Il y a le package omegaconf qui a de la fonctionnalité pour faire ça.

[gyom]

OmegaConf is a YAML based hierarchical configuration system

Je trouve que YAML c'est difficile à lire comparé à JSON. On utilise TOML dans Clockwork et YAML pour Ansible, et je ne sais plus trop quand ça prend des guillemets ou pas. J'aime mieux JSON pcq c'est la même syntaxe (ou presque) que le Python qu'on écrit à longueur de journée.

[breuleux]

Il y a des fonctions dans OmegaConf qu'on peut appeler pour merger des dictionnaires, donc c'est possible d'utiliser ça avec JSON. Ceci dit j'ai aussi des fonctions handcrafted quelque part qui feraient la job.

[gyom]

C'est le genre de chose où une fonction de 8-10 lignes fait ça, mais c'est super facile de se planter en écrivant ça mal ou testant mal.

Maxime dirait: Eille, on n'introduit pas des dépendances quand on n'en a pas besoin.

Je penche plus vers l'idée que, si on voulait faire ça, on mette quelques lignes de ton code.

[bouthilx]

La référence au répertoire "secrets" est relative, mais ça veut dire qu'il faudrait s'entendre sur une sorte de convention pour les références à des fichiers. Quel est le répertoire "racine" à partir duquel on représente les paths?
On pourrait ajouter quelque chose comme secrets_root_dir à la configuration. Sinon mettre les path absolue dans la config.

[gyom]

Tant qu'à moi c'est bien si on se définit une sorte de "root_dir" et/ou "secrets_root_dir" et qu'on exprime les paths comme partant de là. Pas besoin de mettre des "${SECRETS_ROOT_DIR}" dans les paths si c'est clair on doit utiliser quelle racine.

Ça donne quand même un argument comme quoi on serait de n'utiliser qu'une seule racine du genre, et comme ça c'est plus facile de toujours savoir qu'on doit mettre cette valeur en préfixe même quand elle n'est pas spécifiée. Pas de substitutions nécessaires.