Composer e la rivoluzione batch nel mondo PHP. Gestore pacchetti Composer Cos'è Composer e come usarlo

Bene, nell'ultima lezione abbiamo effettivamente finito di scrivere il nucleo del nostro sito e da ora in poi propongo di abbandonare la costruzione di biciclette e passare ai risultati della comunità mondiale.

Vale a dire, inizia a usare gestore delle dipendenze per PHP - Compositore. Ci consentirà di installare facilmente varie cose utili sul sito, aggiornarle e persino eliminarle. Se hai già lavorato con il gestore di pacchetti GNU/Linux, tutto questo ti sarà molto familiare.

Come riscaldamento, rimuoviamo Fenomeno dalla directory core e installa tramite Composer. Per fare ciò, è necessario creare un file nella root del sito compositore.json e registrarvi i pacchetti richiesti (puoi leggere di più su Habré):
( "require": ( "php":">=5.3.0", "fenom/fenom": "2.*" ) ) Ora non ti resta che scaricare compositer.phar ed eseguirlo nella root del sito:
php compositore.phar installa su modhost.pro e non è necessario scaricare nulla: basta eseguire compositore nella directory:
compositore install E magicamente abbiamo una directory /vendor/ con Fenom installato. Cosa farne dopo?

Principio di funzionamento

Prendiamoci un momento e ti spiegherò esattamente come funziona Composer se non lo sai già.

Composer è un gestore di pacchetti che lavora con loro secondo le regole in compositore.json. Ciò che scriviamo verrà installato.

Durante l'installazione dei pacchetti, Composer segue le loro regole e genera il file più importante - /vendor/ caricamento automatico.php, che carica tutte le classi scaricate. Risulta che dobbiamo solo includere questo file nel nostro progetto e da ora in poi possiamo eseguire le nostre lezioni senza richiedere:
$Fenom = nuovo Fenom::factory($tplDir, $compileDir); Cioè, il sistema sa già dove si trova fisicamente Fenom e non abbiamo bisogno di fare reuire_once("percorso verso fenom"). Inoltre, non abbiamo bisogno di mantenere Fenom nel nostro progetto; è sufficiente memorizzare lì il nostro compositore.json.

Ancora una volta, per rinforzo:

1. Scriviamo compositore.json
2. Installa i pacchetti tramite compositore.phar
3. Ci colleghiamo al progetto /vendor/autoload.php
4. Usiamo qualsiasi classe installata tramite new Class()

Non ci sono file aggiuntivi nel progetto, nessuna richiesta aggiuntiva, i pacchetti installati vengono aggiornati tramite lo stesso compositore:
aggiornamento php compositore.phar Tutto Molto semplice e conveniente. Una volta utilizzato questo schema di lavoro, è semplicemente impossibile continuare a pedalare!

Collegamento di Fenom

Per lavorare con i pacchetti installati dobbiamo solo aggiungere autoload.php alla nostra classe Nucleo:
function __construct(array $config = array()) ( $this->config = array_merge(array("controllersPath" => dirname(__FILE__) . "/Controllers/", "templatesPath" => dirname(__FILE__) . "/ Templates/", "cachePath" => dirname(__FILE__). "/Cache/", "fenomOptions" => array("auto_reload" => true, "force_verify" => true,),), $config); / / Ad esempio, qui require_once dirname(dirname(__FILE__)). "/vendor/autoload.php"; ) Dal metodo getFenom() ora puoi rimuovere il controllo e la connessione dei file, nonché il caricamento delle sue classi. Il metodo finale è simile al seguente:
funzione pubblica getFenom() ( if (!$this->fenom) ( try ( if (!file_exists($this->config["cachePath"])) ( mkdir($this->config["cachePath"]); ) $this->fenom = Fenom::factory($this->config["templatesPath"], $this->config["cachePath"], $this->config["fenomOptions"]); ) catch (Eccezione $e) ( $this->log($e->getMessage()); return false; ) ) return $this->fenom; ) Basta chiamare Fenom::factrory e si caricherà da solo. Ecco il commit con le modifiche: guarda quanto codice abbiamo rimosso subito dal nostro progetto!

Perché dovremmo portare Fenom con noi e aggiornarlo manualmente, se Composer è stato inventato molto tempo fa, chi se ne occuperà molto meglio? Tutto ciò di cui abbiamo bisogno è metterlo alla radice del progetto compositore.json.

Ora eseguiamo il refactoring del nostro progetto in modo che si connetta anche ad autoload.php.

Allo stesso tempo, i file devono trovarsi fisicamente nelle stesse directory in modo che il caricatore sappia dove cercarli. Il modo esatto in cui funziona è descritto negli standard ufficiali, ma ti consiglio di esaminarli attentamente.

Ciò porta a due conclusioni: Composer può essere utilizzato solo in PHP 5.3+ e il nostro progetto deve essere riscritto per utilizzare gli spazi dei nomi.

Prima di tutto dobbiamo definire un nome per il nostro progetto. Lascia fare Brevis- dal latino “corto”. La nostra directory /core/ ora è lo spazio dei nomi Brevis. Significa:

• La classe Core diventa \Brevis\Core e si trova in core\Core.php
• La classe Controller diventa \Brevis\Controller e si trova in core\Controller.php
• La classe Controlles_Home diventa \Brevis\Controllers\Home e si trova in core\Controllers\Home.php
• La classe Controlles_Test diventa \Brevis\Controllers\Test e si trova in core\Controllers\Test.php

Tieni presente che la posizione fisica dei file corrisponde allo spazio dei nomi. Questo perché seguiamo già lo standard PSR-4.

Ora all'inizio di ogni classe scriviamo il namespace utilizzato. Le classi principali sono:
PhpStorm inizia subito ad evidenziare tutti gli usi di Exception e Fenom come errati, perché chiamati all'interno di un namespace, ma senza specificarne il nome completo. Sono disponibili 2 opzioni di correzione:

1. Esamina l'intero codice e aggiungi \ ai nomi di queste classi in modo che ci siano \Exception e \Fenom
2. Non soffrire con stronzate, ma usa gli alias: la possibilità di specificare un nome breve per la classe

Ovviamente scegliamo la seconda opzione:
Ora rinominiamo i controller e specifichiamo gli alias al loro interno:

Spostiamo autoload.php dalla classe \Brevis\Core a index.php, perché lo spazio dei nomi Brevis presto funzionerà tramite il caricamento automatico e non necessita di richieste aggiuntive.

Index.php ora appare così:
require_once dirname(__FILE__) . "/vendor/autoload.php"; $Core = nuovo \Brevis\Core(); $req = !vuoto($_REQUEST["q"]) ? tagliare($_REQUEST["q"]): ""; $Core->handleRequest($req);
Riscriviamo il metodo \Brevis\Core::handleRequest(), rimuovendo eventuali controlli sui file. Dobbiamo solo verificare l'esistenza di una classe utilizzando get_class():
public function handleRequest($uri) ( $request = esplode("/", $uri); $className = "\Brevis\Controllers\\" . ucfirst(array_shift($request)); /** @var Controller $controller */ if (!class_exists($className)) ( $controller = new Controllers\Home($this); ) else ( $controller = new $className($this); ) $initialize = $controller->initialize($request ); if ($initialize === true) ( ​​​​$response = $controller->run(); ) elseif (is_string($initialize)) ( $response = $initialize; ) else ( $response = "Uno sconosciuto si è verificato un errore durante il caricamento della pagina"; ) echo $response; ) Come puoi vedere, determiniamo il nome completo del controller caricato, controlliamo la sua presenza e, se non esiste un controller di questo tipo, carichiamo \Brevis\Controllers\ Casa.

In generale, tutta la logica è rimasta la stessa, ma la quantità di codice è stata ridotta. Non c'è lavoro manuale con i file, non ci sono requisiti, tutto il lavoro sulla connessione delle classi spetta a autoload.php. Di conseguenza, il parametro controllersPath scompare dalla configurazione del sistema.

Non resta che aggiungere il nostro progetto alla startup. Per fare ciò, modifica compositore.json in questo modo:
( "nome": "Brevis", "autoload": ( "psr-4": ( "Brevis\\": "core/" )), "require": ( "php": ">=5.3.0" , "fenom/fenom": "2.*" ) ) Il blocco di caricamento automatico specifica cosa caricare in aggiunta, oltre ai pacchetti installati. Chiave PSR-4 specifica esattamente come caricare il nostro progetto e specifica la directory nucleo/ come principale per lo spazio dei nomi Brevis.

Lanciamo
L'aggiornamento di php compositer.phar e le nostre classi vengono caricate automaticamente. Tutto dovrebbe funzionare, guarda le modifiche su GitHub.

Conclusione

Quindi abbiamo riscritto il nostro progetto secondo gli standard più recenti nel mondo della programmazione PHP. D'accordo, non è stato così spaventoso?

Ma ora il nostro codice è pulito, ordinato, soddisfa gli standard e funziona alla grande!

Nella prossima lezione installeremo xPDO 3.0 tramite Composer (sì, è già stato riscritto e supporta i namespace, anche se per ora solo nel ramo dev) e lo collegheremo al nostro database.

Scriviamo un diagramma, generiamo un modello basato su di esso e creiamo un paio di tabelle.

In questo post parlerò delle mie impressioni personali sull'utilizzo di una cosa così interessante come . Se qualcuno non lo sa, questo è un gestore delle dipendenze per le librerie PHP che semplifica l'installazione, l'aggiornamento e il supporto di varie librerie nel tuo progetto. Un programmatore ha bisogno di un'infrastruttura per lavorare comodamente (te lo dico con certezza: - ). Ciò include una sedia comoda, una macchina potente con due monitor e un IDE moderno, strumenti di database e strumenti di debug. Ma è importante anche l’infrastruttura di sviluppo del progetto stesso.

Prendiamo ad esempio Ruby. Questo linguaggio, dannazione, è solo un trendsetter nel campo dello sviluppo web. Esistono utili strumenti per impalcature (beh, ZF ha anche questo) e cose come il rastrello per completare le attività. Non sto nemmeno parlando di migrazioni, test unitari con ogni sorta di oggetti simulati. Quando stavo programmando in Ruby, la sensazione era come quella di sedermi in un comodo posto di business class su un aereo e il tuo unico problema era scegliere un drink adatto al tuo umore.

Stavo solo scherzando. Non tutto è così roseo in Ruby: ci sono molte gemme storte e gli sviluppatori a volte rilasciano un tale miracolo che la mamma non piange. Non sto parlando di sciamanesimo di basso livello quando è necessario creare qualcosa come un sistema distribuito o multi-thread. Ma questo post non riguarderà questo. E sul fatto che in Ruby esiste qualcosa come RubyGems.

RubyGems è un sistema per la gestione delle dipendenze in un progetto Ruby. In particolare esiste Bundler, che installa i pacchetti necessari o li aggiorna con un clic. È stato da lui che è stato palesemente copiato ed è servito da ispirazione per Composer.

Cosa può fare Composer

Quindi, una breve panoramica delle funzionalità. Ce ne sono solo due: gestione dei pacchetti e caricamento automatico delle classi. Devo dire che senza il compositore entrambi questi compiti hanno richiesto molto tempo. Internet è ancora pieno di articoli del tipo “come collegare ZF 1.x e Doctrine 2” o “come installare Doctrine 2 ODM e Doctrine 1 ORM”. Perversione, dici. Ho esagerato apposta, ma devi ammettere che devi darti un sacco di problemi per incrociare alcuni framework o librerie. Con l'uscita di Composer la situazione è cambiata.

Un ringraziamento speciale va detto per il caricamento automatico umano. Wow, quanto tempo ho dedicato una volta all'integrazione di Zend_Loader_Autoloader e Doctrine/ClassLoader. Ormai è una cosa del passato. Sediamoci su una sedia

Esempio compositore.json

Ecco un esempio di un file di dipendenze da un progetto.

( "require": ( "doctrine/common": "2.3.0", "doctrine/migrations": "dev-master", "doctrine/dbal": "2.3.0", "doctrine/orm": "2.3 .0", "doctrine/mongodb": "1.0.x-dev", "doctrine/mongodb-odm": "1.0.x-dev", "simukti/zf1": "1.12.0", "zendframework/zendframework ": "2.0.3" ), "autoload": ( "psr-0": ( "ZendExtra": "vendor/netandreus/zend-extra/lib/", "DoctrineExtra": "vendor/netandreus/doctrine-extra /lib/", "MyProject": "vendor/myvendor/myproject/lib/", "Hydrators": "misc/cache/", "": "app/default/models/" ) )

Quindi esaminiamolo riga per riga. Nel blocco require descriviamo i nomi dei pacchetti nella forma VendorName/PackageName e le versioni minime richieste per il nostro progetto. Quindi verranno scaricati e installati nella cartella del fornitore. Come puoi vedere, la Dottrina, ad esempio, è stata impacchettata in più pacchetti contemporaneamente. A proposito, le migrazioni sono state rilasciate in un pacchetto separato abbastanza recentemente, quindi resta sintonizzato per le novità sul progetto. Esprimo la mia profonda gratitudine al compagno Simukti per aver portato tutte le ultime versioni di ZF 1.x su Composer. Quando un tempo ne avevo bisogno, ho iniziato a farlo... ma non avevo mai tempo a causa di altri compiti. Ora, all'interno di un progetto, abbiamo l'opportunità di utilizzare i componenti Doctrine 2 ODM + ORM + ZF 1.x + ZF 2.x. Una vinaigrette pazzesca, ma ne abbiamo bisogno. Perché Stiamo lentamente migrando da MySQL (mi perdoni Michail Widenius) a MongoDB. La spina dorsale principale è su ZF1, ma anche ZF2 non è per vana curiosità /* intrigo */.

Ora è richiesta la seconda parte della configurazione. Qui specifichiamo le classi (o meglio i loro spazi dei nomi) e le loro posizioni di archiviazione, ad es. risolviamo i percorsi per gli spazi dei nomi corrispondenti. Si prega di notare alcune cose. Per gli idratanti della dottrina (se non sai di cosa si tratta puoi saltarla) indichiamo i percorsi, perché. con il caricatore automatico della dottrina mancante, non è possibile trovarli. L'ultima riga è la posizione del cestino, dove possono essere archiviate le classi con qualsiasi spazio dei nomi. La caratteristica principale di Composer è che (fortunatamente) può esserci solo uno di questi dump. Ma nel nostro progetto, le classi richieste sono arrivate dal nulla, quindi abbiamo dovuto effettuare, per così dire, una raccolta dei rifiuti e gettare tutto in una pila. Naturalmente, un giorno dovremo smontarlo, ma ora almeno tutta la spazzatura è in un unico posto. Bene, ZendExtra e DoctrineExtra sono le mie estensioni, che ho parzialmente descritto nei miei post.

Bug del compositore

Bene, dove senza insetti. Forse il bug più notevole. Quando, sicuro che tutto sia a posto, esegui l'aggiornamento di php compositer.phar, rimarrai... deluso. Il problema è che il compositore non scarica i sorgenti (o meglio, non li aggiorna) se è specificato il ramo dev e i sorgenti sono più vecchi di 6 mesi. Sfortunatamente, nel mio compositer.json questi erano pacchetti con dottrine. La soluzione è semplice, prima di fare un aggiornamento rimuoviamo i pacchetti con la dottrina.

Il secondo bug era che i repository di alcuni pacchetti contengono un file .gitignore, che viene scaricato durante l'aggiornamento/installazione. E se poi impegni il codice sorgente del progetto (insieme a questo pacchetto), non arriverà. Ad esempio, nell'assembly con cui sto lavorando, invece di una cartella con i sorgenti viene visualizzato un file vuoto. Allo stesso tempo, il commit e il push procedono normalmente, ma i trader si lamentano che non arriva loro nulla. La soluzione è semplice, dopo l'aggiornamento cancelliamo i file naifg .gitignore dai file sorgente con i pacchetti.

Dovrei usare Composer o no?

SÌ! Come qualcuno ha detto, la tua libreria fa schifo se non ha un file composite.json alla radice.No sul serio, sono finiti i tempi di php 4, phpclasses e un mucchio di caricatori automatici in pila. Smettiamo di produrre codice di merda, rispettiamo gli standard (beh, almeno psr-0) e scriviamo codice con un volto umano, per così dire. Sono assolutamente per l'unificazione e la standardizzazione! Godere!

Grazie!

Se questo articolo ti ha aiutato, o vuoi supportare la mia ricerca e il mio blog, ecco il modo migliore per farlo:

Cos'è e perché ne ho bisogno?

Se hai questa domanda, non leggere oltre l'articolo e prima chiedi a Google "cos'è l'iniezione di dipendenza?" e perché ne hai bisogno gestore delle dipendenze(in particolare ).

Personalmente non ho più applicazioni senza compositore. Soprattutto quando si sviluppa per un framework. Ecco solo i vantaggi fondamentali dell'utilizzo di un gestore delle dipendenze nei progetti:

• Comoda installazione e aggiornamento di pacchetti e librerie di terze parti
• Distribuzione corretta
• Il codice di qualcun altro proveniente da pacchetti di terze parti non è memorizzato nel suo repository e non sporca il codice e le statistiche
• Versioni flessibili delle dipendenze

Installazione

Qui tutto è il più semplice possibile, ma prima devi decidere il metodo di utilizzo: un compositore per l'intero localhost o ogni progetto ha il proprio compositore? (ovviamente puoi combinare)

La prima opzione è conveniente per gli sviluppatori che lavorano contemporaneamente su molte applicazioni e mantengono tutto pulito e fresco. La seconda opzione viene utilizzata quando è necessario che l'applicazione disponga di una versione accurata e uniforme del compositore per tutti gli sviluppatori, e quindi viene inserita nel repository.

Mantenere Composer insieme all'applicazione

Comandi del compositore

installare

Avendo installato e raccogliendo il tuo compositore.json puoi iniziare a installare gli stessi pacchetti che abbiamo specificato nel nostro file json nei blocchi "require" e "require-dev". Per questo usiamo il comando installare.

Installazione del compositore ./composer.phar installa l'installazione di php compositer.phar

* Il primo comando (riga 1) per chi ha scelto la modalità di installazione singola per l'intero sistema operativo. Il secondo e il terzo sono necessari a tutti gli altri e differiscono solo nel fatto che tu abbia concesso o meno i diritti per eseguire il file phar.

Quando esegui per la prima volta il comando installare riceveremo la versione più recente o esatta di tutti i pacchetti che abbiamo specificato nel file json (a seconda di come abbiamo specificato la versione per ogni singolo pacchetto). Rieseguire il comando installare non porterà a nulla - e questo è un punto importante!

Durante l'esecuzione installare scarica tutte le librerie in una cartella venditore del nostro progetto (di seguito descriverò come cambiare questo percorso), e accanto a json-con il file verrà creato un nuovo file compositore.lock(questa è un'istantanea: un'istantanea dei pacchetti installati che indica le loro versioni esatte). Cartella venditore dovrebbe essere immediatamente inserito .gitignore, in modo da non mescolare accidentalmente tutto con il tuo codice. E qui serratura- il file, invece, deve essere impegnato e inviato al repository. Se elimini una cartella venditore o alcuni pacchetti da esso e quindi richiamare nuovamente il comando installare, tutti i pacchetti verranno ripristinati esattamente con le stesse versioni installate al momento della prima chiamata installare. Questo accade perché verifica la disponibilità serratura-file, e se presenti, ignora le versioni del pacchetto specificate nel file json (solo se non erano abbassate!), e installa le versioni specificate in serratura-file.

Quindi, trasmettendo un singolo serratura-file tra tutti gli sviluppatori, il team avrà la garanzia di avere le stesse versioni dei pacchetti (non credo valga la pena spiegare il perché).

aggiornamento

Se è necessario aggiornare le versioni del pacchetto a quelle più recenti, richiamare il comando aggiornamento.

Aggiornamento del compositore ./composer.phar aggiornamento php compositore.phar aggiornamento

Dopodiché tutti i pacchetti verranno aggiornati. Verrà inoltre aggiornato serratura-file.

Vale la pena ricordare che i pacchetti verranno aggiornati in conformità con il formato della versione specificato per ciascuno di essi separatamente in json-file. La sintassi per specificare le versioni dei pacchetti è ben descritta nella documentazione ufficiale.

auto-aggiornamento

Un altro comando utile che si aggiornerà da solo .

Auto-aggiornamento del compositore ./composer.phar auto-aggiornamento php compositer.phar auto-aggiornamento

spettacolo

./composer.phar mostra -s -t ./composer.phar mostra -i -t

Questo comando visualizza un elenco di pacchetti installati.

Primo esempio (con chiave -S) mostrerà un albero di pacchetti che noi stessi abbiamo specificato manualmente json-file.

Secondo esempio (con la chiave -io) mostrerà assolutamente tutti i pacchetti installati, includendo ricorsivamente le dipendenze di tutti i nostri pacchetti originali.

Chiave -T cambia la visualizzazione della risposta a uno stile di albero delle dipendenze.

percorso del fornitore o come modificare il percorso di installazione delle librerie

Per modificare il percorso di installazione dei pacchetti, è necessario utilizzare la direttiva dir-venditore V json-file. Ecco un esempio:

( "nome": "Il mio progetto", "descrizione": "Descrizione del progetto", "homepage": "http://mio-progetto.com/", "config": ( "vendor-dir": "/vendor /custom/path" ), "require": ( "php": ">=5.3.3", "zendframework/zendframework": "2.*" ), "require-dev": ( "zendframework/zftool": "v0.1.0", "zendframework/zend-developer-tools": "dev-master" ) )

Conclusione

Ho provato a descrivere tutto ciò di base che potrebbe essere necessario per familiarizzare con Composer. È meglio studiare le funzionalità più approfondite dalla documentazione. Ad esempio: come abilitare il download della tua libreria da github.

E per trovare facilmente i pacchetti necessari, ti consiglio di utilizzare il progetto packagist.org

Se avete domande, sentitevi liberi di scrivere nei commenti.

Il mondo dello sviluppo PHP è da tempo famoso per la pratica caotica di creare sistemi dipendenti, autoprodotti e non universali. E gli aderenti ad altre lingue lo derisero. Negli ultimi anni, il che è davvero positivo, si sta muovendo sempre più verso un futuro diverso, più consapevole. La pratica della programmazione sociale tramite archivi pubblici, interessante per molti, ha introdotto l’idea di generalizzare la conoscenza acquisita.

Invece di lasciare che ogni gruppo separato di programmatori sviluppi soluzioni agli stessi problemi, ora è possibile creare un’unica soluzione comune per coprire l’intero settore contemporaneamente.

L'implementazione della nuova struttura Yii2 è stata riprogettata per funzionare con i componenti tramite Composer. Per questo motivo lo prenderemo in considerazione. Ma prima, approfondiamo un po' la filosofia e la psicologia del software open source.

Nuova programmazione

L'era dei social network e dei servizi di messaggistica Internet ha ampliato i confini della comunicazione. La presenza di archivi pubblici e sistemi di controllo della versione ha ampliato le opportunità di sviluppo. Ora qualsiasi sviluppatore di tutto il mondo può creare e migliorare qualsiasi libreria.

Cosa è necessario per una più ampia adozione della pratica dei componenti liberamente ridistribuibili? In molti modi, questo movimento è supportato dallo sviluppo della pubblicazione civile del lavoro personale negli archivi pubblici, nonché dall’introduzione di standard PSR comuni.

Allo stesso tempo, prendere in prestito strumenti validi e comprovati da altre lingue consente di sistematizzare e trasferire le migliori soluzioni in una forma più digeribile. Ed è solo l’avidità che lo impedisce?

È davvero necessario mantenere un conservatorismo di principio al limite della razionalità ed essere contrari ai prestiti nei linguaggi di programmazione? È molto più utile raccogliere l'una nell'altra le caratteristiche positive di tutte le lingue e quindi rendere tutte le lingue del mondo convenienti e più efficaci!

Invece di componenti fortemente legati all'implementazione di un framework specifico, esiste ora la pratica di creare componenti multipiattaforma o, più precisamente, indipendenti dalla piattaforma costruiti secondo i principi SOLID. Vale a dire, il movimento verso lo sviluppo a livello di interfaccia e verso la liberazione delle classi da dipendenze non necessarie. Inoltre, l'avvento dei namespace ha finalmente liberato gli sviluppatori dalla confusione dei nomi delle classi.

In precedenza, ogni framework faceva tutto in modo diverso. Aveva le proprie estensioni per autorizzazione, posta, modelli. I programmatori hanno trascorso migliaia di ore a scrivere i propri componenti e "wrapper" per adattare la libreria finita agli standard del loro sistema. Ogni framework sul proprio sito ufficiale aveva un elenco di estensioni, a volte incompatibili con altri framework. Ma ora, a causa dell'accordo generale sull'eliminazione delle dipendenze non necessarie e del passaggio di tutti i principali sviluppatori a metodi comuni di progettazione e scrittura del codice, il tempo dell'indipendenza inappropriata sta passando.

Se prima non vi era alcuna comoda continuità, nessuno scambio di componenti già pronti (tranne che per la pubblicazione su blog personali, e solo pochi, soprattutto quelli avanzati, aggiungevano addirittura il loro codice al repository PEAR), ora sempre più già pronti e i pacchetti sottoposti a debug vengono esposti al pubblico in generale.

Milioni di repository su GitHub e altri servizi simili semplificano la raccolta del set richiesto di "pezzi di ricambio" e il loro utilizzo per scrivere le tue applicazioni.

Non hai bisogno di una struttura

In cosa consiste un'applicazione web? Di cosa è fatto il quadro? Si tratta, ad esempio, di un insieme di un sistema di routing per "risolvere" indirizzi, un ORM per lavorare con un database, un contenitore per archiviare componenti, un motore di template, un logger e... una selezione di classi per lavorare con le API di sistemi diversi, invio di email e componenti aggiuntivi del servizio.

Più recentemente, o dovevi programmarlo da solo o cercare con poco successo nelle profondità dei blog. È un momento diverso adesso. Hai bisogno di un ORM? Prendi Dottrina o Propel. Hai bisogno di un motore di modelli? Prendi Ramoscello. Simile a Monolog per la registrazione e SwiftMailer per la posta. Hai bisogno di una ricerca? Scarica il componente LuceneSearch da Zend Framework o trova un driver per Sphinx. E come router puoi prendere lo stesso componente utilizzato nel framework Symfony. E così via per lavorare con autorizzazioni di social network, gateway di pagamento...

Tra milioni di repository puoi già trovare quasi tutte le implementazioni già pronte delle tue idee. Non resta che creare istanze di classi, “estrarre” componenti dal contenitore, richiedere modelli e rendere pagine. E, alla fine, “non serve un framework”, come è scritto nell’articolo omonimo qui sotto.

Rivoluzione del quadro

Il Laravel Framework, che ora sta guadagnando popolarità, sta già superando uno dopo l'altro gli altri framework. Di per sé contiene poco codice, molto leggero al suo interno a causa dell'utilizzo di un paio di dozzine di componenti pubblici stranieri nel suo lavoro. A proposito, ne abbiamo già elencati alcuni. Un sistema simile di componenti è stato utilizzato a lungo in Symfony.

Se Yii1 non lo utilizzava (a differenza di Symfony, Laravel e alcuni altri), poiché al momento della sua creazione non era ancora di moda e molte cose non erano supportate da quelle versioni del linguaggio PHP, allora la nuova versione di Yii2 ora ha vengono seguiti i principi incorporati per lavorare con vari pacchetti e standard di codifica internazionali. Ciò significa che proprio davanti ai nostri occhi si sta svolgendo la transizione necessaria per qualsiasi quadro serio. L'ingresso nel nuovo sindacato unitario è stato completato. E nel momento in cui scrivo queste righe è già stato completato! È importante. E lo scetticismo che divampa online al momento di ogni microrivoluzione in qualsiasi ambito è qui semplicemente inappropriato.

L'individualismo e la vicinanza dei diversi team di sviluppo si perdono e si trasformano a favore della sinergia globale, che consente di liberare una grande quantità di risorse e indirizzarle alla creazione di cose veramente utili a tutti.

Cos'è Compositore

La distribuzione e lo sviluppo di un'applicazione avviene molto spesso in questo modo:

Installiamo il linguaggio PHP su un computer server reale o virtuale. Ma su un interprete semplice, l'applicazione richiede componenti aggiuntivi. Installiamo librerie ed estensioni compilate tramite PEAR e Pecl, quindi scarichiamo il nostro framework dal repository. E successivamente il nostro sito inizierà a funzionare. Allo stesso tempo, ovviamente, non includiamo le librerie installate per i file di progetto nel nostro sistema di controllo del codice.

Ora dobbiamo trovare e scaricare componenti già pronti. Andiamo su GitHub o altri sistemi e cloniamo queste librerie da lì. Ma devi stare attento, poiché potrebbero dipendere allo stesso modo da altre librerie. Quindi dobbiamo studiare tutti i componenti e caricare il set completo nella nostra cartella delle estensioni. Sarebbe buona norma per gli autori dei componenti fornire un elenco di dipendenze nel file Leggimi.

Per risparmiare spazio, non è necessario che tutti questi componenti aggiuntivi siano archiviati in un sistema di controllo della versione, poiché per un progetto di grandi dimensioni la loro dimensione può ammontare a centinaia di megabyte. È sufficiente compilarli manualmente e allegare un elenco completo. Indicando la fonte e la versione funzionante. Per automatizzare il processo di download, puoi aggiungere uno script bash che clonerà i repository da questo elenco.

Il progetto ora ha diverse dozzine di estensioni di terze parti. Invece di chiamare manualmente include per ogni classe, puoi creare un caricatore automatico comune per tutte. Soprattutto se le classi utilizzano gli spazi dei nomi.

Nel tempo è consigliabile aggiornare ogni componente. Se ce ne sono dozzine, farlo manualmente sarà noioso. Questo può anche essere automatizzato con uno script della console. Dovrebbe anche essere possibile specificare restrizioni di versione specifiche nell'elenco, in modo da aggiornare solo le versioni minori e non saltare accidentalmente "troppo". Un sistema di aggiornamento automatico unico, personalizzabile e lanciato manualmente.

Questa, infatti, è la consueta pratica manuale di sviluppo di un'applicazione basata su componenti pubblici di altre persone. Come possiamo vedere, alcuni processi possono essere automatizzati, ad eccezione della presa in considerazione delle dipendenze reciproche delle biblioteche. Ma se gli sviluppatori accettano di utilizzare un unico formato di file per elencare i componenti di terze parti necessari per il funzionamento delle loro estensioni, anche questo può essere automatizzato.

Questo è esattamente ciò che fanno i gestori di pacchetti (gestire le dipendenze, scaricare e aggiornare centralmente i componenti).

All'inizio volevo registrare un video su come conoscere Composer, ma, fortunatamente per tutti, su Internet ci sono già diversi esempi decenti. Puoi visualizzarne un paio:

Quindi ora possiamo formare e integrare una certa comprensione del suo scopo. E ora possiamo anche impostare un elenco di dipendenze per il nostro progetto:

E sull'applicazione pratica, puoi anche leggere diversi materiali, incluso l'articolo sopra menzionato:

• UPD: il nostro workshop su Git e Composer.

È tutto per ora. I gestori dei pacchetti, spero, siano diventati più chiari. Se qualcosa non è molto chiaro o c'è qualcosa da aggiungere, scrivetelo nei commenti. Bene, non dimenticare di iscriverti alla newsletter per monitorare il sito. È facile e utile. Grazie in anticipo!

) è un gestore delle dipendenze per PHP relativamente nuovo e già abbastanza popolare. Puoi descrivere da quali librerie dipende il tuo progetto e Composer installerà le librerie necessarie per te! Inoltre, Composer non è un gestore di pacchetti nel senso classico del termine. Sì, funziona con entità, che chiameremo “pacchetti” o librerie, ma sono installate all'interno di ciascun progetto separatamente e non globalmente (questa è una delle principali differenze rispetto al buon vecchio PEAR).

Brevemente come funziona:

1. Hai un progetto che dipende da diverse librerie.
2. Alcune di queste librerie dipendono da altre librerie.
3. Nel tuo progetto descrivi quelle librerie da cui dipende direttamente il tuo codice.
4. Composer trova le versioni corrette delle librerie richieste per l'intero progetto, le scarica e le installa nella cartella del progetto.

Durante la creazione di Composer, gli autori hanno tratto idee e ispirazione da progetti simili: npm per Node.js e Bundler per Ruby.

È stato originariamente progettato e sviluppato da due persone, Nils Adermann e Jordi Boggiano, ora ci sono più di venti contributori al progetto. Il progetto è scritto in PHP 5.3, distribuito sotto la licenza MIT e disponibile su github.

I primi commit sono stati effettuati nell'aprile 2011 e oggi Composer è nella fase “alpha3”. Tuttavia, è già abbastanza stabile e viene utilizzato da molti progetti PHP popolari (ad esempio, Symfony2). Un elenco di progetti che utilizzano Composer può essere trovato sul sito web packagist.org: questo è il repository ufficiale dei pacchetti Composer. A proposito, alla recente conferenza Devconf 2012, lo sviluppatore del framework Yii ha menzionato nel suo rapporto che Yii2 molto probabilmente utilizzerà anche Composer.

In questo articolo descriverò brevemente le principali funzionalità di Composer e proveremo a creare un progetto demo che utilizzi Composer per caricare le librerie necessarie. Tutti gli esempi saranno disponibili su github.com e bitbucket.org.

Cosa può fare Composer?

• Scarica i pacchetti e le loro dipendenze;
• per impostazione predefinita, i pacchetti vengono scaricati dal repository ufficiale packagist.org. Chiunque può aggiungere liberamente il proprio pacchetto per rendere la sua installazione il più semplice e conveniente possibile per tutto il mondo;
• i pacchetti possono essere scaricati non solo da packagist.org, ma anche da qualsiasi repository git, mercurial o svn;
• quando si scaricano pacchetti da github.com o bitbucket.org, non è richiesto alcun sistema di controllo della versione installato (git o hg), Composer funziona tramite l'API di questi siti;
• Il repository git/hg/svn con il pacchetto può trovarsi non solo su uno dei siti sopra elencati, ma in qualsiasi altro luogo, ad esempio sulla rete locale di un'azienda o anche su un disco rigido locale;
• inoltre la libreria da installare non deve necessariamente essere sotto forma di pacchetto Composer, è possibile installarla da qualsiasi repository git/hg/svn di qualsiasi struttura;
• infine, il pacchetto da installare non deve essere un repository git/hg/svn, può essere un file zip arbitrario disponibile in qualsiasi URI!
• tutti i pacchetti vengono installati nella directory corrente (da dove è stato eseguito il comando install), questo consente di avere diverse versioni di librerie quando si lavora su diversi progetti in parallelo;
• Il comando update aggiorna tutti i pacchetti installati (o reinstalla quelli eliminati accidentalmente) alle versioni più recenti. Oppure potrebbe non essere necessario aggiornare le versioni a quelle più recenti se crei uno speciale file compositore.lock: questo ti consente di correggere una combinazione di versioni stabili di tutte le librerie utilizzate nel progetto;
• Dopo aver installato i pacchetti, viene generato automaticamente autoload.php, con il quale puoi collegare le librerie installate nel codice del tuo progetto. Quando si prepara un pacchetto Composer, si consiglia di utilizzare PSR-0, uno standard per la posizione e la denominazione dei file PHP in modo che il caricamento automatico possa trovarli facilmente. In ogni caso, l'autore del pacchetto può descrivere le regole in base alle quali il caricamento automatico cercherà file di determinate classi o spazi dei nomi. Se installi una libreria che non è impacchettata come pacchetto Composer (ad esempio, un repository git personalizzato da github), il compito di descrivere le regole di caricamento automatico ricade sulle tue spalle. Quindi non c'è magia con l'autoload.php generato: può caricare tutto (anche le librerie con un insieme di funzioni al di fuori delle classi), l'importante è che le regole siano descritte (dall'autore della libreria o da te).

Esempio di lavoro: utilizzo di Composer nel nostro progetto

Per capire come usare Composer, scriveremo un piccolo progetto in PHP: "Super Hello World". Poiché non vogliamo reinventare la ruota e scrivere codice da zero, prenderemo librerie e framework già pronti .

Utilizzeremo le seguenti librerie:

1. Microstruttura Silex
2. Motore di template Twig (disponibile come pacchetto Composer su packagist.org),
3. il nostro registratore di visite SuperLogger, che ho progettato come pacchetto Composer e pubblicato su github
4. la nostra vecchia ma amata libreria legacy superlib, che consiste in un miscuglio di classi senza spazi dei nomi e funzioni senza classi; la libreria è pubblicata su github, ma non è un pacchetto Composer in pacchetto

Come lo facevamo prima: abbiamo scaricato i framework e le librerie di cui avevamo bisogno, abbiamo pensato a dove decomprimerli, abbiamo scritto una serie di require (o require_once per affidabilità) nel progetto.

Come lo faremo ora: utilizziamo Composer: scaricherà tutte le librerie e genererà autoload.php per noi. Inoltre, se vogliamo mostrare “Super Hello World” ai nostri colleghi, basterà pubblicare il codice del nostro progetto su github (o altrove), senza includere tutte le librerie richieste nel repository e senza preparare lunghe istruzioni per installarli. I nostri colleghi dovranno solo scaricare (clonare) “Super Hello World” ed eseguire il comando
Installazione di php compositore.phar
Composer è distribuito come un singolo file compositore.phar(phar è un archivio php) - essenzialmente è uno script PHP che può accettare diversi comandi (installa, aggiorna, ...) e può scaricare e decomprimere librerie.

A proposito, qualcosa sulla sintassi di lancio.
Se utilizzi Windows, molto probabilmente scriverai qualcosa del tipo
installazione di php C:\percorso\del\composer.phar
Puoi semplificarti la vita creando compositore.bat e inserendolo in% PATH%.

Su Linux e OS X, puoi configurare un comando come
installazione del compositore

compositore.json

Quindi, siamo pronti per scrivere il nostro progetto Super Hello World. E l'ho appena scritto: http://github.com/pqr/superhelloworld. Il codice è costituito da un file index.php nella directory web e da un modello layout.twig nella directory views.

Il capo di tutto è il file compositore.json. Dovrebbe essere nella radice del progetto, nel nostro caso accanto al web e alle directory di visualizzazione. In questo file dobbiamo indicare da quali librerie dipende il nostro progetto. Inoltre, se queste librerie non sono pacchetti Composer formalizzati, è necessario fornire alcune informazioni aggiuntive sulla libreria da installare (ad esempio, descrivere le regole per il caricamento automatico delle classi e delle funzioni per autoload.php).

Composer.json, come hai intuito, ha un formato dati JSON. Alla domanda" perché JSON?"Gli sviluppatori di compositori rispondono" Perché. Accettalo e basta.".

Dobbiamo descrivere un oggetto js che conterrà tutte le istruzioni. Le prime e più importanti istruzioni: richiedere.

Colleghiamo i pacchetti da packagist.org

( "richiede": ( "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev" } }
Qui ho descritto la dipendenza del progetto da PHP versione 5.3.0 e successive, da silex (microframework) e da twig (template engine). Silex e Twig sono disponibili come pacchetti Composer su packagist.org, quindi non richiedono impostazioni aggiuntive. Noto che Silex, a sua volta, dipende da molti altri pacchetti: verranno tutti scaricati e installati automaticamente.

Il nome del pacchetto è composto da due parti separate da una barra: Nome del fornitore(nome del venditore) e nomi delle biblioteche. Il nome del fornitore è spesso il soprannome o il nome dell'azienda dell'autore. A volte, il nome del fornitore è lo stesso del nome della libreria o del framework stesso.

Per ciascun pacchetto è necessario specificare un numero di versione. Potrebbe trattarsi di un ramo nel repository, ad esempio "dev-master": il prefisso dev segnala che questo è il nome del ramo e il ramo stesso viene chiamato di conseguenza "master". Per un repository mercurial, una voce simile sarà simile a "dev-default". Puoi anche specificare regole più complesse come numero di versione utilizzando gli operatori di confronto. A proposito, se scarichi codice da un repository remoto, Composer esegue la scansione dei tag e dei nomi dei rami in quel repository per qualcosa di simile ai numeri di versione, ad esempio il tag "v1.2.3" verrà utilizzato come puntatore alla versione 1.2.3 .

Ci colleghiamo al nostro pacchetto Compsoer

Successivamente, colleghiamo il nostro pacchetto SuperLogger, che è formattato correttamente, ma pubblicato non su packagist.org, ma su github:
( "richiede": ( "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" } ] }
Per far sapere a Composer dove cercare il pacchetto "mycompany/superlogger", abbiamo aggiunto un array repository con un collegamento al repository github corrispondente. Tieni presente che le voci nell'array dei repository non sono direttamente correlate in alcun modo al blocco require: la corrispondenza tra pacchetti e repository non è specificata. Per quanto ho capito, Composer cerca tutti i pacchetti richiesti in tutti i repository specificati (incluso il sito web packagist.org) e scarica le corrispondenze trovate in base ad alcune priorità interne. Non ho ancora capito più a fondo questo punto, correggetemi se qualcuno conosce i dettagli.

Connetti un repository git arbitrario

Ora colleghiamo la nostra libreria legacy superlib, che è su github, ma non è un pacchetto Composer formalizzato, perché è molto vecchia.
( "require":( "php":">=5.3.0", "silex/silex":"dev-master", "twig/twig":">=1.8,<2.0-dev", "mycompany/superlogger":"dev-master", "pqr/superlib":"1.2.3" }, "repositories":[ { "type":"git", "url":"http://github.com/pqr/superlogger" }, { "type":"package", "package":{ "name":"pqr/superlib", "version":"1.2.3", "source":{ "type":"git", "url":"http://github.com/pqr/superlib", "reference":"master" }, "autoload":{ "classmap":["timer.php"], "files":["lib_functions.php"] } } } ] }
È stato aggiunto un oggetto all'array dei repository che descrive completamente il pacchetto pqr/superlib. In sostanza, questa è la descrizione che l'autore della libreria dovrebbe fare e inserire nel suo repository. Ma secondo i termini del compito, superlib non è un pacchetto Composer formalizzato, quindi abbiamo dovuto creare la sua descrizione come parte del progetto Super Hello World. Allo stesso modo, puoi collegare qualsiasi altra libreria, incl. semplice file zip.

Collega un semplice file zip

Ad esempio, ecco come potrebbe apparire una descrizione di una dipendenza dal motore di template Smarty, distribuito come file zip con sorgenti in svn:
( "repositories":[ ( "tipo":"pacchetto", "pacchetto":( "nome":"smarty/smarty", "versione":"3.1.7", "dist":( "url":" http://www.smarty.net/files/Smarty-3.1.7.zip", "type":"zip", "source":( "url":"http://smarty-php.googlecode.com /svn/", "type":"svn", "reference":"tags/Smarty_3_1_7/distribution/" ) ) ) ], "require":( "smarty/smarty":"3.1.*" ) )

istruzione di caricamento automatico

Torniamo al nostro progetto.
Nel descrivere "pqr/superlib", abbiamo aggiunto le istruzioni caricamento automatico. Specifica il file timer.php, in cui il futuro autoloader cercherà le classi, e specifica un file con le funzioni lib_functions.php - sarà costretto a connettersi all'inizio di autoload.php.

Quindi il nostro progetto consiste in:

• la root contiene il file compositer.json;
• le directory web e views si trovano nella root;
• all'interno della directory web è presente un file con la “logica di business” della nostra applicazione: index.php;
• all'interno della directory views c'è un file template layout.twig;
• Inoltre, nella cartella web inserisco .htaccess (per Apache) e web.config (per IIS 7.5) con le regole del rewriter mod_rewrite/url: non hanno nulla a che fare direttamente con la configurazione di Composer.

Tutto è pronto.

Esegui l'installazione del compositore

Installazione di php compositore.phar
Composer clona i repository e li decomprime nella versione desiderata in una directory venditore, che lui stesso crea alla radice del progetto. Dopo aver decompresso, nella directory del venditore troveremo:

• file autoload.php
• servizio directory.compositore e compositore
• brufolo: un pacchetto sviluppato insieme al microframework Silex
• silex è il microframework stesso, lo abbiamo esplicitamente richiesto quando descriviamo le dipendenze
• symfony - alcuni componenti di Symfony 2 richiesti per il funzionamento di Silex
• twig è un motore di template che abbiamo anche esplicitamente richiesto
• miaazienda: all'interno di questa directory ci sarà un repository superlogger scaricato da github
• pqr - all'interno di questa directory ci sarà un repository superlib, anch'esso scaricato da github

Non resta che includere autoload.php all'inizio del file web/index.php (richiede "../vendor/autoload.php") e tutte le librerie e le funzioni saranno disponibili!

Come creare il tuo pacchetto Composer?

In questo progetto abbiamo utilizzato Composer dal punto di vista del consumatore di biblioteca. Come puoi creare tu stesso un pacchetto Composer in modo che chiunque altro possa usarlo?

In effetti, ho creato uno di questi pacchetti durante la preparazione degli esempi per questo articolo. Alla radice del repository di superlogger c'è un file compositore.json di struttura simile, che descrive il pacchetto stesso e le sue dipendenze (nel caso di superlogger non ci sono dipendenze). Altri esempi: repository silex e twig, che sono stati scaricati nella cartella del fornitore - hanno tutti un file compositore.json nella radice - guarda, studia!

E, naturalmente, non dimenticare la documentazione sul sito ufficiale getcomposer.org/doc/.
Lascerò che tu studi questo argomento da solo.

Riassumiamo

In questo articolo ho spiegato cos'è Composer, la sua storia e ne ho descritto le caratteristiche principali. Abbiamo provato a creare un progetto che utilizzi Composer per installare pacchetti da packagist.org e dai nostri repository.

È ora di provarlo!

1. Scarica Composer (getcomposer.org/download/)
2. Scarica superhelloworld (git clone git://github.com/pqr/superhelloworld.git)
3. Installa le dipendenze (cd superhelloworld && php compositer.phar install)
4. Esaminare la cartella del fornitore visualizzata e il file autoload.php generato
5. Usa Composer nei tuoi progetti
   …
6. PROFITTO!!!

Un paio di link da aggiungere