script d'export CSV
 
 
Aller au fichier
Vincent Adolphe 4fe0a17c53 fix: supprime un parametre inutile dans get_main_query() 2022-10-28 03:03:19 +02:00
src fix: supprime un parametre inutile dans get_main_query() 2022-10-28 03:03:19 +02:00
tests feat(tests): ajout structure de test 2022-08-11 15:06:42 +02:00
.gitignore fix: ajuste .gitignore et corrige le chemin de _version.py 2022-08-11 16:17:55 +02:00
Makefile build: ajoute une cible sbuild, plus simple 2022-08-11 16:24:51 +02:00
README.md ref: decouple l'ouverture de la bdd et du fichier csv du code principal 2022-08-11 17:48:56 +02:00
pyproject.toml fix: ajuste .gitignore et corrige le chemin de _version.py 2022-08-11 16:17:55 +02:00
requirements.txt init 2022-08-11 14:49:35 +02:00
setup.cfg feat(tests): ajout structure de test 2022-08-11 15:06:42 +02:00
setup.py init 2022-08-11 14:49:35 +02:00

README.md

Script de génération CSV

Installation

Il faut d'abord récupérer les sources du projets dans un dossier. Pour l'exemple on prendra export_csv/

Le script développé pour assurer la génération des chiers CSV destinés à la diffusion OpenData est fait en langage Python. Un environnement dédié a été configuré dans le répertoire /home/neogeo/export_csv Cet environnement est un environnement virtuel python, généré par la commande suivante:

make init

Pour activer l’environnement il faut se déplacer dans le répertoire export_csv/ puis effectuer la commande suivante :

. venv/bin/activate

Un répertoire dédié au code source du script lui-même a été créé dans export_csv/src, et le script s’y nomme main.py.

Les CSV eux-mêmes sont générés directement dans $HOME/CSV. Ce répertoire de destination est paramétrable (voir plus bas)

Pour exécuter le script on peut simplement faire appel au script bash prévu à cet effet dans le répertoire racinee de l'utilisateur :

./generate_csv.sh

Script d’export pas-à-pas.

Le script main.py comporte plusieurs sections avant le coeur du programme de récupération des données et de génération des CSV. Il lit nottement le fichier export_csv/src/pocli_csv_export/settings.py qui permet de configurer de nouveaux indicateurs ou de paramétrer le répertoire de destination ou l’accès à la base de données.

On peut s'inspirer du fichier export_csv/src/pocli_csv_export/settings.example.py pour creer le fichier settings.py:

  • Parametrage du répertoire d'export:
#### DEFINITION DU REPERTOIRE DE DESTINATION DES FICHIERS CSV GENERES
DESTINATION_FOLDER = '/tmp/CSV'
  • Connexion à la base de données
#### PARAMETRAGE DE L'ACCES A LA BASE DE DONNEES ################
sql_hostname = '127.0.0.1'
sql_username = 'username'
sql_password = 'password'
sql_main_database = 'database'
sql_port = 5432

Définition des indicateurs

Pour chacun des indicateurs à traiter dans le script il faut renseigner le dictionnaire des indicateurs, nommé INDICATORS, avec l’identi ant de l’indicateur et les informations associées à sa publication (colonne cible dans le chier CSV, type d’énergie et lière), sur le modèle suivant :

#### HOWTO : GESTION DES INDICATEURS #########################
#
# Pour chacun des indicateurs, ajouter au dictionnaire INDICATORS
# une nouvelle structure sur le modèle suivant ;
# 'ID 9 chiffres': {
#        'colonne':'NB_INSTALL',
#        'energy_type':'Electricite',
#        'filiere':'Eolien'
#    }
#  En cas d'ajout, ne pas oublier de séparer du précédent par une virgule
##############################################################

Le dictionnaire est alors structuré comme suit:

INDICATORS = {
    '202155002': {
        'colonne':'NB_INSTALL',
        'energy_type':'Electricite',
        'filiere':'Eolien'
    },
    '202206002': {
        'colonne':'NB_INSTALL',
        'energy_type':'Electricite',
        'filiere':'Solaire photovoltaique'
    },
...

En cas d’ajout ou modification, il faut faire attention à respecter la structure du dictionnaire (accolades, virgules séparatives), et bien renseigner de manière uniforme les colonnes, types d’énergie et lières, afin de bien regrouper les résultats en un même fichier par lière par exemple.

Territoires à traiter

Les différents types de territoires à traiter sont listés dans la variable TYPE_TER. Il faut que les valeurs correspondent à ce qui est utilisé dans la colonne TYPE_TER de la table T_TERRITOIRES.

#### TYPES DE TERRITOIRES A TRAITER    ########################
TYPE_TER = ('REGION','DEPARTEMENT','EPCI','PNR','SCOT')

Génération des fichiers

Pour lancer le script et générer les fichiers il faut ensuite utiliser les commandes suivantes depuis la racine du compte :

. export_csv/venv/bin/activate
python export_csv/src/main.py

ou plus simplement depuis la racine du compte ./generate_csv.sh

Historique du projet

Projet initié par Guillaume SUEUR de Néogeo le 28/02/2022 ("Copyright 2022, Neogeo Technologies"). Lors de la migration de la base de donnée du CERDD de MySQL à PostgreSQL il a fallut revoir le script et pallier autant que faire se peut à quelques faiblesses identifiées (voir ci dessous). Cette partie du travail est initiée par Vincent ADOLPHE de ClissXXI.

Points améliorables

  • pas de versionnement (git ou autre) permet de tracker les modifications du code

  • présence de code mort (ça s'évite facilement avec un système de versionnement)

  • pas de découpage paramètre/code (permet d'isoler des infos sensible comme les mots de passe)

  • pas de découpage en fonctions, code fleuve

  • pas très DRY (Don't Repeat Yourself - répétition de portions de code) (corollaire du code fleuve)

  • pas d'utilisation d'ORM (sqlalchemy ou l'ORM de django) on est moins agnostique vis à vis de la base de donnée ce qui est dommage surtout dans un contexte de changement MySQL vers PostgreSQL

  • pas de formatage type black/isort -> améliore la lisibilité du code

  • utilisation assez "php" du code: (if/elifs/else) str.replace()... là encore des structures comme dict() et des fonctions améliorent la lisiblité et la maintenabilité du code

  • pas de tests (on est en python unittest, nose, pytest, mock existent et on est déjà dans un environnement virtuel)

  • certaines colonnes sont adressées par leur numéro plutôt que par leur nom ça ajoute de la confusion (column_names.pop(), type_ter = row[2], res[0], res[1]) des structures comme dict() ou NamedTuple() permettent d'éviter ça.

  • utilisation de nom de variables de moins de 3 caractères (risque de confusion)

Tout ces points sont améliorables en vue de:

  • la robustesse du script (est ce qu'il se comporte bien comme on veut)

  • la maintenance du script (est ce qu'il reste lisible et compréhensible dans le temps)