Oui oui, les metadata des systèmes de paquets sont très (trop) stricts avec les dépendances.
Ceci dit, ces histoires de versions de dépendances, c'est bien, mais ça n'est pas magique. Souvent ça encourage les développeurs à être très restrictifs (par exemple, si on utilise la version 1.2.3 du paquet Truc, alors on force la version 1.2.3, comme ça on est sûr que ça marche... et on est sûr d'emm* tous les utilisateurs).
En tant qu'utilisateur très régulier de R, je suis en désaccord sur un certain nombre de points avec la politique des dev de R core. Typiquement, les devs R considèrent que la "bonne manière" de faire les choses et de distribuer des paquets pour n'importe quel projet, ce qui, en effet, permet de bien structurer l'arborescence des projets, d'améliorer la reproductibilité, etc. Malheureusement, cette manière de travailler est aussi très rigide et très technique; pour qu'un paquet passe les checks il faut une documentation très rigide, et la moindre tâche devient pénible (par exemple, imaginons qu'on souhaite ajouter un paramètre optionnel à une fonction pour tester un truc : il faut modifier la fonction, modifier la doc, parfois modifier les metadata si on utilise une dépendance, reconstruire le paquet, le recharger dans son script de test (éventuellement avec les outils de R-devel si on ne veut pas réinstaller le nouveau paquet), et exécuter sa fonction. Zut, il y a une faute de frappe. Rebelotte, reconstruire le paquet, etc. C'est un workflow pourri de chez pourri, ça revient à perdre tous les avantages d'un langage de script où on colle ses constantes, ses dépendances, ses fonctions, et son code dans un même fichier, on exécute, et basta. Évidemment, il existe des utilitaires qui permettent d'automatiser un peu tout ça, mais ça revient à coller des pansements sur une jambe de bois.
Pourtant, les devs utilisent l'existence de ce système de paquets (qui est excellent pour, en effet, distribuer des paquets) pour nier l'évidence sur les besoins des utilisateurs. Par exemple, il semble que n'importe qui utilisant R pour des projets de taille moyenne (quelques mois de travail personnel par exemple) a besoin de structurer son code en plusieurs fichiers, qui peuvent s'appeler les uns les autres. Or, il n'existe aucune fonction dans R pour gérer les chemins d'appel des scripts de manière fiable (en gros, pour connaitre le chemin complet du script qu'on est en train d'exécuter, il faut sans utiliser des variables système-spécifiques cachées dans les paramètres environnementaux). La réponse des devs est systématiquement "vous n'avez qu'à utiliser les paquets", et je ne comprends pas pourquoi. C'est un peu la même chose pour la gestion des environnements (qui définissent la visibilité des variables), qui reste cryptique et incohérente, mais qui est sans cesse renvoyée dans les dents des gens qui se plaignent des incohérences du langage.
Je trouve ça un peu moche quand les devs d'un langage tellement utilisé ont du mal à comprendre les besoins de leurs utilisateurs (mais c'est souvent inévitable : les devs sont de très bons techniciens et ils connaissent parfaitement toutes les subtilités de leur outil, il est très difficile pour eux de comprendre pourquoi certaines procédures sont totalement hermétiques aux utilisateurs "normaux").
[^] # Re: Ma plus commune erreur
Posté par arnaudus . En réponse au journal Gnu R version 4.0.0 est disponible. Évalué à 3.
Oui oui, les metadata des systèmes de paquets sont très (trop) stricts avec les dépendances.
Ceci dit, ces histoires de versions de dépendances, c'est bien, mais ça n'est pas magique. Souvent ça encourage les développeurs à être très restrictifs (par exemple, si on utilise la version 1.2.3 du paquet Truc, alors on force la version 1.2.3, comme ça on est sûr que ça marche... et on est sûr d'emm* tous les utilisateurs).
En tant qu'utilisateur très régulier de R, je suis en désaccord sur un certain nombre de points avec la politique des dev de R core. Typiquement, les devs R considèrent que la "bonne manière" de faire les choses et de distribuer des paquets pour n'importe quel projet, ce qui, en effet, permet de bien structurer l'arborescence des projets, d'améliorer la reproductibilité, etc. Malheureusement, cette manière de travailler est aussi très rigide et très technique; pour qu'un paquet passe les checks il faut une documentation très rigide, et la moindre tâche devient pénible (par exemple, imaginons qu'on souhaite ajouter un paramètre optionnel à une fonction pour tester un truc : il faut modifier la fonction, modifier la doc, parfois modifier les metadata si on utilise une dépendance, reconstruire le paquet, le recharger dans son script de test (éventuellement avec les outils de R-devel si on ne veut pas réinstaller le nouveau paquet), et exécuter sa fonction. Zut, il y a une faute de frappe. Rebelotte, reconstruire le paquet, etc. C'est un workflow pourri de chez pourri, ça revient à perdre tous les avantages d'un langage de script où on colle ses constantes, ses dépendances, ses fonctions, et son code dans un même fichier, on exécute, et basta. Évidemment, il existe des utilitaires qui permettent d'automatiser un peu tout ça, mais ça revient à coller des pansements sur une jambe de bois.
Pourtant, les devs utilisent l'existence de ce système de paquets (qui est excellent pour, en effet, distribuer des paquets) pour nier l'évidence sur les besoins des utilisateurs. Par exemple, il semble que n'importe qui utilisant R pour des projets de taille moyenne (quelques mois de travail personnel par exemple) a besoin de structurer son code en plusieurs fichiers, qui peuvent s'appeler les uns les autres. Or, il n'existe aucune fonction dans R pour gérer les chemins d'appel des scripts de manière fiable (en gros, pour connaitre le chemin complet du script qu'on est en train d'exécuter, il faut sans utiliser des variables système-spécifiques cachées dans les paramètres environnementaux). La réponse des devs est systématiquement "vous n'avez qu'à utiliser les paquets", et je ne comprends pas pourquoi. C'est un peu la même chose pour la gestion des environnements (qui définissent la visibilité des variables), qui reste cryptique et incohérente, mais qui est sans cesse renvoyée dans les dents des gens qui se plaignent des incohérences du langage.
Je trouve ça un peu moche quand les devs d'un langage tellement utilisé ont du mal à comprendre les besoins de leurs utilisateurs (mais c'est souvent inévitable : les devs sont de très bons techniciens et ils connaissent parfaitement toutes les subtilités de leur outil, il est très difficile pour eux de comprendre pourquoi certaines procédures sont totalement hermétiques aux utilisateurs "normaux").