How to

Le dépot cs-metz/ecues

Le dépôt cs-metz/ecues est à l’adresse https://gitlab-research.centralesupelec.fr/cs-metz/ecues. C’est un projet git qui contient tout ce que les enseignants doivent éditer pour décrire la formation.

Rappel : ecue <=> Elément Constitutif d’une Unité d’Enseignement… ce que géode appelle un UE… et ce qu’on appelle communément un module de cours. (e.g. l’ECUE “Mathématiques Pour l’Ingénieur”).

Le but de ce dépôt est de rassembler toutes les descriptions d’ECUEs du campus de Metz, pour que chaque formation (spé info, spé physique, SDI-M, …) puisse venir y puiser l’information dont elle a besoin pour:

  • générer des pages web
  • générer des catalogues de cours
  • nourrir le rableau de bord admin
  • …

Ce git contient aussi de quoi décrire chacune des formations (par exemple pour SDI-M, le fait qu’il y a 2 semestres, dans chacun des séquences, dans lesquelles sont les unités de formation, …)

Les intervenants

Ils sont décrits dans le dossier Staff, qui structure la définition d’informations pour les différents intervenants sous forme de fichiers .json. Le fichier common.json, quand il est présent dans un dossier, décrit les attributs à ajouter à toutes les personnes du dossier et de ses sous-dossiers (récursivement).

Les ECUEs

Les variables globales

On peut vouloir définir dans les scripts python des variables globales (pour ne pas copier-coller les même choses dans plusieurs fichiers). Pour ce faire, dans le dossier Variables, il y a la définition d’un package csmetzvar. Dans Variables/csmetzvars, le fichier lv.py définit par exemple acquis. Dans un script de description de module, on peut écrire:

from csmetzvars import lv

...
module.acquis = lv.acquis
...

Où et comment sont décrits les ECUEs ?

Ils sont dans le dossier ECUEs. On peut les répartir dans des sous-dossiers (par exemple le sous-dossier IA). Chaque ECUE est décrit par un fichier .py, disons toto.py. Le mot toto est le tag de l’ECUE, il doit être unique (unique dans tout le dossier ECUEs).

Les ECUEs peuvent être partagés par différentes formations, qu’on appellera différentes tracks. Certains éléments des ECUEs peuvent différer selon la track qui les inclut (pas les mêmes compétences, pas les mêmes modalités d’examen, des TP en plus dans une track, …).

Il y a des outils pour décrire, dans les .py, ce qui diffère d’une track à l’autre.

Dépendances / pré-requis

Dans le dossier ECUEs, il y a un fichier deps.json, dont la syntaxe est

  • le fichier est une liste de déclarations.
  • une déclaration est :
    • {"@seq": [ECUE1, ECUE2, …]} (les ecues dans l’ordre de dépendance, le suivant requiert le précédent).
    • {"@before" : [ECUE1, ECUE2, …], “@after”: [ECUE1, ECUE2, …]} (chaque ECUE de after doit suivre tous les ECUEs de before)
  • un ECUE est le nom d’un fichier .py (entre guillements, sans .py)
  • pour une liste à 1 élement, on peut se passer des []

C’est quoi la syntaxe des fichiers d’ECUEs ?

Dans le dossier Doc, il y a un exemple mon-module.py

Les formations

La lib cursus sur laquelle tout ceci se base est faite pour analyser des descriptions structurées en JSON. Une structure peut en inclure une autre, ce qui permet de séparer une grosse description JSON en plusieurs fichiers.

Les structures peuvent avoir un champ "code": "toto", ce qui signifie qu’une génération de graphique d’heures de cours lui sera associée (l’image étant alors toto.png ou toto.pdf).

Chaque formation est un sous dossier du dossier Structures, dont le nom est le nom de la “track” représentant cette formation. Pour le spé info, c’est dans Structures/info. Dans ce sous-dossier, regardez spe-info.json à titre d’exemple, puis 1A.json, puis S05.json, puis UE-S05-01.json. Dans ce dernier fichier, l’expression {"$": "MathInge", "track": "info"}dit qu’il faut chercher la description donnée par MathInge.py (qui est dans les sous-dossiers de ECUEs), et générer les infos correspondantes à la track info pour cette UE-là.

Enfin, la gestion de cours électifs se fait par {"|": [elem1, elem2, ...]}. Voir par exemple UE-S10-13.json.

Le dossier Config

Pas besoin de comprendre pour utiliser.

Il contient tout ce qui s’apparente à une traduction. On a:

  • competences.json : Lisez-le, c’est évident.
  • translations.json : Les traductions diverses.
  • module-attr-set.json : Ce sont les items, pour chaque ECUE, apparaissant dans le catalogue… avec leur traduction.
  • module-attr-set-convert.json : Pour chaque langue, cela dit quel attribut de la description .json de l’ECUE il faut regarder quand on veut la description d’un item. Pour l’item “quoi” par exemple, qui est le contenu, il faut regarde la valeur “quoi” du json si on est en français, mais “what” si on est en anglais. Les .json associés aux .py des ECUEs sont générés par les moulinettes. On notera que “quel attribut” est en fait une liste… en effet, les attributs sont cherchez dans l’ordre de cette liste, jusqu’à ce qu’on trouve une valeur (??? sera affiché dans les catalogue si vraiment on ne trouve rien pour l’item). Par exemple, l’item “pseudo” est à chercher dans l’attribut “pseudo”… ou “tag” s’il manque.
  • module-formatted-attr-set-convert.json : C’est pareil, dans le cas où les descriptions de cours proposent plusieurs formats (md et latex).

Les fichiers de configs sont a priori valables pour toutes nos formations.

Le dossier Grilles-Evaluation-Competences

Il contient les fichiers JSON de description des grilles de compétences.

Le dossier Perspectives

Il contient la description des perspectives (utilisées par certaine moulinettes pour représenter les perspectives sur le page web).

Et mon site web ? Mon catalogue ?

Chaque formation doit se faire un projet git qui va générer tout ça. Dans ce projet, il faut inclure le présent Git comme un sous-module. Il faudra aussi prévoir un site hugo, et un makefile qui va générer la partie catalogue de ce site à partir des infos que l’on daura décrites ici.

S’inspirer du git du spe-info.

Service après ven… après partage !

Contactez Hervé.

Tester mon site en local

Pour installer cursus et ecues sur son poste, il faut se créer un virtual env (moi je me mets à ma racine).

sudo apt install python3-venv 
python3 -m venv ~/virtual-env

Ensuite, à chaque fois qu’on veut faire du python, il faut:

. ~/virtual-env/bin/activate

je travaille, puis

deactivate

… ou killer le terminal.

Pour l’installation dans l’environnement virtuel donc:

. ~/virtual-env/bin/activate
pip install git+https://gitlab-research.centralesupelec.fr/frezza/cursus
pip install git+https://gitlab-research.centralesupelec.fr/cs-metz/cursus-metz-lib
deactivate

Après-ça, les moulinettes de votre site qui invoque des utilitaires de cursus ou csmetz seront disponnibles.