Évaluation

1 Résumé

• A la fin du semestre, les étudiants rendront un projet informatique par groupe de 2-3 personnes.
• Ce projet dont le sujet est libre devra comporter:
  • Une valorisation d’un ou plusieurs jeux de données open data ou collectés par le biais de scraping ou d’API ;
  • De la visualisation ;
  • De la modélisation.
• Les étudiants sont invités à proposer des sujets qui leur plaisent, à faire valider par le chargé de TD.
• Le projet doit utiliser Git et être disponible sous Github (dépôt public ou dépôt privé à partager avec le chargé de TD) ;
• Le projet doit être reproductible sous peine de sanction forte. Cela implique des morceaux de code reproductibles, une description des dépendances et des explications si nécessaire sur la récupération des données ;
• La date du rendu est fixée au : 29 décembre 2024 23h59
• Le 10 janvier 2025, auront lieu des soutenances

2 Attentes du projet

Le projet est une problématique à laquelle vous souhaitez répondre à l’aide d’un ou de plusieurs jeu(s) de données.

Il faut donc dans un premier temps se pencher sur la recherche de problématisation et de contextualisation. Nous vous recommandons de prendre un sujet qui vous plaît afin d’être motivé à impliquer le lecteur dans votre démarche.

Trois dimensions doivent être présentes dans le projet. Pour chacune de ces parties, il est possible d’aller plus ou moins loin. Il est recommandé d’aller loin sur au moins une des 3 dimensions.

2.1 La récupération et le traitement des données

Ces données peuvent être directement disponibles sous la forme de fichiers txt, csv … ou provenir de sites internet (scraping, API). Plus le travail sur la récupération de données est important (par exemple scraping sur plusieurs sites, données croisées récupérées par le biais d’API et de fichiers…), plus la partie obtiendra de points. Si le jeu de données utilisé est un téléchargement d’un jeu propre existant, il faudra chercher à le compléter d’une manière ou d’une autre pour obtenir des points sur cette partie.

Vous obtiendrez vraisemblablement des données qui ne sont pas « propres » du premier coup : mettez en place des protocoles de nettoyage pour obtenir à la fin de cette étape un ou des jeux de données fiable et robuste pour mener ensuite votre analyse. C’est également le moment de créer des variables plus appréhendables, mieux identifiées. N’oubliez pas de justifier les choix méthodologiques que vous avez pu faire car le chargé de TD ne connaît pas forcément la base de données en question.

Faire un code reproductible quand on fait du webscraping ou utilise des API est une gageure

Comme cela est expliqué dans le chapitre consacré au webscraping, récupérer des données par ce biais est un moyen détourné peu fiable dans la durée car les sites évoluent continuellement ou mettent en oeuvre des solutions pour bloquer les robots aspirant leurs données. Vous n’êtes pas assuré que votre code qui fonctionne aujourd’hui pourra à nouveau tourner demain sans encombre. C’est un problème qui peut également être rencontré avec les API quoique ces dernières sont un moyen plus robuste d’accès aux données. Mais on n’est jamais à l’abri d’une mise à jour de celle-ci.

Une composante essentielle de l’évaluation des projets Python est la reproductibilité, i.e. la possibilité de retrouver les mêmes résultats à partir des mêmes données d’entrée et du même code. Dans la mesure du possible, il faut donc que votre rendu final parte des données brutes utilisées comme source dans votre projet. Si les fichiers de données source sont accessibles via une URL publique par exemple, il est idéal de les importer directement à partir de cette URL au début de votre projet (voir le TP Pandas pour un exemple d’un tel import via Pandas).

Face à l’incertitude de ne pas retrouver demain les mêmes données qu’aujourd’hui, il est nécessaire de pouvoir stocker des données (ou des modèles). Votre dépôt Git n’est pas le lieu adapté pour le stockage de fichiers volumineux. Un projet Python bien construit est modulaire: il sépare le stockage du code (Git), d’éléments de configuration (par exemple des jetons d’API qui ne doivent pas être dans le code) et du stockage des données. Cette séparation conceptuelle entre code et données permet de meilleurs projets.

Là où Git est fait pour stocker du code, on utilise des solutions adaptées pour le stockage de fichiers. De nombreuses solutions existent pour ce faire. Sur le SSP Cloud, on propose MinIO, une implémentation open-source du stockage S3. Si vous êtes dans cette situation, vous pouvez consulter ce guide pour partager vos données sur le sspcloud.

2.2 L’analyse descriptive et la représentation graphique

La présence de statistiques descriptives est indispensable dans le projet. De la description de la base aux premières grandes tendances des données, cette partie permet d’avoir une vision globale des données : le lien avec la problématique, comment elle permet d’y répondre, quels sont les premiers éléments de réponse… Chaque résultat doit être interprété : pas la peine de faire un describe et de ne pas le commenter.

En termes de représentation graphique, plusieurs niveaux sont envisageables, selon le degré d’approfondissement de cette partie. La base d’une bonne visualisation est de trouver le type de graphique adéquat pour ce que vous voulez montrer et de le rendre visible : une légende qui a du sens, des axes avec des noms etc.

Encore une fois, il faudra commenter votre graphique: qu’est ce qu’il montre, en quoi cela valide / contredit votre argumentaire ?

Note 2.1: Les applications réactives

Dans le cadre de ce cours, nous présentons plusieurs librairies graphiques permettant de créer des visualisations de données interactives, notamment Plotly ou Leaflet. Pour aller plus loin, vous pouvez désirer créer des applications encapsulant plusieurs graphiques construits automatiquement en fonction de choix de l’utilisateur sur une interface graphique.

Tout d’abord, ce n’est pas un prérequis pour ce cours. Le cours de 3e année “Mise en production de projets de data science” que Romain Avouac et moi donnons à l’ENSAE vous permettra de mettre en oeuvre ceci, qui fait appel à des concepts plus avancés qu’une introduction à Python pour la science des données.

C’est néanmoins un plus qui est apprécié et si vous désirez aller dans cette voie, il est recommandé de bien choisir son écosystème. Il vaut mieux mettre en oeuvre des frameworks web modernes comme Streamlit que des clients lourds comme tkinter qui rendent le code difficilement reproductible car adhérant à une configuration logicielle. Pour en savoir plus, se reporter à l’introduction de la partie visualisation.

Si vous faites une application réactive, vous n’êtes pas obligé de rédiger un notebook. Cependant, faites en sorte que votre application propose une page présentant votre démarche afin de faire comprendre à votre lecteur la problématique et les solutions mises en oeuvre.
Cette application doit être reproductible sur le SSPCloud par le biais, par exemple, d’un streamlit run. Il est donc vivement recommandé de développer celle-ci sur le SSPCloud où la reproductibilité est maximale.

2.3 La modélisation

Vient ensuite la phase de modélisation : un modèle peut être le bienvenu quand des statistiques descriptives ne suffisent pas à apporter une solution complète à votre problématique ou pour compléter / renforcer l’analyse descriptive. Le modèle importe peu (régression linéaire, random forest ou autre) : il doit être approprié (répondre à votre problématique) et justifié. Vous pouvez aussi confronter plusieurs modèles qui n’ont pas la même vocation : par exemple une CAH pour catégoriser et créer des nouvelles variables / faire des groupes puis une régression. Même si le projet n’est pas celui du cours de stats, il faut que la démarche soit scientifique et que les résultats soient interprétés.

3 Format du rendu

Sur le format du rendu, vous devrez :

• Écrire un rapport sous forme de Notebook (quelques exceptions à cette règle peuvent exister, par exemple si vous développer une appli Dash ou Streamlit comme expliqué dans la Note 2.1) ou de Quarto Markdown. Soyez vigilant avec le contrôle de version (Important 3.1)
• Avoir un projet Github avec le rapport. Les données utilisées doivent être accessibles également, dans le dépôt, sur internet ou sur l’espace de stockage du SSPCloud (voir tutoriel S3).
• Les dépôts Github où seul un upload du projet a été réalisé seront pénalisés. A l’inverse, les dépôts dans lequels le contrôle de version et le travail collaboratif ont été activement pratiqués (commits fréquents, pull requests, ..) seront valorisés.
• Le code contenu dans le rapport devra être un maximum propre (pas de copier coller de cellule, préférez des fonctions)

Important 3.1: Git et les notebooks

Faites attention au contrôle de version avec les notebooks, cela ne fait pas toujours bon ménage.

Comme expliqué dans le chapitre sur Git, lorsque vous travaillez sur le même fichier en même temps vous pouvez vous retrouver avec un conflit de version lorsque vous résolvez les différences dans vos dépôts. Dans les notebooks cela peut se traduire par de multiples conflits de version car deux notebooks en apparence similaires peuvent contenir beaucoup d’éléments différents dans les fichiers bruts (un JSON assez complexe, embarquant notamment des id d’exécution de cellules changeant systématiquement). Un merge mal géré peut rendre un notebook invalide.

Il est recommandé de ne pas travailler sur un même notebook sur une même branche en même temps. Cela fait donc beaucoup de conditions pour arriver à un conflit de version mais dans le rush inhérent à tout projet cela peut vite arriver. Outre la coordination, nous pouvons vous conseiller de déporter une partie du code dans des fichiers .py importés sous forme de module par le notebook. De toute manière, c’est une bonne pratique de ne pas accumuler de trop longues instructions de code dans un notebook car cela freine la lisibilité et l’intelligibilité de celui-ci.

4 Barème approximatif

Catégorie	Points
Données (collecte et nettoyage)	4
Analyse descriptive	4
Modélisation	2
Démarche scientifique et reproductibilité du projet	4
Format du code (code propre et github)	2
Soutenance	4

Lors de l’évaluation, une attention particulière sera donnée à la reproductibilité de votre projet. Chaque étape (récupération et traitement des données, analyses descriptives, modélisation) doit pouvoir être reproduite à partir du notebook final.

Le test à réaliser : faire tourner toutes les cellules de votre notebook et ne pas avoir d’erreur est une condition sine qua non pour avoir la moyenne.

5 Projets passés faits par les étudiants 😍

Informations additionnelles

environment files have been tested on.

Latest built version: 2025-03-19

Python version used:

'3.12.6 | packaged by conda-forge | (main, Sep 30 2024, 18:08:52) [GCC 13.3.0]'

Package	Version
affine	2.4.0
aiobotocore	2.21.1
aiohappyeyeballs	2.6.1
aiohttp	3.11.13
aioitertools	0.12.0
aiosignal	1.3.2
alembic	1.13.3
altair	5.4.1
aniso8601	9.0.1
annotated-types	0.7.0
anyio	4.8.0
appdirs	1.4.4
archspec	0.2.3
asttokens	2.4.1
attrs	25.3.0
babel	2.17.0
bcrypt	4.2.0
beautifulsoup4	4.12.3
black	24.8.0
blinker	1.8.2
blis	1.2.0
bokeh	3.5.2
boltons	24.0.0
boto3	1.37.1
botocore	1.37.1
branca	0.7.2
Brotli	1.1.0
cachetools	5.5.0
cartiflette	0.0.2
Cartopy	0.24.1
catalogue	2.0.10
cattrs	24.1.2
certifi	2025.1.31
cffi	1.17.1
charset-normalizer	3.4.1
click	8.1.8
click-plugins	1.1.1
cligj	0.7.2
cloudpathlib	0.21.0
cloudpickle	3.0.0
colorama	0.4.6
comm	0.2.2
commonmark	0.9.1
conda	24.9.1
conda-libmamba-solver	24.7.0
conda-package-handling	2.3.0
conda_package_streaming	0.10.0
confection	0.1.5
contextily	1.6.2
contourpy	1.3.1
cryptography	43.0.1
cycler	0.12.1
cymem	2.0.11
cytoolz	1.0.0
dask	2024.9.1
dask-expr	1.1.15
databricks-sdk	0.33.0
dataclasses-json	0.6.7
debugpy	1.8.6
decorator	5.1.1
Deprecated	1.2.14
diskcache	5.6.3
distributed	2024.9.1
distro	1.9.0
docker	7.1.0
duckdb	1.2.1
en_core_web_sm	3.8.0
entrypoints	0.4
et_xmlfile	2.0.0
exceptiongroup	1.2.2
executing	2.1.0
fastexcel	0.11.6
fastjsonschema	2.21.1
fiona	1.10.1
Flask	3.0.3
folium	0.17.0
fontawesomefree	6.6.0
fonttools	4.56.0
frozendict	2.4.4
frozenlist	1.5.0
fsspec	2023.12.2
geographiclib	2.0
geopandas	1.0.1
geoplot	0.5.1
geopy	2.4.1
gitdb	4.0.11
GitPython	3.1.43
google-auth	2.35.0
graphene	3.3
graphql-core	3.2.4
graphql-relay	3.2.0
graphviz	0.20.3
great-tables	0.12.0
greenlet	3.1.1
gunicorn	22.0.0
h11	0.14.0
h2	4.1.0
hpack	4.0.0
htmltools	0.6.0
httpcore	1.0.7
httpx	0.28.1
httpx-sse	0.4.0
hyperframe	6.0.1
idna	3.10
imageio	2.37.0
importlib_metadata	8.6.1
importlib_resources	6.5.2
inflate64	1.0.1
ipykernel	6.29.5
ipython	8.28.0
itsdangerous	2.2.0
jedi	0.19.1
Jinja2	3.1.6
jmespath	1.0.1
joblib	1.4.2
jsonpatch	1.33
jsonpointer	3.0.0
jsonschema	4.23.0
jsonschema-specifications	2024.10.1
jupyter-cache	1.0.0
jupyter_client	8.6.3
jupyter_core	5.7.2
kaleido	0.2.1
kiwisolver	1.4.8
langchain	0.3.20
langchain-community	0.3.9
langchain-core	0.3.45
langchain-text-splitters	0.3.6
langcodes	3.5.0
langsmith	0.1.147
language_data	1.3.0
lazy_loader	0.4
libmambapy	1.5.9
locket	1.0.0
loguru	0.7.3
lxml	5.3.1
lz4	4.3.3
Mako	1.3.5
mamba	1.5.9
mapclassify	2.8.1
marisa-trie	1.2.1
Markdown	3.6
markdown-it-py	3.0.0
MarkupSafe	3.0.2
marshmallow	3.26.1
matplotlib	3.10.1
matplotlib-inline	0.1.7
mdurl	0.1.2
menuinst	2.1.2
mercantile	1.2.1
mizani	0.11.4
mlflow	2.16.2
mlflow-skinny	2.16.2
msgpack	1.1.0
multidict	6.1.0
multivolumefile	0.2.3
munkres	1.1.4
murmurhash	1.0.12
mypy-extensions	1.0.0
narwhals	1.30.0
nbclient	0.10.0
nbformat	5.10.4
nest_asyncio	1.6.0
networkx	3.4.2
nltk	3.9.1
numpy	2.2.3
opencv-python-headless	4.10.0.84
openpyxl	3.1.5
opentelemetry-api	1.16.0
opentelemetry-sdk	1.16.0
opentelemetry-semantic-conventions	0.37b0
orjson	3.10.15
OWSLib	0.28.1
packaging	24.2
pandas	2.2.3
paramiko	3.5.0
parso	0.8.4
partd	1.4.2
pathspec	0.12.1
patsy	1.0.1
Pebble	5.1.0
pexpect	4.9.0
pickleshare	0.7.5
pillow	11.1.0
pip	24.2
platformdirs	4.3.6
plotly	5.24.1
plotnine	0.13.6
pluggy	1.5.0
polars	1.8.2
preshed	3.0.9
prometheus_client	0.21.0
prometheus_flask_exporter	0.23.1
prompt_toolkit	3.0.48
propcache	0.3.0
protobuf	4.25.3
psutil	7.0.0
ptyprocess	0.7.0
pure_eval	0.2.3
py7zr	0.20.8
pyarrow	17.0.0
pyarrow-hotfix	0.6
pyasn1	0.6.1
pyasn1_modules	0.4.1
pybcj	1.0.3
pycosat	0.6.6
pycparser	2.22
pycryptodomex	3.21.0
pydantic	2.10.6
pydantic_core	2.27.2
pydantic-settings	2.8.1
Pygments	2.19.1
PyNaCl	1.5.0
pynsee	0.1.8
pyogrio	0.10.0
pyOpenSSL	24.2.1
pyparsing	3.2.1
pyppmd	1.1.1
pyproj	3.7.1
pyshp	2.3.1
PySocks	1.7.1
python-dateutil	2.9.0.post0
python-dotenv	1.0.1
python-magic	0.4.27
pytz	2025.1
pyu2f	0.1.5
pywaffle	1.1.1
PyYAML	6.0.2
pyzmq	26.3.0
pyzstd	0.16.2
querystring_parser	1.2.4
rasterio	1.4.3
referencing	0.36.2
regex	2024.9.11
requests	2.32.3
requests-cache	1.2.1
requests-toolbelt	1.0.0
retrying	1.3.4
rich	13.9.4
rpds-py	0.23.1
rsa	4.9
ruamel.yaml	0.18.6
ruamel.yaml.clib	0.2.8
s3fs	2023.12.2
s3transfer	0.11.3
scikit-image	0.24.0
scikit-learn	1.6.1
scipy	1.13.0
seaborn	0.13.2
setuptools	76.0.0
shapely	2.0.7
shellingham	1.5.4
six	1.17.0
smart-open	7.1.0
smmap	5.0.0
sniffio	1.3.1
sortedcontainers	2.4.0
soupsieve	2.5
spacy	3.8.4
spacy-legacy	3.0.12
spacy-loggers	1.0.5
SQLAlchemy	2.0.39
sqlparse	0.5.1
srsly	2.5.1
stack-data	0.6.2
statsmodels	0.14.4
tabulate	0.9.0
tblib	3.0.0
tenacity	9.0.0
texttable	1.7.0
thinc	8.3.4
threadpoolctl	3.6.0
tifffile	2025.3.13
toolz	1.0.0
topojson	1.9
tornado	6.4.2
tqdm	4.67.1
traitlets	5.14.3
truststore	0.9.2
typer	0.15.2
typing_extensions	4.12.2
typing-inspect	0.9.0
tzdata	2025.1
Unidecode	1.3.8
url-normalize	1.4.3
urllib3	1.26.20
uv	0.6.8
wasabi	1.1.3
wcwidth	0.2.13
weasel	0.4.1
webdriver-manager	4.0.2
websocket-client	1.8.0
Werkzeug	3.0.4
wheel	0.44.0
wordcloud	1.9.3
wrapt	1.17.2
xgboost	2.1.1
xlrd	2.0.1
xyzservices	2025.1.0
yarl	1.18.3
yellowbrick	1.5
zict	3.0.0
zipp	3.21.0
zstandard	0.23.0

View file history

md`Ce fichier a été modifié __${table_commit.length}__ fois depuis sa création le ${creation_string} (dernière modification le ${last_modification_string})`

creation = d3.min(
  table_commit.map(d => new Date(d.Date))
)

last_modification = d3.max(
  table_commit.map(d => new Date(d.Date))
)

creation_string = creation.toLocaleString("fr", {
  "day": "numeric",
  "month": "long",
  "year": "numeric"
})

last_modification_string = last_modification.toLocaleString("fr", {
  "day": "numeric",
  "month": "long",
  "year": "numeric"
})

html`<div>${git_history_table}</div>`

html`<div>${git_history_plot}</div>`

SHA	Date	Author	Description
ab0eb6e9	2024-12-27 17:29:43	lgaliana	relative path image
88890345	2024-12-27 14:38:09	lgaliana	Sur la récupération de données
618c24a7	2024-12-26 15:46:05	lgaliana	Plus de projets d’alumni
c1853b92	2024-11-20 15:09:19	Lino Galiana	Reprise eval + reprise S3 (#576)
4ddbdc80	2024-10-30 10:31:07	lbaudin	Update evaluation.qmd (#572)
e0fa908a	2024-10-12 13:50:16	lgaliana	Mise en forme exogit
c326488c	2024-10-10 14:31:57	Romain Avouac	Various fixes (#565)
d02515b4	2024-04-27 21:32:25	Lino Galiana	Eléments sur les applis & évaluation (#495)
005d89b8	2023-12-20 17:23:04	Lino Galiana	Finalise l’affichage des statistiques Git (#478)
1f23de28	2023-12-01 17:25:36	Lino Galiana	Stockage des images sur S3 (#466)
c8123220	2023-11-29 10:13:21	lbaudin	Dates d’évaluation (#462)
889a71ba	2023-11-10 11:40:51	Antoine Palazzolo	Modification TP 3 (#443)
3276558f	2023-10-17 11:09:45	Romain Avouac	more example projects (#436)
154f09e4	2023-09-26 14:59:11	Antoine Palazzolo	Des typos corrigées par Antoine (#411)
3bdf3b06	2023-08-25 11:23:02	Lino Galiana	Simplification de la structure 🤓 (#393)
30823c40	2023-08-24 14:30:55	Lino Galiana	Liens morts navbar (#392)
202e7dc0	2023-08-11 15:52:52	linogaliana	Order execution
5d4874a8	2023-08-11 15:09:33	Lino Galiana	Pimp les introductions des trois premières parties (#387)
25adfdce	2022-09-22 16:20:12	Lino Galiana	Slides version 2022 (#275)
b2d48237	2022-09-21 17:36:29	Lino Galiana	Relec KA 21/09 (#273)
2360ff7b	2022-08-02 16:29:57	Lino Galiana	Test wowchemy update (#247)
3e919f9f	2022-03-28 10:00:49	jblaval	Ajoute projet élève (#224)
dece5e48	2022-03-21 10:10:39	Mélissa Tamine	Ajoute projet élèves (#222)
06016669	2022-03-21 10:05:12	Idrissa KONKOBO	Ajoute projet élève (#221)
9c71d6e7	2022-03-08 10:34:26	Lino Galiana	Plus d’éléments sur S3 (#218)
6cc6d81f	2021-12-31 09:40:17	Lino Galiana	Lien pour avoir des notebooks propres
81ce124d	2021-09-20 15:36:05	Romain Avouac	Quelques éléments sur la reproductibilité (#148)
bf5ebc5f	2021-09-01 14:41:17	Lino Galiana	Fix problem import pynsee (#128)
4cdb759c	2021-05-12 10:37:23	Lino Galiana	:sparkles: :star2: Nouveau thème hugo :snake: :fire: (#105)
8781c833	2021-03-05 15:32:43	romanegajdos	Projet GPS vélo (#96)
acfb0100	2021-03-03 18:50:32	Lino Galiana	Intégration d’un endroit où lister les projets des élèves (#95)
72092d73	2020-11-10 17:43:52	Lino Galiana	Ajout dates rendu
b47e1ae4	2020-11-09 14:58:18	Lino Galiana	Section sur l’intégration continue (#77)
e644cc70	2020-10-21 15:48:12	Lino Galiana	Actualise la partie évaluation (#73)
4677769b	2020-09-15 18:19:24	Lino Galiana	Nettoyage des coquilles pour premiers TP (#37)
913047d3	2020-09-08 14:44:41	Lino Galiana	Harmonisation des niveaux de titre (#17)

git_history_table = Inputs.table(
  table_commit,
  {
    format: {
      SHA: x => md`[${x}](${github_repo}/commit/${x})`,
      Description: x => md`${replacePullRequestPattern(x, github_repo)}`,
      /*Date: x => x.toLocaleString("fr", {
        "month": "numeric",
        "day": "numeric",
        "year": "numeric"
        })
      */
    }
  }
)

git_history_plot = Plot.plot({
  marks: [
    Plot.ruleY([0], {stroke: "royalblue"}),
    Plot.dot(
          table_commit,
          Plot.pointerX({x: (d) => new Date(d.date), y: 0, stroke: "red"})),
    Plot.dot(table_commit, {x: (d) => new Date(d.Date), y: 0, fill: "royalblue"})
  ]
})

function replacePullRequestPattern(inputString, githubRepo) {
    // Use a regular expression to match the pattern #digit
    var pattern = /#(\d+)/g;

    // Replace the pattern with ${github_repo}/pull/#digit
    var replacedString = inputString.replace(pattern, '[#$1](' + githubRepo + '/pull/$1)');

    return replacedString;
}

github_repo = "https://github.com/linogaliana/python-datascientist"

table_commit = {

// Get the HTML table by its class name
var table = document.querySelector('.commit-table');

// Check if the table exists
if (table) {
    // Initialize an array to store the table data
    var dataArray = [];

    // Extract headers from the first row
    var headers = [];
    for (var i = 0; i < table.rows[0].cells.length; i++) {
        headers.push(table.rows[0].cells[i].textContent.trim());
    }

    // Iterate through the rows, starting from the second row
    for (var i = 1; i < table.rows.length; i++) {
        var row = table.rows[i];
        var rowData = {};

        // Iterate through the cells in the row
        for (var j = 0; j < row.cells.length; j++) {
            // Use headers as keys and cell content as values
            rowData[headers[j]] = row.cells[j].textContent.trim();
        }

        // Push the rowData object to the dataArray
        dataArray.push(rowData);
    }
  }

  return dataArray

}

// Get the element with class 'git-details'
{
  var gitDetails = document.querySelector('.commit-table');

  // Check if the element exists
  if (gitDetails) {
      // Hide the element
      gitDetails.style.display = 'none';
  }
}

Plot = require('@observablehq/plot@0.6.12/dist/plot.umd.min.js')