Organizarea dezvoltării R folosind SRCPKGS

Prezentare generală

Aceasta este o introducere a organizării proiectelor R folosind pachete sursă (alimentat de pachetul meu R srcpkgs). Se bazează pe note pentru o discuție pe care o am pe 2024-05-27 pentru întâlnirea de analiști ai grupului Bioinformatics Vital-IT.

Obiectivul este de a organiza proiecte R pentru:

• Cod de reutilizare
• Cod de partajare
• crește robustetea
• Activare analiză (cod) Reproductibilitate

Contextul este în mare parte pentru proiecte R orientate spre analiză.

În ceea ce privește evoluția naturală a proiectelor de cod …

Opinia mea despre evoluția generală a proiectelor de analiză:

• Începi cu un script unicsecvențial, fără funcții

• La un moment dat (după ce ai scris sute sau mii de linii) îți dai seama că ai nevoie de unele Funcții

• Apoi începeți să reutilizați aceste funcții pe proiecte prin copie/lipire. Acest lucru ridică o serie de probleme

  • Versiune: la un moment dat veți rezolva sau îmbunătăți o astfel de funcție
    • Poate fi dificil să ne amintim ce proiect conține cea mai recentă versiune
    • Ce dintre proiectele care conțin versiunile incorecte?

• Atunci poate doriți, dacă lucrați într -o echipă, să partajați acest cod cu colegii sau să le folosiți

  • -> necesită unele documentarechiar și ticălos.
  • există o creștere responsabilitate. Ce se întâmplă dacă codul dvs. este greșit și are un impact asupra proiectelor colegilor dvs.? Un remediu este să scrieți teste pentru aceste funcții.
  • Aceste funcții sunt rareori independente, astfel încât nu puteți alege doar una
  • Toate aceste funcții sunt expus (adică public sau exportat)
    • Dacă începeți să utilizați o funcție de nivel scăzut în proiectul dvs. și că în următoarea versiune a fost refactorată și că această funcție a fost modificată sau eliminată, actualizarea codului partajat va rupe proiectul.

• Din toate aceste motive, începeți să vă împachetați codul reutilizabil ca Pachet R.

  • Puteți adăuga documentație, teste, cod de grup logic. Aduce un spațiu de nume, astfel încât să puteți decide ce expuneți.

• Dar … nu rezolvă cu adevărat versiune problemă

  • În R, pachetele trebuie să fie instalat (de exemplu, folosind install.packages()) înainte de a le putea folosi cu library(mypkg)
  • Pachetele au un număr de versiune (NB: acesta nu este același lucru cu Versiunea de cod)
  • Dacă utilizați versiunea v1 în proiectul A și versiunea V2 în proiectul B, trebuie să jonglezi cu versiunile (Instalare/Dezinstalare), desigur, există câteva instrumente pentru a face față acestora (Renv …), dar lucrează cu pachete externe (sau ai nevoie de câteva depozite personalizate private)
  • Și este foarte greoi. Să presupunem că, în proiectul dvs., găsiți o eroare în pachetul (instalat). Pentru a -l repara, trebuie
    • Obțineți codul sursă al pachetului
    • Încercați să vă reproduceți problema. Șansele sunt că aveți nevoie de datele proiectului dvs., trebuie să vă reproduceți sesiunea
    • În cele din urmă, dacă reușești să -l rezolvi. Trebuie să -l publicați, să -l instalați.

• Abordarea mea este să folosesc ceea ce numesc Pachete sursă

  • Sunt pachete R normale, dar în loc să le instalați pe sistemul dvs. R, le încărcați direct de la sursa din sesiunea R.
  • a fost posibil de către infam Hadley Wickhamși al lui devtools::load_all() Funcție, care imită încărcarea unui pachet instalat
  • Acest lucru ajută foarte mult la toate aceste probleme:
    • Îți încorporați pachetele sursă în cadrul proiectului dvs. (ca submodule Gitvom vedea asta mai târziu) Acest lucru rezolvă versiunea/reproductibilitatea la nivelul codului reutilizabil: toate proiectele dvs. pot utiliza o versiune diferită
  • Dacă trebuie să remediați o eroare sau să vă îmbunătățiți și să vă sporiți codul reutilizabil, este simplu ca editarea codului pentru proiectul dvs. Și folosind srcpkgsputeți chiar reîncărca cu ușurință codul în sesiunile R existente, fără a pierde date calculate.

• Până acum, bine. Apoi, pentru o ușurință de întreținere/modularitate, începeți să vă împărțiți codul reutilizabil pe categorie și să dezvoltați mai multe pachete R, de exemplu, unul pentru unele utilități DIDID, unul pentru încărcarea datelor din baza de date, una pentru o analiză specifică …

  • Aici srcpkgs devin utili, de când devtools a fost conceput pentru a gestiona un Pachet sursă unic Rnu o colecție/bibliotecă de pachete posibil inter-dependente.
    • În plus, are un mic hack util care vă permite să utilizați standardul library() Funcție pentru a încărca pachetele sursă. Astfel încât atunci când analizați este finalizat sau implementat în producțiecu pachetele dvs. instalate în mod standard, scriptul dvs. va continua să se uzeze fără nicio modificare.

• Dar acest lucru nu rezolvă reproductibilitate pentru pachetele externe

  • Codul dvs. și biblioteca sursă folosesc cu siguranță pachete externe și depind și de versiunea dvs. R (și astfel de Bioconductor versiune)
  • De asemenea, poate depinde de arhitectura sistemului de operare (CPU …)
  • Acest lucru este în afara domeniului de discuție, dar o soluție pentru aceasta este să folosești un mediu de dezvoltare virtualizat: a docher Container (CF https://rocker-project.org/) care conține o versiune fixă a Rși din toate pachetele externe necesare.
  • Acum provocarea este de a sincroniza acea versiune de container Docker cu versiunea dvs. de bibliotecă sursă …
  • De asemenea, CF DevContainers

Configurarea mea recomandată de proiect

• sursa bibliotecă de pachete R.
  • ar trebui să fie un un singur depozit GIT dedicat
    • Recomandat, deoarece este mai ușor să ai versiuni consistente ale pachetelor interdependente
    • dar fiecare pachet ar putea fi în propriul său depozit GIT, dacă este necesar
  • Fiecare pachet ar trebui să conțină teste (Foarte important, chiar dacă este contra intuitiv, dar, de obicei, există mai multă valoare în suita de testare decât în codul în sine, nu mă începe să pornească pe asta …)
  • pentru pachete interne, în special pentru un public de dezvoltatori, personal, că documentare este mai puțin important, de exemplu, pentru un pachet lansat public.
  • ar trebui să utilizați CI (Integrare continuă, cum ar fi GitHub Actions sau Gitlab CI) pentru a rula automat testele automatizate de fiecare dată când împingeți către depozit.
  • De asemenea, raportarea acoperirii testului este importantă
• cod de proiect
  • Trebuie să fie versiunea într -un depozit Git (în GitHub/Gitlab …): un depozit pe proiect
  • ar trebui să fie el însuși un pachet R (sursă)
    • mai ușor de adăugat teste, documentație, viniete
  • dar poate fi un singur script sau un set de fișiere sursă
  • conține o versiune dată (angajament/etichetă/sucursală) a bibliotecii sursă ca Submodula Git
  • ar trebui să conțină un vscode DevContainer pentru a executa codul proiectului (utilizabil automat prin intermediul Github Codespaces)
• Codul proiectului R va folosi apoi srcpkgs pachet, care va fi automat descoperi Pachetele R conținute în folderul proiectului și le încarcă transparent folosind tocat library() Funcționează ca și cum ar fi instalat pachete.

Eu (Karl Forner) lucrez în prezent ca consultant, mă contactez dacă doriți să vă ajut să utilizați R, organizarea dezvoltării, dezvoltarea de pachete R sau, în general, susțin eforturile dvs. de dezvoltare software.