Cea mai mare parte a activității noastre în Epiverse Trace implică fie dezvoltarea unui pachet R de la zero, fie adoptarea și menținerea unui pachet R existent. În primul caz, luarea deciziilor în timpul dezvoltării este ghidată de politicile interne documentate în planurile Epiverse-Trace. Cu toate acestea, un scenariu mai puțin obișnuit pentru noi a fost preluarea întreținerii unui pachet existent – situație pe care am întâlnit -o recent cu {bpmodels}
Pachet R.
În această postare, vreau să împărtășesc câteva considerente și lecții învățate de la menținerea {BPModels}, dezvoltată inițial de Sebastian Funk la London School of Hygiene & Tropical Medicine (cu contribuții ale Zhian Kamvar și Flavio Finger) și decizia de a se retrage/ înlocuiți -l cu {epichains}. Scopul nu este acela de a defini reguli stricte, ci de a stârni o conversație despre practici suficient de bune și abordări alternative pe care comunitatea de dezvoltatori R le -a folosit sau ar dori să fie utilizată mai pe scară largă.
Una dintre primele considerente a fost domeniul de aplicare al pachetului. Atunci când se menține sau reimaginarea unui pachet R, evaluarea domeniului său de aplicare și identificarea oportunităților de perfecționare este crucială. De exemplu, unele pachete au evoluat semnificativ în ecosistemul R mai larg pentru a se alinia mai bine nevoilor utilizatorilor. Vom evidenția câteva exemple.{plyr}
a fost împărțit în {dplyr}
şi {purrr}
Pentru manipularea, respectiv a obiectelor de cadru de date și, respectiv, reflectarea funcționalității mai specializate bazate pe tipuri de obiecte. În mod similar, {reshape}
a evoluat în {reshape2}
1 și în prezent în {tidyr}
cu fiecare iterație simplificând și îmbunătățind predecesorul său. Un alt exemplu este redenumirea2 de {ggmissing}
în cei mai generalizați {naniar}
. În ecosistemul de epidemiologie, două exemple includ evoluția {EpiNow}
în {EpiNow2}
şi {incidence}
la {incidence2}
.
Pentru {BPModels}, am dorit să unificăm funcțiile de simulare (existente ca două funcții anterior) și să îmbunătățim semnătura funcției prin redenumirea mai multor argumente pentru lizibilitate. De asemenea, am dorit să introducem un flux de lucru orientat pe obiecte pentru a ajuta la interoperabilitate cu instrumente existente, cum ar fi Epicontacts și Epiparameter. De asemenea, backend-ul orientat către obiecte ne-ar permite să implementăm metode mai bune pentru imprimare, rezumare și agregare a producției de simulare. Unele dintre aceste considerente ar fi fost mai puțin perturbatoare decât altele, dar schimbarea numelui funcției și a semnăturii ar fi dus la o mulțime de perturbări, inclusiv deprecierea funcțiilor și argumentelor existente.
Un lucru este clar din exemplele privind schimbările de aplicare – ele duc adesea la schimbări de nume. O altă decizie importantă a fost dacă rebrand pachetul cu un nou nume. Un nou nume poate semnala o abordare nouă și limitările de adresă ale pachetului original. Cel mai popular exemplu este redenumirea {ggplot}
la {ggplot2}
. Alte exemple includ redenumirea {ResHape} la {ResHape2} și {Tidyr}. În cazul nostru, am decis să oferim originalul {bpmodels}
Depozit sub Epiverse-TRACE și mențineți vechiul pachet pentru a evita ruperea scripturilor care se bazează pe acesta. În același timp, am introdus {Epichains} ca succesor. Numele reflectă faptul că este un pachet pentru analiză Lanțuri de transmisie epidemiologică.
O a doua considerație cheie este planurile pe care le -ar fi putut avea autorul original al pachetului și opiniile lor cu privire la orice modificări viitoare. În cazul nostru, acest lucru a fost destul de simplu, deoarece întreținerea pachetului inițial a fost implicată pe deplin în refactorizare. Un alt autor al pachetului care a adus contribuții substanțiale ar putea fi atins și a dat aprobarea lor. Cu toate acestea, mai general, aducerea tuturor autorilor de pachete la bord cu, de exemplu, modificări ale domeniului de aplicare și nume este un pas important în luarea întreținerii unui pachet și unul care nu ar trebui neglijat.
O altă considerație tehnică a fost modul de gestionare a controlului versiunii și a comiterii istoriilor. Atunci când curgeți un pachet, este important să decideți dacă păstrați istoricul angajamentului. Opțiunile includ creșterea istoricului pentru a începe cu o ardezie curată, care riscă să piardă vizibilitatea contribuțiilor anterioare sau să eticheteze comitetul principal al depozitului original și să se construiască de acolo. Pentru {BPModels}, am ales să menținem istoria intactă pentru a păstra contribuțiile autorilor săi originali.
Pe parcursul acestui proces, ne -am inspirat din diverse surse. Raționamentul lui Hadley Wickham pentru {ResHape2} ca o repornire a {ResHape} și motivul lui Nicholas Tierney pentru redenumire {ggmissing}
la {naniar}
au fost de ajutor. În plus, o discuție la utilizator! 2024 intitulat „Retragerea pachetelor cu dependențe inversă extinse” au oferit sfaturi practice.
Această tranziție a ridicat mai multe întrebări pentru comunitate. Cum decideți dacă să înlocuiți sau să depreciați un pachet? Ce strategii au funcționat pentru menținerea compatibilității înapoi în timp ce introduceți noi instrumente? Cum documentați și comunicați modificări majore utilizatorilor? Cum se fac toate acestea, credind în mod corespunzător contribuțiile anterioare și păstrați descoperirea și urmărirea/utilizarea urmăririi?
Ne -ar plăcea să vă auzim gândurile și experiențele. Să începem o conversație despre menținerea și evoluția instrumentelor open-source într-un mod durabil.
Reutilizați
Citare
Citarea Bibtex:
@online{mba_azam2025, author = {Mba Azam, James and Funk, Sebastian}, title = {Key Considerations for Retiring/Superseding an {R} Package}, date = {2025-02-03}, url = {https://epiverse-trace.github.io/posts/superseding-bpmodels/}, langid = {en} }
Pentru atribuire, vă rugăm să citați această lucrare ca:
MBA Azam, James și Sebastian Funk. 2025. „Considerații cheie pentru retragerea/înlocuirea unui pachet R.” 3 februarie 2025. Https://epiverse-trace.github.io/posts/superseding-bmodels/.