Pakethanterare för PHP?
 

Jag tänkte ge mig på PHP men har inte hittat någon ordentlig pakethanterare.

Jag letar efter något enkelt sätt att installera paket från en centraliserad server som hanterar paketberoenden för en, lite som apt-get.

De borde ju finnas någon, med tanke på hur stort PHP-community:t är.

Jag har f.ö redan kollat på Pear. Dom har tyvärr för lite paket för att göra de användbart.

Vad är det du ska ha pakethanteraren till? vilken sorts paket handlar det om?

Plugins kanske är ett bättre namn.

Jag letar efter ett automatiserat sätt att installera plugins från en centraliserad punk. Pakethanteraren ska, som nyligen nämnt, även hålla koll på paketberoenden.

Ungefär så här.

Jag skriver en applikation.
Applikationen i sig är beroende av paket A, B och C.
Paket A är beroende av paket D version 1.0, paket B är beroende av paket D version 1.1 och paket C är beroende av paket E.

Den ska då, precis som apt-get, installera alla paketberoenden utan konflikter.

Här är ett exempel från ett tidigare projekt skrivet i Ruby.
Filen innehåller alla paketberoenden för projektet i fråga, paketen i sig vet själva vad dom har för beroenden.

I exemplet så plockas paket från Github, Rubygems och en lokal mapp.

Inkl alla underliggande beroenden så installeras drygt 190 paket.

Jag tror du vill ha PEAR eller PECL :)

http://pear.php.net
http://pecl.php.net

Med tanke på hur stort PHP är så borde man tycka att dom skrapat ihop mer än 800 (!) paket.

Någon som har nått alternativ, eller är det så här de ser ut?

Men vilka funktioner i paketen är det du är ute efter?

Kolla på php.net så ser du vilka funktioner som existerar, och sen får du googla lite klasser om det är funktioner du vill ha som inte redan finns.

Om du vill ha någon pakethanterare så är det så det ser ut. Nöjer du dig däremot med att ta 1 manuell minut per projekt har du betydligt fler bibliotek tillgängliga än i de flesta andra språk.

Jag hade tänkt mig något likt Rubygems.org

Drygt 22k plugins.

Att uppfinna hjulet på nytt för varje gång känns ju aningen getto.
Sedan så saknar jag expertis inom varje område, så att överlämna arbete till 3:e part är något jag gör med glädje.

Vi har nog lite olika krav på koden som ska användas i produktion.
Ett plugin ska, enligt mig, var testad, dokumenterad, ligger under en vettig licens och vara distribuerad via ett ordentligt nätverk.

Ett kodstycke skrivet av en nybörjare utan tester postat på ett forum ligger inte under den kategorin.

En minut per projekt, vilket enligt koden jag nyss postade är 190 minuter, och det är varje gång jag ska kolla efter uppdateringar.

I min värld går detta via ett kommando på drygt 5 sekunder.

Jag ger språket 24h till, sedan drar jag mig tillbaka.

Sätt upp en egen apt-get repo?

Nerix: Saken är väl den att PHP har mycket inbyggt direkt.
Du behöver inte hämta gem's för t.ex. json, mysql, sqlite osv.

Därav att det "bara" är 800(!) phpmoduler som finns tillgängliga.
Om du saknar något i PHP, säg gärna till. Jag har inte hittat någon direkt saknad support på ett par år.

OAuth osv, laddas ner som php-klasser med vettig licens, dokumentation och exempel, behövs inga moduler för det.

EDIT: Drupal har iof ett commandline verktyg för precis det här, men det är då bundna moduler till just drupal - verktyget heter "drush"

EDIT2:
Det svåra i att skapa ett sånt här verktyg är att du isåfall behöver utgå ifrån en förutbestämd katalogstruktur, då PHP är så fritt finns det inga direkta verktyg för att göra det.
Koda gärna ett, och släpp under vettig licens så kan jag både utöka det och hjälpa dig förbättra :) Kunde vara nice att ha.

Jag kan bara hålla med här, i princip alla grundstenar som behövs finns reda i PHP, sedan får man som utvecklare bygga det mesta själv, om man inte går med ett ramverk eller CMS, typ CodeIgniter, Wordpress eller drupal.

Det är så PHP ser ut, å gott och på ont.

Verkar som det är ett ramverk du efterfrågar, till exempel Zend Framework som har färdiga bibliotek och funktioner för det mesta du kan tänka dig. Fördelen med Zend är att du har tillgång till biblioteken fullt ut utan att behöva hoppa på Zend Frameworks sätt att implementera MVC.

Det där verkar ju enbart bygga på desinformation. 80% av det du drar ner gems för är inbyggt i PHP, 10% till finns i via apt-get eller pecl (här ligger t ex phpunit och oauth). Återstående procent är något man ändå för det mesta får se till att underhålla själv om man vill uppgradera. Ett väldigt enkelt exempel är Jquery som kan ha sönder din kod genom automatisk uppgradering då den inte alltid är bakåtkompatibel.

Sen är det, oavsett vilka språk man vill byta mellan, vissa saker som görs sämre eller inte alls i ett nytt språk. Är man inte öppen för det och ger det en extra dag när man möter motgångar så är det nog bättre att bara hålla sig på den trygga sidan språkbarriären.

Hur är det tänkt att jag ska använda apt-get under OS X?

Rubygems är plattformsoberoende.

Att MySQL ligger som en egen gem i stället för att vara inbyggd i core-delen betyder att utvecklingen kan ske parallellt med språket.

Jag har själv varit med och skrivit patchar för mongodb. Ändringarna kördes in i stable på mindre än 1 vecka.
Skulle mongodb eller mysql i stället varit native så skulle patchen förmodligen inte mergas in förrän nästa version, vilket när det kommer till Ruby och PHP tar sin lilla tid.

beanstalk-client - Bryggan mellan beanstalkd och Ruby.
whenever - Möjliggör crontasks direkt från Ruby.
Capistano - Deploy-verktyg
eventmachine - Eventhantering i Ruby
undertexter - Inofficiellt API för undertexter.se
spotify - Spotify-klient
Hallon - Bryggan mellan libspotify och Ruby.
haml- Ett alternativ till rent HTML
BSON - Den binära version av JSON

Det jag menar är att jag kan hitta allt och lite till, full dokumenterat, med tester som kräver att jag varken kopierar någon kod eller bryter mot några skumma, möjligen icke existerande licensavtal.

Skulle paketet vara utdaterat och finns på Github (vilket många utav paketen gör) så kan jag utan några konstigheter göra forka projektet, fixa felet, göra en pull-request var vid ägaren (förhoppninsgvis) mergar in min ändring. Vart efter paketet pushas upp till rubygems och finns tillgängligt för allmänheten.

En viktig del är även att jag får cred för patchen jag skrev, något som både Rubygems och Github fixar.

Lätt som en plätt.

Sedan kanske det är värt att nämna att siter som Github ökar överlevnaden för ett projekt. Jag har sedan drygt ett år tillbaka valt att publicera alla smådelar för mina projekt som egna gems. Små finesser som byggt efter alla konstens alla regler. Jag kan där efter publicera paketet och låta OSS-comunity:t vidareutvecklare projektet.

Jag menar; chansen att fler söker efter lösningar på samma problem som jag är ganska stor. Finns det fler användare så finns det även fler utvecklare som kan jobbare vidare på projektet.

Jag tror att det jag saknar mest är implementeringen av alla dessa API:er.
Om man te.x får för sig att skriva en site som jobbar mot eBay så kan man ge sig f*n på att någon redan har skrivit en gem.

Plockade bara något ur skjortärmen, har ingen aning om träffarna är någon att ha.

Yeah, du hittade en. ~ 22k kvar. :)

Själv använder jag OmniAuth.
Stöd för auktorisering mot ett 30-tal siter.
Implementeras med ett fåtal rader kod.

Nja. Mappstrukturen kan se ut hur som helst, så länge man lägger till projektet i load-pathen.

Paket som jag installerar lägger sig i en dold-mapp i min hem-katalog.
Exakt hur projektet är uppbyggt behöver jag aldrig bry mig om.

För att distribuera en s.k gem så används en gemspec-fil där namnet på författaren angivits och även vart huvud-filerna ligger.

Här är ett exempel

Hur hittar ni (PHP-utvecklare) kunder som kan tänkas betala för det här?
Utvecklingstiden måste ju vara flera gånger vad det skulle tagit att implementera samma funktionalitet i Python, Ruby eller exempelvis Haskell.

Jag tivlar på att Zend Framework har inbyggt stöd för brittiska polisens API. :)

Listar paketberoenden längre ner. (Hehe, inlägget blev för långt, kan ta och posta listan i ett inlägg till om det är så att du är intresserad.)
Enligt en kompis till mig så innehåller listan knappt 2% standardbibliotek. (4 av 194)

json, mysql, sqlite3, xml-simple

Var av json-paket inte längre behövs i Ruby 1.9.

Sedan så förstår jag inte riktigt hur jag ska få api-get att fungera under något annat än Linux.
Hur gör jag i OS X, eller Windows om jag väljer att sätta mig där?

Det är därför man låser paket-beroenden. Man specificerar helt enkelt vilka version av ett paket som får installeras.

Själv så kör jag dock alltid på de nyaste versionerna, skulle testerna för applikationen inte gå igenom efter en uppdatering så ser jag till och fixa felet bara.

@alla
Det skulle vara väldigt intressant och se hur ni själva bidragit till ert community.
Hur publicerar ni er kod om ingen hittar den te.x?

Jag har själv ett 70-tal OSS-projekt igång med dryga 6000 nedladdningar på Rubygems de senaste månaderna.

Intressant diskussion f.ö, jag hoppas inte att ni tar det allt för personligt :)

Visa förslag på vad du vill ha i PHP som du saknar.
Det finns massor med PHP-classer, säkert mer än 22k dessutom.

phpclasses.org rekommenderas av vissa, men hatas av andra, varierande innehåll dvs.
Github har väl ett par miljoner projekt med PHP-kod med, frågan är dock vad du letar efter.

Angående paket och paketberoende så undrar jag vilken faktisk funktionalitet du saknar, att du inte hittar matchande paket med identiskt namn kan jag förstå - men vad är det du EGENTLIGEN vill ha. Skriv gärna lista.

Ang. apt-get så var jag snäll och googlade åt dig; http://www.finkproject.org/

Här är något läsvärt, för alla egentligen - men speciellt dig Nerix:
http://www.oreillynet.com/ruby/blog/...ck_to_p_1.html

Jaha, trådskaparen urartade snabbt till en flamberingstråd. Gäsp. Lås och släng.

Borde då inte core vara fritt från allt? Jämförelsevis ligger dock mysql som extension till php (pecl install pdo_mysql - done).

Pecl install mongo

Det finns 2 skillnader mot PHP här. Rubygems finns inte för automatiska uppdateringar osv och det finns BETYDLIGT mer bibliotek till PHP. Nej, allt som finns i Ruby finns inte i PHP. Det går dock åt båda hållen. Och detta gäller precis oavsett vilka 2 språk du går imellan.

Jag tycker detta är riktigt bra. Det är ett område där ruby-utvecklare är mycket bättre. Med en bråkdel av utvecklarna så är antalet projekt för ruby på github drygt dubbelt så många som för php. I mångt och mycket tror jag det handlar om fördelen med en kultur som växt från början - snarare än kommit efteråt. När PHP blev gigantiskt fanns inte github eller mostvarande tjänster. Ruby har växt till sig starkast i samma era som motsvarande tjänster.

Det är här du är fel ute. Bara för att det inte finns en centraliserad källa som har allt innebär det inte att vem som helst på en minut kan finna sådana saker. Skillnaden är att du får känna till ett par tre sajter eller göra en google-sökning

Jag tror detta kan tas som ett exempel på att du aldrig finner exakt samma motsvarigheter i olika språk. Att hitta slimmade bibliotek för respektive inloggning är lätt för PHP. Men ett samlat bibliotek för alla vet jag inte om det finns.

Nej. PHP-utveckling är generellt sätt både billigare och lättare att finna utvecklare för än python, ruby och haskell. Utvecklingstiden har du fått om bakfoten då du verkar tro att precis allting skrivs från scratch. Det används ofta/för det mesta ramverk, bibliotek, specialiserade plugins osv samtidigt som du har väldigt väldigt mycket inbyggt i språket så att du får mer standardiserad utveckling.

Om nu obskyr kod som ingen använder skulle vara av värde kan jag försäkra dig om att det finns gott om det för PHP också.

Samtliga är med i en standard PHP-installation. Skulle du inte ha kompilerat med t ex mysql får du in den senaste genom en pecl install mysql

Nej under de plattformarna får du nog nöja dig med en checkout från subversion/git efter en google-sökning.

Låser man paketversionerna så blir man väl av med största nyttan av detta sätt att föra in funktioner? För mig är iallafall den enskilda ordentliga nyttan att du faktiskt kan uppdatera mjukvaran i ett steg. Men då har du såklart nackdelen med alla community-kod att du ofta inte har en aning om hur stabil den är. Prestanda-problem kan exempelvis smyga sig in utan att upptäckas i tester - och i sin tur slå ner hela systemet.

Jag är inte ute efter att övertyga dig om att PHP är bättre. Däremot så tycker jag att hela din insats i att ge dig på PHP verkar baseras på att allt ska fungera precis likadant som det språk du förälskat dig i. Om man inte kan överge det till en början tror jag inte det är någon större poäng med att försöka utöka sin värld med fler språk.

Ruby är näst största språket på Github med sina 17%.
Q.E.D

Sedan handlar inte diskussionen om vad som finns. Läs om tråden igen.
Jag är nämligen helt säker på att alla obskyra exempel på paket som jag tagit upp finns tillgängliga i PHP.

Postade ett en kortare lista lite tidigare, ta en titt på den.

Fink är tyvärr utdaterat. Under OS X så använder jag Brew eller Port.

Dessa pakethanterare är fortfarande inte plattformsoberoende och låter mig inte specificera vilka paketberoenden mitt projekt består av.

Det finns heller inget i Java jag inte skulle kunna göra i ASM, frågan är dock hur bra projektet skulle bli.

Kolla bara på Roller Coaster Tycoon.
Större delen av de tre första spelen är skriven i just ASM.

Sedan så kan man fråga sig vad Rails har med saken att göra.

Givetvis så får man dra en gräns någonstans.

Bryggor mellan ett språk och ett projekt, där projektet kan tänkas utvecklas snabbare än språket bör rent generellt utvecklas vid sidan av.

Chansen att någon gör någon funky i String-klassen i valfritt språk är med stor sannolikhet mindre än att något funky (användbart) implementeras i MongoDB.

Vad du ville visa med det där förstår jag inte riktigt.
Hur sätter du mongo som ett paketberoende i din applikation då?

Syn bara att majoriteten inte går att köra i produktion.
Möjligen att Lasse hos Lasses Fisk inte bryr sig om copy ´n paste-kod från någon random-forum, men jobbar man med lite större projekt där kvaliteten på koden är otroligt viktig så finns det (tyvärr) ingen möjlighet att använda kodbasen.

Sedan så får du gärna utveckla det där med automatiska uppdateringar.

För att använda koden så måste du sedan ... *trummvirvel* ...

Att kopiera kod tillsammans med alla paketberoenden tar tid, vilket kanske inte är ett problem om projektet är litet, men ställer till aningen med problem i lite större kodbaser.

Ta te.x koden jag postade i tidigare inlägget.
Projektet är relativt litet, ändå hade jag angivit drygt 30 gems.
Varje gems beroende resulterade i slutändan i 190 paket.

PHP-utvecklare är rent generellt billigare eftersom komplexiteten i applikationerna som ska implementeras ofta inte överstiger svårhetsgraden för vad en 15-åring skulle klara av.

Ta bara en titt i feedback-forumet. Det är ju inte direkt rocket-science. :)

Det var allt bra längesedan jag träffade en PHP-utvecklare som satt i ett ramverk. Jag har heller inte sett någon fråga varken på det här forumet eller på flashback som indikerar på att folk faktiskt väljer att använda ett ramverk. Men vet vem, folk kanske utvecklar i smyg.

I min värld så ökar även implementeringstiden i samband med att mer kod behöver skrivas.

De tror jag säkert, frågan är bara om folk verkligen orkar lägga ner tid på att leta upp den.

Som tidigare nämnt så handlar det inte om något är möjligt eller ej utan hur snabbt och enkelt det faktiskt är att utföra något.

Precis som tidigare nämnt så är det bara 4 av ~ 200 paket som fanns inbyggd PHP.

Här är listan: http://pastebin.com/Hfk9QCAn

Eller så väljer jag ett språk som har en lösning.

Det där får du gärna utveckla, förstår inte riktigt vad du menar.

Jag kanske skulle tillägga att mitt wild-and-crazy-alltid-nyaste-paketet-tänk bara körs på mina egna småprojekt. Skulle servern överbelastas under 30 min för mindre än 20k användare så är det inte hela världen.

Jag skulle dock inte få för mig att göra samma sak i ett större projekt, där jag har folk över mig.

Ni får ursäka min möjligen aggressiva ton, jag känner att jag hade aningen svårt att linda in mina svar i silkeshandskar :)

Du dissar PHP till fördel för Ruby, om nu PHP suger i dina ögon, varför ge dig på att försöka lära dig det?

Jag föredrar Skånemejeriers mjölk, vilken föredrar du?
Jag föredrar OLW Sourcream & Onion, vilken föredrar du?

Ge upp med att försöka se ned på saker, försök att se möjligheterna, är du rädd att slita på tangentbordet, så fortsätt med att koda Ruby och ge fan i PHP, och tänk inte ens tanken på att ge dig på Assembler...

Jag håller med Jonas.

Du verkar ha bestämt dig redan sen innan du startade tråden, varför ens försöka?
Det finns inget vi kan säga som kan få dig släppa bilden över att PHP är sämst.

Nu råkar det inte vara min världsbild, men jag anser du får ha din kvar, och om du är sådär inbiten så får du nog fortsätta ha det.

Jag ger mig, lycka till!

Hahahah! :D

Ställer mig också frågande till vad du egentligen ville ha ut av tråden, Nerix... Du vet ju uppenbarligen redan att Ruby är fullständigt överlägset på alla sätt och vis. ;)

Att byta plattform på vår största sajt från Ruby till PHP var det bästa jag gjort!

Utveckla gärna varför, jag (och säkert fler) är nyfikna... :)

http://fabian.mossberg.in/2010/05/fo...ed-nya-sajten/

http://fabian.mossberg.in/2010/05/ny...nkten-ar-live/

http://fabian.mossberg.in/2010/04/ny...en-vaxer-fram/

Förutom det som står i länkarna till min blogg som hnn postade så handlade det mycket just om tillgängligheten på kodare.

Eftersom jag inte själv kodar ruby var jag tvungen att hitta någon som kunde hjälpa mig. Jag bad om offerter från flera oliak webbyråer, träffade både frilansare och byråer, flera av dom började försöka bygga vidare på sajten men alla gav upp för att dom tyckte att projektet var "för omfattande".

Communityt kring ruby är mycket mindre än det runt PHP. Tillgången till kompetens inom det språk sajten är byggd i är för mig en viktig faktor.

Rails crashade för oss några gånger i veckan vilket resulterade i att sajten stod till. På grund av en konflikt mellan mig och webbyrån som gjorde skitjobbet (skrev om det här på WN men dom trådarna har tagits bort) kunde jag inte ta hjälp av dom för att fixa det, ingen av dom tre webbyråer och två frilansare som kollade på det kunde lösa det utan rekommenderade mig att via cronjobs starta om rails-demonen en gång om dagen eftersom den nästan aldrig crashade inom 24 timmar.