feat: Inflate_all()

[ymansiaux]

TODO:

• Fix unit tests
  

-> devtools::check() performed by @ymansiaux on 2023-05-11

All like:

Warning (test-inflate-part2.R:59): (code run outside of `test_that()`)
path[1]="/tmp/RtmpJoImwR/all.templates.inflate6b9525bdf9ae/minimal": Aucun fichier ou dossier de ce type

• Test inflate_all_no_check() to verify it does not check ?
  done by @ymansiaux on 2023-05-10 : a39a1a5

• Test what happens with "keep" section: test driven
  done by @ymansiaux on 2023-05-10 : 8e4901d

• Edit inflate-params writing in config_fusen.yaml to deal appropriately with logicals.
  Logicals were written as yes/no, we want them to be stored as TRUE/FALSE
  done by @ymansiaux on 2023-05-11 : a253b4e

• See if we can put in function the document & check part used similarly in ìnflate() and inflate_all()
  done by @ymansiaux on 2023-05-11 ba45a5a

• See if there is still a need to separate test_that() calls for easier maintenance

• Open issue for documentation refactor

• Faire tourner inflate_all() et inflate_all_no_check() sur {fusen} lui-même pour voir. Gérer les messages d'erreurs plus explicites pour l'utilisateur
  

issue #96
close #157

[statnmap]

https://tech.lgbt/@debruine/110315357001043525

list(x=TRUE, y=FALSE, z = "true", a = "a") |>
yaml::as.yaml(handlers = list(
 logical = function(x) {
 result <- ifelse(x, "true", "false")
 class(result) <- "verbatim"
 return(result)
 }
))

[statnmap]

Merci de continuer à avancer sur ce sujet !

Je vois que tu as retiré {devtools} pour mettre {rcmdcheck}.
Je comprend pourquoi tu as fait ça car j'ai déjà eu ce problème.
Pour simplifier le problème, je dirai que c'est une question de fonctionnement de {devtools} dans un environnement interactif ou non.

Je pense qu'il faut remettre {devtools} plutôt que {rmcdcheck} parce que les utilisateurs vont utiliser {fusen} dans un environnement interactif et non pas dans un contexte comme nos tests unitaires.
Donc il faut faire en sorte que {fusen} corresponde à ce qu'un utilisateur voudrait et non pas s'ajuste aux problèmes que l'on rencontre en tant que dev.

Je te propose de regarder ce qu'il se passe dans les tests "inflate-part-1". Tu verras que j'ai mis des inflate(check = FALSE) puis plus tard mis à rcmdcheck() dans le test unitaire, pour éviter de tomber sur les mêmes problèmes que tu as vu dans le CI.
Tu noteras que le check = TRUE je ne le teste que dans inflate-part-2" dans un environnement interactif.
Et c'est la raison pour laquelle "dev/dev_history" contient des lignes de code pour lancer les tests dans la console, et donc en interactif.

On pourrait discuter du vrai pourquoi. Pourquoi tu t'es senti obligé de déclarer MASS, et tous les packages r-base ?
C'est parce que le devtools::check() travaille dans un libPaths indépendant de façon à n'avoir accès qu'aux packages listés dans ton DESCRIPTION et donc pour s'assurer que tu as bien tout déclaré.
Cependant, ce libPaths temporaire et créé avec un lien symbolique vers le r-base.
Lorsque tu lances un devtools::check() à l'intérieur du devtools::check(), il fait de même. Mais il ne se rend pas compte que le lien symbolique vers le r-base est à conserver. Du coup, il le supprime pour avoir un environnement le plus simple possible. Mais comme il ne peut pas créer le lien symbolique vers r-base à partir du lien symbolique vers r-base du check() parent, alors il est perdu.
Cela ne remet pas en cause le fonctionnement de {fusen}. Ça n'a pas d'impact sur les utilisateurs. Même si les utilisateurs lancent {fusen} dans un environnement non interactif, le check fonctionnera comme attendu.
Ça n'a un impact que pour les dev de {fusen} (nous !) qui veulent check que le check fonctionne...
C'est la joie de créer des packages pour simplifier la vie des autres dev ! Les packages pour faire des packages, c'est compliqué.

[ymansiaux]

Merci pour ta réponse c'était très instructif !

J'ai fait des modifications en conséquent. J'ai par contre des soucis avec la github action R-CMD-check-devel.yaml

Cf log https://github.com/ThinkR-open/fusen/actions/runs/5090267208/jobs/9148872503?pr=204

-> L'installation de {rcmdcheck} ne se fait pas (voir ligne 3067). La dépendance {curl} ne peut pas s'installer (voir à partir de la ligne 3539 pour + d'infos).

[ymansiaux]

Il semblerait que certaines dépendances systèmes nécessaire pour curl soient manquantes :

On note un problème dans la récupération des dépendances systèmes dans le fichier github actions

En théorie Ubuntu 20.04 est censé être encore supporté :
https://github.com/rstudio/r-system-requirements#operating-systems

Peut etre ouvrir une issue dédiée ?