Évolution du chargement des modules GeoNature

[bouttier]

Le packaging des modules GeoNature permet notamment :

• d’indiquer la version de GeoNature requise
• d’éviter les chemins d’import relatif à plusieurs points
• d’effectuer des imports depuis un autre module

Le mécanisme d’import des modules par GeoNature actuellement repose sur des chemins bien connu à la racine du module. Ceci est peu souple et ne permet pas le packaging où les sources sont généralement dans un dossier « src/{nom du module} ».

L’objectif de cet ticket est donc de faire évoluer le mécanisme d’import des modules par GeoNature afin de pouvoir importer des modules packagés. L’idée est la suivante :

• Rétro-compatibilité avec les modules v1

• Import du blueprint et du schéma de configuration à partir d’indication d’entry point dans le setup.py du module

• Import d’un module packagé

  • Blueprint
  • Schéma de configuration
  • Sous-commandes geonature fournies par le module

• Mise-à-jour de la documentation

• Mise-à-jour du template

[camillemonchicourt]

Si cela impacte la structure ou la documentation des modules, il faut peut-être adapter le template de module fourni dans un dépôt dédié ?

[bouttier]

J’ai commencé une liste des choses à faire, en y précisant ces points.

[bouttier]

Support des modules packagés dans ces commits :

• 8fefbc6
• d4fc5df
• a7cdeaf (alembic)

Un module packagé doit définir un certains nombres d’entry point, exemple pour le module d’import (en cours de dev) :

    entry_points={
        'gn_module': [
            'code = gn_module_import:MODULE_CODE',
            'blueprint = gn_module_import.blueprint:blueprint',
            'config_schema = gn_module_import.conf_schema_toml:GnModuleSchemaConf',
            'migrations = gn_module_import:migrations',
        ],
    }

L’entry point code doit pointer sur une chaîne de texte contenant le code du module, i.e. IMPORT, permettant de faire la liaison entre le module et l’objet TModules en bdd.
L’entry point blueprint pointe vers le blueprint définissant les routes du module.
L’entry point config_schema pointe vers la classe Marshmallow permettant de parser le fichier de configuration du module.
L’entry point migrations pointe vers le dossier contenant les fichiers de migrations alembic.

Pour installer le module :

• pip install --editable path/to/module
• FLASK_APP=geonature.app flask db upgrade import@head
  Les migrations alembic ont pour rôle de créer l’entrée dans la table gn_commons.t_modules
• ln -s path/to/module external_module/{MODULE_CODE} (pour activer le frontend)
• Ajout du code du module dans la configuration de GeoNature (pour activer le backend):

  ENABLED_MODULES = [
    'IMPORT',
  ]

• Les commandes usuelles de re-génération des fichiers de configurations (travail en cours de @joelclems pour simplifier cette partie) :
  • geonature update_module_configuration import
  • geonature generate_frontend_tsconfig_app
  • geonature generate_frontend_modules_route

[bouttier]

Après discussion, afin de simplifier le processus d’installation notamment, le paramètre ENABLED_MODULES va être retiré, au profit du flag « active_backend » dans la BDD.
Alembic nécessite de connaître la liste des modules pour lesquelles des migrations existent (sans accéder à la BDD), mais la méthode de recherche introduite dans a7cdeaf ne nécessite pas de connaître la liste explicite des modules, rendant le paramètre ENABLED_MODULES superflu.