Réduire la duplication des exercices

[jengelaere]

Bonjour @MTES-MCT/parcours-r
Aujourd'hui chaque consigne et chaque corrigé d'exercice sont présents 5 fois :

• dans le support de cours, au fil des chapitres auxquels ils se rapportent
• dans le support de cours, au niveau du chapitre final exercice qui donne à voir en clair le corrigé
• dans savoirfR au niveau du dossier exercice
• dans savoirfR au niveau du dossier corrigé
• dans savoir faire au niveau de la vignette dédiée au module
  ça fait beaucoup !
  Et les incohérences entre version se multiplient au fil du temps...
  Voyez-vous un moyen de réduire cette duplication ?

[jengelaere]

Aujourd'hui, je vois plusieurs pistes à explorer :

• intégrer les consignes et le corrigé dans des fonctions de savoirfR : ça n'évite pas tous les doublons dans savoirfR, mais en faisant appel à ces fonctions dans le support de cours, on s'épargne la mise à jour à ces endroits
• incorporer dans le support les consignes/corrigés à partir du repo github de savoirfR, par exemple : https://raw.githubusercontent.com/MTES-MCT/savoirfR/master/inst/rstudio/templates/project/ressources/m5/enonces/exo1.R, mais je ne suis pas certaine du résultat.
  Voyez-vous d'autres pistes ?

[jdlom]

Les deux pistes me semblent intéressantes et réalisables.
Il faudra juste s'attacher à ce que le rendu soit formaté (comme dans les supports)

Je me pose la question de laquelle des deux solutions serait la meilleure.

Si on part sur la première, de fait savoirfR devient une dépendance de chaque module. (Peut-être pas besoin de construire une image docker malgré tout). L'avantage de cette solution, c'est que ca permettra de faire des tests unitaires.

La deuxième solution me semble aussi intéressante, mais j'ai peur qu'elle soit moins robuste que la première.

Après je n'ai pas le recul nécessaire pour savoir ce qu'il est possible de faire. Mais j'imagine que si on avait la possibilité d'intégrer par exemple des vignettes dans les supports de cours cela serait l'idéal.

[jdlom]

Il y a peut-être un autre piste.
J'imaginais peut-être une autre solution. Le problème des fonctions c'est que ca va peut-être pas optimal à formater pour avoir un rendu rmarkdown potable.
Histoire d'alimenter la réflexion, j'ai creusé et j'ai vu une piste intéressante :

Pour un module si pour chaque exercice on avait un Rmd, on serait je pense en mesure de les transformer en fichier R pour garder le principe de fonctionnement de savoirfR

On peut faire cela avec knitr::purl https://bookdown.org/yihui/rmarkdown-cookbook/purl.html

knitr::purl(input = "exo1.Rmd", output= "corriges/exo1.R", documentation = 2) #pour extraire le code R avec le texte autour
knitr::opt_chunks$set(purl = FALSE) #pour enlever le code R
knitr::purl(input = "exo1.Rmd", output= "enonces/exo1.R", documentation = 2) 

Pour les vignettes, on pourrait imaginer les générer automatiquement grâce à knit_child

https://bookdown.org/yihui/rmarkdown-cookbook/child-document.html

res <- knitr::knit_child('exo1.Rmd', quiet = TRUE)
cat(res, sep = '\n')

En bouclant sur un dossier, on doit pouvoir faire le rendu de la vignette.

Y'aurait un wokflow pour convertir les Rmarkdown en .R avant de builder le package savoirfR et la vignette y aurait pas de problème.
Faut voir si en pratique ca peut fonctionner.