[RM-8528] [AmazedOutputAnalyzer] Amélioration de l'API d'export d'attributs

Created on 2023-12-07 09:34:32 by Thomas Bedrine. % Done: 100

Dans l'issue #7752 nous avons posé les bases de l'API pour l'export d'attributs, on doit maintenant poursuivre cette avancée avec certains points encore non résolus ou améliorables du ticket de base.

Pour rappel, l'API actuelle reprend une partie du comportement de l'ancienne API et retourne les attributs demandés sous forme de liste ordonnée (si on a la liste @attribute_list@ en entrée correspondant à @["SpectrumID", "galaxy.Redshift", "mismatch.class"]@, les attributs retournés seraient par exemple @["spec_100001", "1.0", "success"]@). Les fonctions individuelles @get_attributes@ et @get_logpdfs@ n'ont pas été implémentées car nous avons établi que séparer les deux opérations serait redondant dans la lecture des fichiers. De plus, il est possible de répliquer le comportement de ces fonctions en passant l'argument @include_pdfs@ à False (ce qui indique de ne pas récupérer les infos de la PDF) ou en fournissant une @attribute_list@ vide (ce qui indique de ne pas récupérer d'attributs).

On souhaite maintenant améliorer l'API pour inclure les points manquants qui permettront de la rendre plus générale, en précisant le type d'objet pour la pdf (galaxy/star/qso, pour remplacer la version actuelle qui considère uniquement galaxy)

Jusqu'à présent, la liste des attributs que l'on souhaitait exporter devait être connue à la base par l'utilisateur, l'objectif est d'y remédier et de proposer un moyen de demander les attributs disponibles via l'API (avec la fonction @get_all_attributes@). Notamment, on doit aussi considérer les différents types d'attributs possibles :

• scalaires de l'output Amazed (exemples : galaxy.Redshift, qso.Redshift)
• vectoriels de l'output Amazed (exemple : galaxy.PDFProbaLog)
• scalaires de la référence (exemple : ref.redshift)
• scalaires calculés par AmazedOutput (exemple : mismatch.class)

Il faut donc établir si une distinction doit être faite entre ces attributs, à l'heure actuelle il n'y a pas de séparation entre eux et ils sont tous traités de façon équivalente. Doit-on créer des sous-listes d'attributs qui correspondent à ces catégories ?