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.
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:
introducerea unui suport robust şi solid pentru namespace-uri în cadrul versiunii 5.3 a PHP-ului
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.
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.)
php sau php-64bit
maşina virtuală HipHop
extensii php
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ă:
sub formă exactă (e.g. 1.2.3)
interval (e.g. >=1.0 <2.0)
Pe lângă constângerile de bază, mai pot fi folosiţi doi operatori (next significant release operators):
“~” marchează versiunea minor minimă de care depindem şi lasă ultima cifră specificată să fie incrementată. (e.g. ~1.2.3, care este echivalent cu >=1.2.3 <1.3.0 )
“^” marchează versiunea majoră maximă acceptată care nu introduce incompatibilităţi majore (e.g. ^1.2.3, care este echivalent cu >=1.2.3 <2.0.0). Acest operator se potriveşte perfect pachetelor care implementează regulile versionării semantice
Stabilitatea unui pachet
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:
ca valoare a opţiunii minimum-stability în composer.json . În acest caz, acele versiuni ale pachetelor care sunt sub valoarea minimă setată vor fi ignorate la stabilirea versiunilor pachetelor. Este de reţinut faptul că, dacă pachetele de care depindem au şi ele la rândul lor specificată o astfel de valoare în composer.json-ul lor, aceasta va fi ignorată.
prin flag-uri de stabilitate pentru fiecare pachet în parte (1.0.*@dev, ~2.2.0@beta etc.)
Autoloading
Î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.
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ă:
Satis-ul presupune folosirea conexiunilor intranet, care sunt superioare în ceea ce priveşte latenţa şi viteza.
multe companii dezvoltă pachete care sunt intenţionate doar pentru uz intern. Un sistem Satis este soluţia perfectă pentru a nu fi obligaţi să publicăm pachetele pe Packagist.
Comenzi
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.
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.
de Ovidiu Mățan
de Cristina Juc
de Ioana Luțaș
de Ovidiu Mățan
