Skip to content

Recentraliser fichiers dans l'arborescence de l'application #375

Closed

Description

@camillemonchicourt

Le fait d'avoir migré la conf et les logs dans /etc/ est intéressant pour la mise à jour de l'application.
Cependant c'est moins lisible et surtout ça bloque les possibilités d'un serveur multi-instance de GeoNature.

En regardant, les applis WEB ne font pas ça (Drupal, Lizmap....). C'est plutôt une logique d'application lourde locale.

Après discussion avec Amandine, on partirait sur un répertoire var/ dans GeoNature avec un répertoire log et un répertoire config.

A voir pour les modules externes si on garde la possibilité de les avoir en dehors de GeoNature, ou si on fait un répertoire external_modules à côté de contrib.

Activity

  1. added this to the milestone on May 3, 2018
  2. gildeluermoz commented on May 15, 2018

    @gildeluermoz
    Contributor

    je vote pour tout mettre dans le répertoire de l'appli.
    Il faut aussi un tmp dont on pourra personnaliser l'effacement selon le besoin et non brutalement à chaque reboot du serveur (ou du poste de travail du developpeur)

  3. TheoLechemia commented on Jun 14, 2018

    @TheoLechemia
    Member

    Pas mal de changement dans arborescence de l'application:

    • Suppresion du répertoire /etc/geonature
      Les fichiers de configuration sont regroupés dans le dossier config de GeoNature et de chacun des modules.
      Pour le coeur : config/geonature_config.toml
      Pour les modules, dans le répertoire du module: config/conf_gn_module.toml

    • Création d'un dossier var/log qui contient les logs d'installation (db + serveur)

    • Création d'un dossier tmp à l’intérieur du projet pour stocker les scripts d'installation provisoires.

    • Création d'un dossier external_modules ou on retrouve tous les gn_modules installés (activé ou non). Chaque gn_module est en fait un lien symbolique vers là ou se trouve le module sur la machine.

    • La table gn_commons.t_modules contient deux champs qui contrôlent l'activation du module, respectivement pour le frontend et le backend: active_frontend et active_backend. Cela permet d'activer le backend d'un module qui à un frontend exterieur à GeoNature (et inversement).

    • Regroupement de tous les scripts d'installation dans un dossier install à la racine du projet

    Pour migrer de l'ancienne structure à la nouvelle, executer le script install/migration/beta4tobeta5.sh

  4. camillemonchicourt commented on Jun 14, 2018

    @camillemonchicourt
    MemberAuthor

    Banzai !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions