Tales from Open Source Development II: Un pachet de care depindeți este arhivat

Arhiva oaqc

Tocmai când problemele din jur timeless au fost rezolvate, am primit încă un e-mail de la CRAN.

Dragă întreținător,

Vă rugăm să vedeți problemele afișate pe https://cran.r-project.org/web/checks/check_results_graphlayouts.html.

Vă rugăm să corectați înainte de 2024-10-07 pentru a vă păstra pachetul în siguranță pe CRAN.

Nu uitați să vă uitați la orice „probleme suplimentare”

Pachetele din Suggest ar trebui să fie folosite condiționat: vezi „Scrierea extensiilor R”. Acest lucru trebuie corectat chiar dacă pachetele lipsă devin disponibile. Poate fi testat verificând cu R_CHECK_DEPENDS_ONLY=adevarat.

Echipa CRAN

Eroarea afișată a fost ceva de genul

Package oaqc not found

Am aflat că pachetul a fost arhivat, deoarece adresa de e-mail a autorilor nu mai era valabilă.

Consecință pentru graphlayouts

The oaqc pachetul este sugerat în graphlayouts, cel mai utilizat pachet dintre toate pachetele pe care le întrețin. De asemenea, este importat în ggraph. Așa că am avut un ușor atac de panică pentru că nu eram sigur cum să remediez asta. Părea că a preluat întreținerea oaqc pachetul părea cea mai bună soluție pe termen lung. Soluția mea pe termen scurt a fost să port codul relevant la graphlayouts astfel încât să rămână cel puțin pe CRAN, dându-mi timp să rezolv problema de bază.

Urmare

Acest incident m-a făcut să mă gândesc la un scenariu ipotetic:

Ce se întâmplă dacă nimeni nu ar rezolva problemele raportate pe CRAN și pachetele sunt arhivate?

Partea interesantă a acestui experiment de gândire este ceea ce mi s-a întâmplat: arhivarea unui pachet ar putea declanșa starea „la risc” a altuia, și anume dacă importă (sau sugerează) pachetul arhivat. Dacă nici aceste pachete nu rezolvă această problemă, ele vor fi de asemenea arhivate și vor declanșa din nou un nou val de pachete „la risc”. În cele din urmă, această reacție în lanț va duce la situația în care rămân doar câteva pachete care nu importă/sugerează altele.

Așa că am creat ceasul apocalipsei CRAN care calculează momentul în care este atins momentul în care CRAN conține doar pachete fără dependență, pe baza pachetelor curente cu risc de a fi arhivate.

Ceasul se resetează în fiecare zi la prânz, deoarece – nu este surprinzător – majoritatea întreținerii chiar remediază problemele. Cu toate acestea, pot apărea și noi probleme în pachetele anterior sigure.

Addendum

Puriștii vor lua acest incident ca exemplu pentru lucrurile rele care se pot întâmpla atunci când adăugați prea multe dependențe, numite și iadul dependențelor. Pentru R, există comunitatea tinyverse, care încearcă să pledeze pentru cât mai puține dependențe în pachetele R. Eu personal încerc să urmez reguli simple pentru a decide dacă ar trebui să depind de un pachet sau nu:

• Este pachetul bine întreținut de un grup mai mare de menținători și mă pot aștepta ca aceștia să se mențină „la nesfârșit”?
• Este pachetul utilizat pe scară largă și sunt șanse mari ca utilizatorii să-l aibă deja pe sistemul lor?

Fac o excepție de la această regulă, de exemplu, când vine vorba de dplyr. De fapt, ar îndeplini ambele cerințe, dar pentru mine, acest pachet este orientat spre aplicație și nu spre dezvoltare. Deci, dacă trebuie să disput niște data.frames în pachetele mele, recurg la baza R.

O întrebare importantă pe care mi-o pun mereu este: „De câtă funcționalitate a pachetului am nevoie de fapt?”. Deci are sens să importe stringrcând tot ce am nevoie este str_wrap()? În acest tip de situații, de obicei încerc să implementez eu funcționalitatea. Excepțiile sunt atunci când performanța contează. Deci, dacă am o funcție care apelează o funcție critică de 1 milion de ori, aș prefera să import pachetul cu o soluție de înaltă performanță în loc să implementez eu o soluție suboptimă. Cheia aici este să vă profilați codul.