Cran îl ține pe R înapoi?

Astăzi pachetul R acs a fost recent „arhivată” de la Cran. Acest lucru a dus la choroplethr Pachetul (pe care îl mențin), de asemenea, „arhivat”. Scriu „Arhivat” în citate, deoarece Cran reprezintă „Rețeaua de arhivă R cuprinzătoare”: totul pe ea face parte dintr -o arhivă și se pare că nimic nu este niciodată șters.

Puteți instala în continuare ambele pachete de la CRAN. Cu toate acestea, tastarea install.packages("choroplethr") nu va mai funcționa. Codul de mai jos instalează mai întâi versiunile binare ale dependențelor pachetului ACS de la CRAN. Apoi instalează cea mai recentă versiune „arhivată” a ACS de la CRAN de la sursă. Apoi repetă procesul pentru choroplethr:

# Install binary versions of acs' dependencies, then install acs from source
acs_imports = c("stringr", "XML", "plyr", "httr")
install.packages(acs_imports)
install.packages("https://cran.r-project.org/src/contrib/Archive/acs/acs_2.1.4.tar.gz")

# Install binary versions of choroplethr's dependencies, then install choroplethr from source
choroplethr_imports = c("Hmisc", "ggplot2", "dplyr", "R6", "WDI", "ggmap", "RgoogleMaps", "tigris", "gridExtra", "xml2", "tidyr", "tidycensus", "testthat", "choroplethrMaps", "choroplethrAdmin1")
install.packages(choroplethr_imports)
install.packages("https://cran.r-project.org/src/contrib/Archive/choroplethr/choroplethr_3.7.3.tar.gz")

Există și alte modalități de a instala pachete pe care CRAN le -a arhivat (cum ar fi utilizarea devtools sau remotes pachete). Dar această metodă, care instalează versiuni binare ale cât mai multe pachete, pare a fi cea mai rapidă.

În total, Choroplethr a petrecut 11 ani pe Cran și a fost descărcat de 289k ori de la Rstudio’s Cran Mirror (Link). Aș dori să le mulțumesc tuturor celor care au folosit pachetul și m -au ajutat să -l dezvolt. Aș dori mai ales să mulțumesc tuturor celor care au achiziționat cursurile pe care le -am creat și m -au angajat pentru instruire sau consultanță. Nu aș fi putut să iau proiectul în măsura în care am făcut fără sprijinul tău.

Acum, când Choroplethr a fost arhivat de la Cran, nu o voi mai menține. Dacă doriți să preluați funcția de întreținere, vă rugăm să mă contactați.

De ce a fost arhivat pachetul ACS?

După cum am menționat în ultima mea postare, pachetul ACS a fost arhivat pentru că generează această notă când rulați R CMD check pe ea:

NOTE
    ‘configure’: /bin/bash is not portable 
    ‘cleanup’: /bin/bash is not portable

Am fost surprins că acest lucru a dus la arhivarea pachetului pentru că:

1. configure şi cleanup Fișierele au fost introduse în ACS v2.0, care a fost lansat în 2016 (acum 9 ani).
2. Motivul principal pentru care oamenii descarcă ACS este să descarce Choroplethr. Dintre sutele de întrebări pe care le -am câștigat pe Choroplethr în ultimii 9 ani, niciunul dintre ei nu a avut legătură cu aceste fișiere.

Pe scurt: problema care declanșează această notă pare să nu provoace o problemă pentru niciun utilizator. În timp ce Cran poate arhiva un pachet din orice motiv, sunt surprins că au găsit aici analiza cost-beneficiu. Arhivarea ACS a provocat arhivarea a 3 pachete suplimentare: choroplethr, noaastormevents şi synthACS. În 2024, aceste pachete au fost descărcate de 43.037 de ori de la Rstudio’s Cran Mirror (date de la CRANLOGS).

Arhiva de Choroplethr m -a determinat să reflectez asupra rolului pe care Cran îl joacă în ecosistemul R și dacă împiedică utilizarea R cât mai pe scară largă.

Impactul lui Cran asupra pachetelor R

Limba R în sine este foarte limitată și este greu de imaginat să faci ceva interesant în el, fără acces la pachetele contribuite de utilizator. CRAN face o treabă bună de a oferi acest acces și cred că toți utilizatorii R beneficiază de acesta. Acestea fiind spuse, CRAN are, de asemenea, cerințe foarte specifice pentru pachetele pe care le găzduiește. Cred că multe dintre aceste cerințe limitează dimensiunea și complexitatea proiectelor din ecosistemul R. Iată câteva exemple din propria mea experiență:

1. Când am început Choroplethr, am lansat noi versiuni ale acesteia săptămânal. La jobul meu de zi am lansat software săptămânal, așa că mi s -a părut firesc să facem același lucru pentru proiectul meu. Cran a cerut să încetinesc rata de lansare. Ei au subliniat că politica de depozit CRAN afirmă: „Trimiterea actualizărilor trebuie făcută în mod responsabil și cu respect pentru timpul voluntarilor. Odată stabilit un pachet (care poate dura mai multe runde), „nu mai mult de 1-2 luni” pare adecvat. ” (legătură)
2. Consider Choroplethr ca un singur pachet. Dar Cran mi -a cerut să -l împărțesc în mai multe pachete diferite (choroplethrMaps, choroplethrAdmin1 şi zctaCrosswalk sunt încă pe Cran). Acest lucru a făcut dificilă actualizarea funcțiilor care au cuprins mai multe pachete: actualizările la CRAN se întâmplă secvențial și actualizarea pachetului A nu trebuie să spargă pachetul B.
3. Am scris o mulțime de viniete (adică documentație de formă lungă) care au arătat cum să folosească diferitele funcții din Choroplethr. Pentru că aceste funcții generează imagini și foloseam knitr şi rmarkdown Pentru a genera vinietele, au ocupat mult spațiu. CRAN are o limită de mărime pentru viniete. M -am terminat îndepărtându -le pe toate.

Cumulativ, se simte ca Cran dorește ca pachetele R să fie mici și să nu fie actualizate frecvent. Aceasta este alegerea lor. Dar o mulțime de proiecte interesante în spațiul de date astăzi sunt create de echipe de ingineri software. Aceste proiecte au baze de cod care sunt mult mai mari decât pachetul R tipic. Și sunt, de asemenea, actualizate mai frecvent decât permite Cran. Deoarece CRAN este metoda de facto de distribuire a pachetelor R, preocuparea mea este că politicile lor împiedică aceste proiecte să folosească R.

Distribuția pachetelor în Python

Am început să învăț cum să dezvolt pachete în Python anul trecut. Am luat un curs pe el și apoi am început să contribuit la un pachet consacrat. (Am scris o postare pe blog despre asta în ianuarie.)

Echivalentul Python al CRAN este PYPI (indicele pachetului Python). Pe parcursul cursului de dezvoltare a pachetelor, am continuat să întreb: „De la cine trebuie să primesc aprobarea pentru a împinge la PYPI? Care sunt motivele comune pentru ca aceștia să respingă un pachet? ” Oamenii m -au privit amuzant, pentru că întregul proces de publicare a pachetelor în Python este automatizat. Înapoi și înapoi pe care autorii pachet R îl au cu CRAN pare să nu existe pur și simplu în PYPI.

Popularitatea Cran vs. Pypi

Am început să mă întreb dacă această problemă – restricțiile pe care indici le plasează pe pachetele lor – ar putea afecta cantitatea și complexitatea pachetelor pe care le găzduiesc. Probabil că acest lucru este de necunoscut, deoarece există mulți factori care au impact asupra limbii pe care oamenii le folosesc pentru un proiect. Dar m -am gândit să mă uit cel puțin la ea.

Ca prim pas, m -am uitat la numărul de pachete atât în ​​CRAN, cât și în PYPI. Văd asta de astăzi:

• CRAN listează „22035 (sic) pachete disponibile” (link)
• PYPI listează „608.118 proiecte” (link)

Deci, PYPI conține un ordin de mărime mai multe pachete / proiecte decât CRAN. Dar această comparație nu este complet corectă, deoarece R este utilizat doar pentru analiza datelor și Python este utilizat în mai multe domenii.

Am devenit apoi curios de popularitatea relativă a R vs. Python pentru știința datelor. Acest lucru este, de asemenea, probabil de necunoscut. Dar putem compara numărul de descărcări de pachete populare în fiecare limbă:

• Cel mai cunoscut pachet R este probabil tidyverse. Potrivit Cranlogs, Tidyverse a fost descărcat de 1,2 milioane de ori luna trecută de la R Studio Cran Mirror (Link).
• Cel mai cunoscut pachet de știință a datelor din Python este probabil pandas. Conform statisticilor PYPI, Pandas a fost descărcat de 292 de milioane de ori luna trecută (Link).

Așadar, cel mai cunoscut pachet de știință a datelor din Python are două ordine de mărime mai multe descărcări decât cel mai cunoscut pachet de știință a datelor din R. Nu mă așteptam la asta!

În cele din urmă, m -a interesat să compar dimensiunea și complexitatea pachetelor R vs. pachetele Python. În prezent iau un curs de inginerie a datelor (Link) și am fost introduși într -o varietate de instrumente moderne de inginerie a datelor. Majoritatea acestor instrumente au fost scrise în Python și niciunul nu a fost scris în R. Având în vedere cât de bine este R la lucrul cu date, m -am întrebat de ce este acest lucru. Bănuiesc că este cel puțin parțial datorită restricțiilor pe care Cran le plasează pe pachetele sale.

Ca exemplu, am avut doar un atelier pe DLT, un pachet Python care a fost descărcat de 1,2 milioane de ori luna trecută. În timp ce mă uit prin istoricul lansării proiectului pe PYPI (link), văd că este de obicei actualizat de mai multe ori pe lună. Așadar, chiar dacă ar fi ales să -l scrie în R, nu ar fi putut să -l publice pe Cran.

În timp ce comentariile de pe blogul meu sunt dezactivate, nu ezitați să mă contactați despre această postare.