Utiliser renv pour tous les modules ?

[jengelaere]

Bonjour à tous,

Nous avons déployé renv pour éviter les problèmes de reproductibilité, mais cela savoir assez lourd à gérer en cas de mise à jour du support. Recréer l'environnement du projet avec renv::restore peut rapidement devenir un enfer et alourdit considérablement la charge de review ou de mise à jour.
Par ailleurs, si cela nous assure la création d'un environnement valide pour l'intégration continue, cela conduit à 'fossiliser' notre support par rapport à la version des packages en cours par ailleurs, que nos stagiaires vont installer.

Pour pallier à ce problème, je vois deux pistes :

• ne plus utiliser renv
• se doter d'une doctrine d'utilisation de renv (quand doit on mettre à jour la liste des packages, travailler en désactivant...)

Avez vous d'autres idées, ou une préférence ?

[jdlom]

Quand j'ai poursuivi l'initiative lancée par Maël à savoir remplacer les CI travis en github action en utilisant renv, j'imaginai pas à quel point ca pourrait être lourd . C'est vrai que restaurer les environnements est un calvaire. Sur le fond, et même si je partage l'argument de Maël (MTES-MCT/parcours_r_socle_introduction#9 (comment)), je trouve que cette lourdeur ne favorise pas le travail des mainteneurs et même des contributeurs pour mettre à jour ces supports.

En ce qui concerne les pistes :

• sur la solution de ne plus utiliser renv

Je pense que ca faciliterait la restauration. En revanche, le jour où il y a un breaking change, ca peut tout casser. Si on utilise plus renv, figer les environnements avec docker reste nécessaire pour faciliter l'intégration continue. Faut juste voir comment on fait mais il y a la piste avec le fichier DESCRIPTION

• sur la solution de la doctrine

A la base, je l'ai pensé comme ça. J'imaginais qu'on passerait pas notre vie à modifier renv tous les 4 matins. Dans la pratique, je constate malgré tout que restaurer renv reste pénible. C'est d'ailleurs pour cela que je ne bosse plus du tout sur mon poste de travail mais que j'utilise automatiquement le sspcloud pour contribuer. J'ai développé un environnement de dev pour faciliter les contributions et j'imaginais mettre cela en place pour les futurs contributeurs.

Pour résumer, je n'ai pas forcément de préférences, je m'adapterai à la solution qui sera retenue.

[jengelaere]

Merci Jean-Daniel, ton point de vue en tant que spécialiste CI est précieux !!
C'est vrai que l'environnement déployé via le dockerfile sur onyxia est vraiment confortable d'utilisation.
En cas de breaking change, je pense qu'il vaut mieux s'en rendre compte avant la formation, que pendant ! Il y a rien de pire devant les stagiaires que de se rendre devant eux que le support n'est plus à jour et que les exemples ne fonctionnent plus 😰

[nbc]

Bonjour à tous,

Sur l'utilité d'utiliser renv::restore() je vous laisse seul juge par contre c'est toujours galère de chercher avec quelles versions des packages ça marchait avant, (mais si tu sais y a qq mois).

Pour éviter ça vous pouvez commiter régulièrement un renv::snapshot() sans forcément l'utiliser pour restaurer.

[jdlom]

Bonjour à tous,

Sur l'utilité d'utiliser renv::restore() je vous laisse seul juge par contre c'est toujours galère de chercher avec quelles versions des packages ça marchait avant, (mais si tu sais y a qq mois).

Pour éviter ça vous pouvez commiter régulièrement un renv::snapshot() sans forcément l'utiliser pour restaurer.

oui on pourrait. Rien ne nous empêche d'utiliser renv en dehors de la restauration de l'environnement pour capitaliser cette mémoire. Le souci quand même c'est que quelque fois le snapshot est aussi un peu fastidieux... mais dans une moindre mesure.

Ca peut aussi être utilise dans le cas où un stagiaire veut repartir du support et s'assurer que les exemples tournent.

Après sans s'embêter on pourrait juste utiliser la sessionInfo au moment de la compilation du book pour avoir l'information sur les packages

[jengelaere]

Je vais expérimenter pour le M7 la méthode DESCRIPTION.
Le M7 contient par ailleurs déjà une page sessionInfo.
Je vais désactiver l'environnement renv, car franchement c'est galère de ne pas avoir les addins ou usethis installés pour travailler à la mise à jour du support, on a chacun nos petites habitudes de travail avec des packages ad-hoc qui n'ont nul besoin d'être installé pour que le support se compile, c'est lourd de devoir les installer à chaque projet.
En revanche, je crois que je peux mettre à jour le renv.lock avec un snapshot et y ajouter les nouvelles dépendances sans pour autant activer l'environnement renv, je vais voir si ça peut pas suffire.