W związku z zainteresowaniem (i wnioskiem ~batmana) zakładam wątek.
Tytułem uzupełnienia napiszę tylko, że wątek ten jest miejscem dyskusji na temat biblioteki Phar.

Dzisiaj rano znalazłem na RSS informację, że w PHP 5.3 ma pojawić się phar. Nie spotkałem się z tym wcześniej, więc temat mnie zainteresował. W telegraficznym skrócie chodzi o to, że będzie można tworzyć archiwa PHP wzorowane na archiwach jar, znanych z Javy.
Jak tylko poczytałem w manualu co to jest, przyszło mi do głowy kilka pomysłów. Między innymi to, że w końcu aplikacje pisane w PHP będzie można tworzyć modułowo (a nie prawie modułowo). Każdy z modułów będzie spakowany w takim właśnie archiwum, którego dołączenie będzie polegało na wrzuceniu go na serwer oraz dołączeniu w odpowiednim pliku.
Samo archiwum może zawierać oprócz plików PHP, inne pliki, np obrazki, dzięki czemu będzie można tworzyć gotowe do użycia paczki. Skończą się problemy polegające na dylemacie - gdzie i jakie pliki trzeba przenieść, by zastosowane zmiany na serwerze testowym zadziałały na produkcji.
Dobrze napisana aplikacja będzie składać się z kilku plików PHP oraz dołączonych do nich modułów. By zapewnić unikatowość nazw, wystarczy użyć przestrzeni nazw.

Kolejny dowód na tezę że PHP zmierza nieustannie w kierunku Javy. I jest to plus moim zdaniem.
Nie bardzo jednak widzę sens używania tej biblioteki patrząc chociażby na PEAR.
Zgodnie z manualem PEAR używa tej biblioteki do instalacji ( nie doczytałem czy tylko samego siebie czy też modułów ).
Jednak biblioteki PEAR składowane są w postaci plików PHP i katalogów. Tak dobrze jest i nie widzę specjalnej potrzeby komplikowania tego.
Dodatkowo na niekorzyść może przemawiać iż przy dołączeniu pliku z takiego archiwum przy np. include('phar:///path/to/myphar.phar/file.php');
zanim plik zostanie dołączony musi on zostać wypakowany. Miałoby to jakiś większy sens przy serwerze aplikacji gdzie nie trzeba by było przy każdym wywołaniu uruchamiać tego procesu.

edit>
Istnieje już coś podobnego do Phar'a w niektórych systemach zarządzania treścią gdzie moduły i wtyczki dystrybuowane są na zasadzie spakowanych archiwów. Przy instalacji następuje rozpakowanie, a następnie instalator czyta plik xml i wykonuje odpowiednie zadania.

edit>>
OT: Wczoraj zainstalowałem Fedorę po czym olałem go(ją?). Jestem zdania że PHP rozwija się w 10 razy szybszym tempie niż ten system.
Pewnie wedle zasad rachunku prawdopodobieństwa ... coś w końcu musi

~orglee no właśnie to nie działa tak jak myślisz. Odwołanie się do czegokolwiek wewnątrz archiwum (phar lub jar) nie powoduje wypakowania czegokolwiek. Archiwum takie jest po prostu przezroczystym dostępem do zawartości.

Piszesz, że coś już jest. No właśnie jest to coś innego. W przypadku paczek instalujesz a ona się sama rozpakowuje. W przypadku takiego archiwym po prostu wklejasz plik w jedno mieksce i koniec. Nic nie rozpakowujesz.

Skoro tak to faktycznie może to być nie głupia opcja.
I nie piszę że już coś jest tylko że jest to mechanizm podobny. Nie podoba mi się tylko konieczność rozpakowania archiwum żeby coś zmodyfikować,
no ale wtedy może programiści PHP zaczną z głową pisać swoje skrypty i będzie można w naszych korzystać z dobrodziejstw dziedziczenia.

W takim razie jestem za. Pomysł nie jest głupi.

Tak samo jest w Javie (chyba, że się mylę, niech Javowcy mnie poprawią). Poza tym nie będzie problemów z "przypadkowym" zmodyfikowaniem jakiegoś pliku, ponieważ najpierw trzeba będzie go rozpakować.

Widzę już oczami wyobraźni, jak W PDT można tworzyć phar tak samo prosto, jak uruchomić kompilator, np Javy

Z tego co czytałem dostęp do treści w archiwach PHAR nie będzie wolniejszy. W przypadku kodu PHP mozliwe jest sformatowanie go w taki sposób, aby działał nawet szybciej! Przynajmniej tak czytałem tutaj: http://www.zyxist.com/pokaz.php/phar_pear_pyrus

PHAR mi sie troche nie podoba, o wiele bardziej za to spodobał mi się PHK - http://phk.tekwire.net/. Przede wszystkim dlatego, ze generuje pliki PHP, ktore mozna tak po prostu rozprowadzac (pliki .phar moza uruchomic jedynie, gdy w PHP aktywne jest rozszerzenie PHAR)! Nie mam teraz czasu szerzej opisac swoich doswiadczen, w kazdym razie tworzac niektore biblioteki (na przyklad PHP OTServ Toolkit) jakos znacznie latwiej mi sie pracowalo z PHK. Aczkolwiek nic nie stoi na przeszkodzie (zazwyczaj) generowania obydwu rodzajow archiwow.

Chcialbym tylko wskazac bardzo przydatna moim zdaniem opcje obslugi roznego trybu uruchamiania - zarowno PHK jak i PHAR daja nam mozliwosc dodania skryptow startowych do naszych paczek i to osobnych dla tryby strony WWW, osobnym dla urunamiania z linii komend (CLI), oraz z tego co pamietam jeszcze kilka innych trybow, na przyklad informacyjny.

Z wersją PHP 5.3 nic nie będziesz musiał doinstalowywać. APhar będzie częścią core'a PHP.

Na logikę to archiwum PHAR będzie po prostu jak zwykły folder, tylko troszeczkę w wygodniejszej formie, dobrze zrozumiałem?
Ogółem podoba mi się taka opcja, ponieważ będzie ona przymuszać programistę do pisania bardziej uniwersalnych skryptów, aby dało się to archiwum wszędzie dołączyć.

A czy widział już ktoś, jak wygląda taki phar od środka?
Czy jest to jakiś sposób, żeby ukryć kod przed użytkownikiem?

Domyślnie plik PHAR jest zwykłym skryptem PHP, w którym w pewnym miejscu pierdyknięte jest wywołanie pseudofunkcji __halt_compiler() - dalej jawnie leci treść kolejnych "spakowanych plików". Odczyt odpowiedniego podpliku sprowadza się na ustawieniu kursora w miejscu jego rozpoczęcia i rozpoczęcia kompilacji skryptu od tego miejsca. API Phar-a może też posłużyć do tworzenia archiwów TAR, a także kompresji samych pharów.

Żeby zapakować skrypt do postaci Phar, w zasadzie nie trzeba przerabiać istniejących skryptów - w sieci widziałem już np. phpMyAdmina w wersji Phar. Jedyny dodatek to skrypt pakujący .

Phar przyda się twórcom bibliotek - do każdego archiwum można dołączyć tzw. "stub", który jest wywoływany w momencie załadowania archiwum. Można tam dać np. procedury inicjacyjne, jak np. rejestrowanie autoloadera biblioteki czy wstępną konfigurację.

Albitos -> Trochę przekręciłeś tę notkę . Miałem na myśli, że twórcy PHP mogą optymalizować PHAR-a, zmniejszając liczbę odwołań dyskowych (w sensie: jest to wykonalne i być może tak będzie). Na dzień dzisiejszy sytuacja wygląda tak, że skrypty uruchamiane z Pharem i bez niego działają praktycznie tak samo szybko (różnice są rzędu pojedynczych żądań na 1000). Niestety, póki co kiepsko współpracuje toto z optymalizatorami kodu. Po włączeniu APC, Phar jest wyraźnie wolniejszy. Mail odkrywający ten fakt można znaleźć tutaj: http://marc.info/?l=php-internals&m=12...3624673&w=2

Tematykę PHP Archive śledzę już od kilku lat (bodajże 3). Na początku powstało na bazie PEARa i w międzyczasie pojawiło się również w PECLu (gdzie przez długi okres czasu nie było aktualizacji - myślałem że projekt 'umarł'). Mimo podobnego nazewnictwa pliki końcowe miały odmienną budowę. Pokrótce można powiedzieć, że jeden dało się rozpakować zipem a drugi nie . Bardzo ciekawym rozwiązaniem było zaszyfrowanie (w PEAR) pliku uruchomieniowego poprzez bibliotekę BLENC i następnie złączenie wszystkiego w jeden plik. Dzięki temu można było tworzyć zaszyfrowane pliki PHP. Aktualnie nie sprawdzałem różnic między najnowszymi wersjami z PECLa i PEARa.

Na dzień dzisiejszy, tj wersja PHP 5.2.x trudno znaleźć dużo informacji na temat PHARów (niedopracowany manual); opisy na dodatkowych stronach są zagmatwane i trzeba się troszeczkę namęczyć. Winą męczarni są różnice w składniach między poszczególnymi wersjami. I mimo, że na stronie będzie napisane "How to PHAR..." nie wiadomo czy tyczy się to PECLa czy też PEARa i której wersji.

Co do użyteczności - przydadzą się do tworzenia plików dystrybucyjnych (aktualnie tak z nich korzystam). Mając przykładowo klasę db z dziećmi, tworzymy paczkę db.phar; validate z regułami też jeden plik. Można dołączać dowolny rodzaj plików; jednakże przy większych paczkach zauważalny jest spadek prędkości wykonywania skryptów. I teraz po modyfikacji jakiejś klasy rozsyłamy po klientach, bądź wgrywamy tylko jeden duży plik. No i należy dodać, że ładnie to wygląda .

Można spakować, lub stworzyć archiwum. Do wyboru przy pakowaniu GZ lub BZ, można wybrać które pliki pakujemy i w jakim stopniu. Z biblioteki wielkości 900k czystego kodu zrobiło pliki o sumarycznej wielkości 120k.
Nie należy tworzyć jedej paczki do wszystkiego, ale podzielić na mniejsze, względnie tematyczne - nie zawsze użyjemy klasę którą zaincludujemy poprzez uruchomienie jednego pliku PHAR - powoduje to wzrost zajętości RAMu, dlatego idealnym rozwiązaniem jest właśnie utworzenie kilku a nawet kilkunastu takich plików (sprawdzone empirycznie).

Zgadzam się z wrzasq - lepszym rozwiązaniem może być PHK, i tutaj pojawia się kolejny problem świata PHP - wiele różnych rozwiązań, brak tego dobrego; mogliby połączyć siły. Mimo zaimplementowania w 5.3 PHARa, wątpie by wszyscy administratorzy zmienili wersję PHP na nowszą.

Podsumowując krok w bardzo dobrym kierunku, oprócz skąpej dokumentacji nie mam innych uwag.

Uruchamiając archiwum phar nie ładujemy znajdujących się tam plików do pamięci. Uruchamiany jest wyłącznie stub i to on ewentualnie decyduje, czy nie dołączyć jednego z elementów archiwum.

Programista do niczego nie zostanie zmuszony, a już na pewno nie do pisania bardziej uniwersalnego kodu. Problem z modułowością aplikaci też nie zostanie do końca rozwiązany bo zawsze w takich sytuacjach pojawia się kwestia zależności tak jak to ma miejsce w PEAR. Ale żeby nie być takim sceptykiem wspomnę, że widzę w tym rozszerzeniu szansę na lepsze mechanizmy dystrybuowania aplikacji a także ich aktualizację.

phar - nic specjalnego. plusow wielu nie widze, poza jednym zarabistym (wyzej pare razy wspomniany) - aktualizacja.
Swego czasu w jednej agencji interaktywnej obslugiwalem firme axa ubezpiecznia, pajace nie chcieli nam dac dostepu do serwera i pliki ktore zmienialismy, wysylalismy im mailem i oni wrzucali na swoj serwer. wiele razy dzwonili do nas, bo nie wiedzieli gdzie plik x wrzuc a gdzie plik z. nie wazne ze instrukcje dostawali.
w przypadku pharow, dostaja jeden plik i po sprawie.
BTW: oczywiscie nie jestem zwolennikiem pharowania core aplikacji.

Pozwolę sobie odgrzebać temat. Ktokolwiek tego wynalazku używa? Nie widziałem jeszcze na oczy żadnej biblioteki, która była by w tej postaci dystrybuowana.

Z tego co widzę to użytkownik Zyx chyba z tego korzysta: http://www.invenzzia.org/en/download

PHAR jest wykorzystywany chociażby w projekcie PEAR2, który ma zastąpić obecne repozytorium PEAR. Można też znaleźć wiele opisów, jak zapakować do tej postaci rozmaite aplikacje (phpMyAdmin, Zend Framework itd.). Problem z brakiem oficjalnych paczek może wynikać z tego, że twórcy chcą zachować kompatybilność z wcześniejszymi wersjami PHP, które PHAR-a nie obsługują bądź nie mają.

Korzystam z tego w kilku projektach, ale tylko na serwerach dedykowanych, gdzie mam taką możliwość. Na chwile jest to głównie zabawa z archiwami, ale szczerze mówiąc jest w tym potencjał.

Projektów na chwile obecną nie wypuszcza się jako archiwum, z jednego prostego powodu, po prostu większość serwerów nie ma w kompilowanego modułu phar.