Enkel pakkehåndtering med komponist

La oss innse det: PHP har hatt en steinete historie med pakkeledelse, og som et resultat er det ganske sjelden å finne en utvikler som aktivt bruker systemer som PEAR. I stedet har de fleste utviklere valgt sitt favorittramme, som har kode spesifikt skrevet for å håndtere forskjellige ting, som DB-interaksjon, ORM, OAuth, Amazon S3-integrasjon, etc.

Ulempen her er imidlertid at bytte av rammer (eller tilbake til ikke å bruke et rammeverk i det hele tatt) kan være et mareritt, da det innebærer å gjenopplive alt for å bruke helt nye verktøy - og det er ingen lett oppgave. Vel, komponisten kan fikse det!


Introduksjon

"Limet mellom alle prosjekter."

Komponisten setter opp for å løse denne situasjonen ved å posisjonere seg som "limet mellom alle prosjekter" - noe som betyr at pakker kan skrives, utvikles og deles i et format som andre utviklere kan plugge inn i andre applikasjoner med letthet.

Denne artikkelen beskriver hvordan du installerer og jobber med Composer-pakker. Ved slutten av denne artikkelen vil du kunne koble til og spille med biter av kode i alle rammer, uansett om du jobber med CodeIgniter, FuelPHP, Laravel, Symfony2, Litium, Yii, Zend ... eller noe annet.


Trinn 1 - Installere Komponist

Komponist har to hovedlogiske deler: Det finnes et lager som lagrer pakker, og så er det kommandolinjeprogrammet som hjelper deg med å finne, laste ned, oppdatere og dele kode.

Installere programmet på noe Unix smaksatt er enkelt:

$ cd / path / to / my / project $ curl -s http://getcomposer.org/installer | php

Det er like enkelt som det! Du har nå en composer.phar fil oppført i prosjektet ditt, som inneholder all logikken for kommandolinjeverktøyet.

Du kan bekrefte at den er installert ved å kjøre:

$ php composer.phar

Denne kommandoen avslører alle tilgjengelige kommandoer.

En personlig preferanse for meg er å drive en ekstra kommando:

$ sudo mv composer.phar / usr / bin / komponist

Dette beveger seg filen i din bin, som lar deg få tilgang til alle kommandoer med det mye kortere eksemplet:

$ komponist om

Hvis du kjører Windows, kan du bare laste ned denne filen, og kjøre den gjennom PHP tolken - hvor som helst det kan installeres.


Trinn 2 - Forståelse composer.json

Hvis du er en Ruby-utvikler, vil du sannsynligvis være kjent med Gemfile. Eller, Node-utviklere vil vite om package.json. På samme måte bruker Composer a composer.json fil for å angi innstillinger og pakke krav til søknaden din.

I sin mest grunnleggende form vil komponentfilen se slik ut:

"krever": "kriswallsmith / assetic": "*"

Dette vil kreve "Assetic" -pakken, opprettet av "kriswallsmith", og vil kreve noen versjon. For å spesifisere en bestemt versjon, kan du i stedet bruke:

"kriswallsmith / assetic": "1.0.3"

Du kan til og med kombinere de to tilnærmingene, slik som:

"kriswallsmith / assetic": "1.0. *"

Dette vil tillate at noen mindre oppdateringer automatisk inkluderes, men det oppgraderer ikke til 1.1.0, da det kan ha noen grensesnittendringer, vil en utvikler måtte passe på.


Trinn 3 - Installasjonskrav

Nå som du har en eller flere pakker oppført i din composer.json, du kan kjøre:

$ php composer.phar installere

... Eller, hvis du har brukt trikset mitt for å forkorte det på Unix-maskiner (se ovenfor):

$ komponent installasjon

Du vil nå legge merke til at filer lastes ned og legges inn i en ny leverandører / mappe i roten til søknaden din. Denne logikken kan endres, ved hjelp av følgende konfigurasjonsalternativ:

"krav": "kriswallsmith / assetic": "1.0. *", "config": "vendor-dir": "pakker"

Trinn 4 - Autolading

Autoloading i PHP har vært litt rotet for en stund.

Autoloading i PHP har vært litt rotete i noen tid, da hver utvikler har sine egne måter å håndtere ting på. Noen pakker, som Smarty, bruker egen autoloading, noen utviklere plasserer flere klasser i en fil eller har små bokstaver - det er alt veldig tilfeldig.

PSR-0 er en standard, laget av PHP Standards Group, for å berolige dette rotet. Komponist vil arbeide med det som standard. Komponistpakker med en PSR-0 autoloader, som du kan inkludere i prosjektet ditt med bare en enkelt linje:

include_once './vendor/autoload.php';

Åpenbart, hvis du endret leverandørkatalogen, må du oppdatere det.

Du kan nå bruke koden i programmene dine:

dump ();

Dette er et eksempel på Assetic i bruk. Ja, det er mye namespace-kode der inne, men dette er gjort for å unngå konflikter mellom pakker. Navngivningskonvensjonen for PSR-0 er i hovedsak:

\\ (\) *

Et annet eksempel kan være Buzz HTTP-pakken, som ser slik ut:

$ browser = ny Buzz \ Browser; $ respons = $ browser-> get ('http://www.google.com'); ekko $ browser-> getLastRequest (). "\ n"; ekko $ respons;

Det kan se ut som en herliggjort file_get_contents (), men det håndterer all slags smart logikk i bakgrunnen for å arbeide med HTTP Response / Request - og du kan se navneområdet syntaks er litt mindre intens.


Trinn 5 - Real World

Hvis du vil være veldig smart, kan du automatisere hele prosessen.

For tiden lagrer de fleste prosjekter alle PHP-avhengigheter i hovedkodelageret; så hvis du bruker Facebook SDK, for eksempel, skyver du bare den versjonen inn i koden din ved å kopiere-kaste koden fra GitHub eller utvide en ZIP-fil. Deretter legger du det til versionssystemet ditt og trykker endringene.

Den versjonen setter da med koden din som en statisk fil, som på et eller annet tidspunkt kan du ikke huske å oppgradere - HVIS du merker at Facebook har gitt ut en oppdatert versjon. Den nye versjonen av filen går over toppen, og du presser de nye endringene også.

Du kan bruk Komponist for å unngå å måtte ta hensyn til versjonene, og bare kjøre en oppdatering, og forplikte alle endringene. Men hvorfor har masse kode i lageret ditt som du ikke trenger å ha der inne?

Den fineste løsningen er å legge til leverandører / til listen "Ignorer" (E.g: .gitignore) og hold koden helt ut av det. Når du distribuerer kode til vertene dine, kan du bare kjøre komponent installasjon eller komponistoppdatering.

Hvis du vil være veldig smart, kan du automatisere hele prosessen, så hvis du har vert i skyen, kan du sette opp kroker for å løpe komponent installasjon så snart den nye koden er trykket!


Sammendrag

Du vil begynne å se mye mer av Composer fremover, da ulike PHP-rammer har begynt å gi ulike nivåer av integrasjon; FuelPHP vil bli bygget som Composer-pakker, CodeIgniter vil støtte autoloading, og Symfony2 bruker allerede det i stor utstrekning.

Komponist er en flott måte å legge til avhengigheter til prosjektene dine uten å måtte installere PECL-utvidelser eller kopiere og lime inn en masse filer. Den måten å gjøre ting på er ekstremt utdatert, og krever for mye av en utvikleres tid.