ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 125
Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ 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.

VIDEO: NUMĂRULUI 125

Sponsori

  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Colors in projects

VIDEO: EXTRA