TSM - Composer și Packagist, vedetele PHP-ului
ABONAMENTE VIDEO TESTE REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 44
Abonament PDF

Composer și Packagist, vedetele PHP-ului

Radu Murzea
PHP Developer
@Pentalog



Cătălin Criste
PHP Developer @Pentalog
PROGRAMARE


PHP-ul are o istorie destul de zbuciumată în ceea ce priveşte managementul pachetelor. Aceasta a urmat să se schimbe la începutul anului 2012, când s-au lansat proiectele Composer şi fratele său, Packagist. 

În acest articol, vă vom introduce în  frumoasa lume şi istorie a managementului pachetelor în PHP-ul modern.

Puţină istorie

Un sistem de management al pachetelor nu a existat în lumea PHP până la începutul anului 2000, când Stig Bakken a început proiectul PEAR ca urmare a discuţiilor purtate la Tel-Aviv în cadrul conferinţei PHP Developers Meeting.

Principiul de funcţionare al PEAR-ului era încorporarea unui manager direct în runtime-ul limbajului PHP şi instalarea dependinţelor dorite folosind linia de comandă. Dependinţele erau aduse împachetate în arhive şi erau folosite în proiecte prin folosirea instrucţiunilor de “include” sau “require”.

Pentru îmbunătăţirea performanţei aplicaţiilor, PECL a fost lansat în octombrie 2003. Acest sistem permitea compilarea librăriilor PHP în programe C, urmând a fi folosite prin PEAR ca extensii ale PHP-ului. Motivaţia pentru acest sistem a fost faptul că programele C au performanţă superioară în comparaţie cu codul interpretat al PHP-ului.

Utilizarea de cod prin PEAR şi PECL era dificilă din cauza lipsei standardelor de codare, dificultăţilor de contribuire la proiecte existente şi modului greoi în care puteau fi folosite librăriile şi extensiile. În ciuda acestui fapt, PEAR a crescut în popularitate datorită deţinerii unui monopol a acestei funcţionalităţi.

Ca urmare a acestui suport precar, cei mai mulţi programatori au decis pur şi simplu să nu folosească acest manager de pachete şi au recurs la a se baza doar pe functionalităţile oferite de framework-ul în care lucrau, în special datorită boom-ului framework-urilor PHP în perioada 2004 – 2006. Această practică nu adus decât o cuplare excesivă între framework şi aplicaţia dezvoltată, migrarea către un alt framework sau renunţarea completă la unul fiind extrem de dificilă.

Toate acestea ne conduc în anul 2009, un an cu o semnificaţie istorică majoră în lumea PHP. Atunci au avut loc două evenimente relevante:

Brusc, aceste schimbări au eliminat o parte din dezavantajele majore ale PEAR-ului şi au deschis drumul către ecosistemul PHP modern care-l cunoaştem astăzi.

Printre altele, a început dezvoltarea proiectelor Composer şi Packagist, prima lansare a unei versiuni funcţionale a acestora având loc în Martie 2012. Ele au fost dezvoltate de către Nils Adermann şi Jordi Boggiano, cei doi continuând mentenanţa acestora până în ziua de astăzi.

Mecanisme de funcționare

composer.json

Pentru a folosi composer într-un proiect, e nevoie să creăm un fişier denumit composer.json. Acest fişier descrie pachetele de care depinde proiectul, dar poate conține şi alte meta-informații.

Unul dintre cele mai importante câmpuri din acest fişier este câmpul require. Prin acesta, specificăm pachetele de care proiectul nostru depinde:

„require”: {
    „monolog/monolog”: „1.0.*”
}

De multe ori, câmpul require este tot ce avem nevoie pentru a ne configura dependenţele proiectului. Pentru lista completă de câmpuri disponibile în cadrul fişierului composer.json, puteţi consulta schema din documentaţia composer-ului.

Pe lângă pachetele externe, se pot specifica ca dependenţe şi pachete de platformă. Acestea sunt nişte pachete virtuale pentru ceea ce este instalat pe system.(Nu sunt instalate de Composer.)

Pentru a vedea pachetele de platformă disponibile pe sistemul local, putem folosi comanda composer show --platform.

Instalarea pachetelor

Instalarea pachetelor se face rulând comanda composer install.

La prima execuţie a comenzii, Composer va încerca să determine care versiune să descarce pentru fiecare pachet specificat astfel încât toate cerinţele de versiune şi stabilitate să fie satisfacute. Aceasta poate fi o problemă dificilă pentru că, în practică, multe pachete depind unele de altele, iar legăturile dintre ele sunt deseori menţionate în moduri diferite (vezi capitolul despre operatori).

Sistemul prin care Composer parcurge acest pas este printr-un algoritm de rezolvare a satisfiabilităţii booleen-e. Prin urmare, aceasta este o problemă a cărei complexitate creşte exponenţial cu numărul de pachete care trebuie instalate.

composer.lock

După rularea comenzii de instalare, vom observa că un nou fişier a fost creat: composer.lock. Rolul acestui fişier este de a stoca versiunile exacte ale pachetelor instalate, făcând o “încuiere” a acestora (de unde şi numele). Astfel, toate persoanele care vor folosi acest proiect vor avea instalate exact aceleaşi versiuni ale tuturor pachetelor.

Fişierul .lock conţine hash-ul fişierului .json din care a fost generat. Prin urmare, dacă fişierul .json, s-a modificat, următoarea execuţie a comenzii composer install va afişa o atenţionare cu privire la desincronizarea celor două fişiere.

Având un astfel de fişier uşurează de asemenea instalarea pachetelor, deoarece comanda composer install va sări peste procesul complex de rezolvare a versiunilor dacă detectează prezenţa fişierului .lock.

Operatori de versionare a unui pachet

Versionarea semantică (major.minor.patch) este acum considerată o practică ideală în lumea PHP. Prin urmare, pachetele în general respectă această convenţie.

Versiunea unui pachet poate fi specificată prin constrângeri de bază:

Pe lângă constângerile de bază, mai pot fi folosiţi doi operatori (next significant release operators):

Composer permite inclusiv instalarea pachetelor cu o variată stare de stabilitate. Valorile posibile, în ordine crescătoare a stabilităţii, sunt: dev, alpha, beta, RC şi stable. Această valoare poate fi specificată în 2 moduri, care nu se exclud:

În capitolul despre istoria manager-elor am menţionat ca suportul corect şi complet pentru namespace-uri introdus în versiunea PHP 5.3 a fost ultimul ingredient necesar pentru naşterea unui manager de pachete robust şi cu adevărat util. Namespace-urile sunt, printre altele, felul corect de a integra cod 3rd-party în propria aplicaţie, eliminând folosirea operatorilor “include” şi “require”.

Composer va construi un autoloader de namespace-uri pentru proiectul nostru şi pentru pachetele de care depindem pe baza informaţiilor trecute în câmpul autoloading din composer.json. Această informaţie poate fi specificată în trei feluri: prin definiţie PSR-0, prin definiţie PSR-4 şi prin corelare între namespace şi fişier; acestea pot fi combinate în orice fel se doreşte.

Surse ale pachetelor

Packagist

Packagist este repository-ul central care conţine toate pachetele disponibile pentru instalare, fiind folosit în mod implicit pentru descărcarea pachetelor. Acestea sunt de obicei adăugate şi administrate de către autorii acestora. Packagist necesită ca sursa pachetelor să fie un repository Git, binenţeles public. Se obişnuieşte ca această sursă să fie pagina de GitHub a respectivului pachet, dar acest lucru nu este obligatoriu.

Satis

Satis-ul este o variantă simplificată a Packagist-ului care poate fi instalată într-un sistem privat. Sunt două motive principale pentru care folosirea Satis-ului poate fi benefică:

Până acum am cunoscut o parte din funcţionalităţile oferite de comenzile install şi show, însă Composer oferă o varietate de comenzi.

Pe scurt, comenzile ne ajută să efectuăm cu uşurintă o varietate de operaţiuni uzuale necesare în contextul unui manager de pachete. Aceasta poate să includă iniţializarea unui nou proiect, adăugare şi ştergere de pachete, verificarea dependenţelor între pachete, regenerare de informaţii pentru autoloading, modificare de setari ale Composer-ului şi multe altele. Vă invităm să consultaţi documentaţia pentru a vedea lista completă şi detaliată a acestora.

Pe final...

Composer împreună cu Packagist, e un manager de pachete modern şi robust, care ne pune la dispoziţie toate facilităţile necesare fără a sacrifica simplitatea şi curba foarte uşoară de învăţare.

Acesta a fost scânteia necesară pentru ca PHP-ul să poată adopta multe practici moderne de dezvoltare software. Este de departe unul dintre cele mai importante proiecte din ecosistemul PHP-ului.

LANSAREA NUMĂRULUI 74, CLUJ

Prezentări articole și
Panel: Autonomous driving

Miercuri, 22 August, ora 18:00
sediul Bosch, str. Someșului 14

Înregistrează-te

Facebook Meetup

Sponsori

  • kronsoft
  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • Crossover
  • MHP
  • BCR
  • Itiviti
  • Connatix
  • MicroFocus
  • Colors in projects