Procédure de MAJ du module et migrations Alembic

[camillemonchicourt]

Actuellement, on utilise la procédure classique GeoNature de mise à jour du module : https://github.com/PnX-SI/gn_modulator?tab=readme-ov-file#mise-%C3%A0-jour
Celle-ci consiste à télécharger la nouvelle version du module et relancer son installation.
Mais du coup quand on renomme l'ancien dossier de Modulator et le nouveau, on perd le lien symbolique des sous-modules de Modulator qui sont dans son ancien dossier.
Si les sous-modules comprennent des migrations Alembic à lancer lors de la mise à jour de Modulator (geonature install-gn-module ~/gn_modulator MODULATOR) alors il ne trouvera pas les branches du sous-module et renverra une erreur du trype : alembic.util.exc.CommandError: Can't locate revision identified by 'b7eb2e900bf1'.

Cela est contournable en lançant l'installation des sous-modules (après la MAJ de Modulator qui a fini en erreur sur les migrations de BDD) : geonature modulator install -p <chemin vers le sous-module> puis de relancer les migrations Alembic : geonature db autoupgrade

Idem si on met à jour GeoNature en même temps que Modulator avec la procédure classique où on renomme les dossiers des modules puis lance le script migrate.sh.

Pour palier à cela :

• Installer Modulator en git, pour ne pas renommer les dossiers à chaque mise à jour
• Sortir le dossier des sous-modules du dossier de Modulator pour ne pas casser les chemins vers les sous-modules à chaque mise à jour (et renommage des dossiers) de Modulator. En même temps, sortir les exemples de sous-module du dépôt Modulator (SIPAF, etc...) vers un dépôt spécifique pour faciliter leur gestion dans un dossier à part et leur donner un cycle de releases indépendant de Modulator