fix: migrate poetry.lock, pyproject & tox at root after folder redesign

BLOOM_CONFIG.txt

@@ -0,0 +1,19 @@
+
+De mon côté, je voulais mettre en place mon mécanisme de gestion des configurations qui me permet d'avoir une seule config pour du déploiement natif et de la surcharger à la marge directement dans le docker-compose pour du déploiement Docker et je n'y arrivais pas. @Samuel Enguehard a émis ce besoin pour pouvoir lancer en natif et utiliser les outils de débogage intégré à l'éditeur graphique j'imagine, ce qui est quand même bcp plus confort, mais de mon côté je l'utilise tous les jours et je trouve ça vraiment pratique d'avoir une seule conf sans se poser de question si c'est du natif ou du docker.
+
+Au final j'ai trouvé pourquoi, c'est parce que le mécanisme de chargement automatique du fichier .env activé dans docker-compose est prioritaire sur les sections "environment:" décrites dans le fichier docker-compose.yaml et vient donc écraser les valeurs qui ont pu être mises dans le fichier (je l'utilise par exemple pour forcer la valeur POSTGRES_HOSTNAME|PORT:postgres:5432 dans le fichier docker-compose peu importe la valeur du fichier .env initial mais avec ce mécanisme, c'est la valeur du .env qui mise systématiquement. Du coup quand on passe du natif à docker on est quand même obligé de venir modifier la valeur des paramètres dans le fichier de .env POSTGRES_HOST/PORT mais aussi mettre des chemins typé "Docker" pour les secrets: /run/secrets/postgres_password au lieu POSTGRES_PASSWORD_FILE=./secrets/postges_password quand on passe de l'un à l'autre... c'est un peu dommage mais soit
+Ca devient donc impossible d'avoir une conf native par fichier+surcharge Docker au niveau du docker compose au sein des ces sections "environment"
+
+Bref ça me rappelle pourquoi je n'utilise jamais le chargement .env par défaut de docker-compose autant pour le dev mais surtout pour le déploiement en compose, c'est pas flexible (https://docs.docker.com/compose/environment-variables/envvars-precedence/)
+
+De ce fait on en arrive à privilégier un déploiement des paramètres par variable d'environnement et non pas par fichier au niveau d'application (comme certain préféraient dans nos discussions) puisque c'est le mode un peu forcé si on utilise le chargement des fichiers .env de docker-compose et que c'est préférable que le fonctionnement de l'application soit équivalent en natif comme en Docker.
+Perso, dans tous mes projets, je mets en place un chargement hybride des settings par fichier + env avec priorité pour l'env (standard Docker mais c'est hyper pratique) donc je fais les deux mais de manière maitrisée, mais l'idée là est juste qu'on se fixe officiellement pour le projet bloom, c'est pour ça que je voulais savoir si au final ce sera déployé en natif ou en Docker pour valider que c'était pratique sur toute la chaine et non pas que pour les développeurs
+
+Pour ce qui est de la flexibilité pour lancer en natif @Samuel Enguehard, pour ceux qui alternent natif/docker ou ceux qui alternent dev/test/prod/... j'aurais une proposition qui n'impacte pas le fonctionnement par défaut utilisant le .env et docker-compose:
+on utilise une variable (optionnelle) d'environnement BLOOM_CONFIG=.env.dev par exemple (.env par défaut) (qui peut d'ailleurs se trouver hors du dépôt Git dans ce cas, ce qui est très utile dans le cas des déploiement automatisés Docker comme natif avec une conf locale au serveur en dehors du dossier gitlab/github
+Dans cette solution il suffit d'exporter la variable COMPOSE_ENV_FILES qui précise le nom du fichier par environnement à charger (par défaut c'est bien .env) et lui donner la valeur de BLOOM_CONFIG à savoir " export COMPOSE_ENV_FILES=${BLOOM_CONFIG}" sous Linux et set COMPOSE_ENV_FILES=%BLOOM_CONFIG% sous windows et de faire simplement
+export BLOOM_CONFIG=.env.dev ;
+puis, pour Docker: docker compose up (il prend automatiquement la valeur COMPOSE_ENV_FILES qui est égale à la valeur de BLOOM_CONFIG
+puis, pour du natif charge à l'application d'aller chercher les valeurs du fichier BLOOM_CONFIG si cette variable est définie, sinon on charge le .env par défaut (=> évolution de bloom.config)
+Dans les deux cas Docker/Natif, bloom.config doit charger le fichier BLOOM_CONFIG si présent sinon .env, puis surcharger les éventuelles valeurs qui seraient aussi présentes dans les variables d'environnement
+Je précise que ce mécanisme apporte de la flexibilité pour ceux qui alternent entre natif et docker (il suffit de faire BLOOM_CONFIG=.env.docker et BLOOM_CONFIG=.env.local) et en vue des contraintes de déploiement natif/Docker (BLOOM_CONFIG=/my/secured/folder/.env.prod), cependant pour les développeurs qui utilisent toujours le même environnement, il suffit de laisser la config par défaut (.env) sans modifier la valeur COMPOSE_ENV_FILES et/ou exporter BLOOM_CONFIG, ça utilisera le .env partout comme actuellement