ai 2 varianta la php: ori folosesti numai ce-ti da distributia, ceea ce
inseamna ca vor fi chestii mai vechi, insa in general mai stabile, si nu
te trezesti ca se strica ceva ca a facut un third party update si a
explodat; ar trebui sa mearga din fuleu insa nu prea vad de ce te-ai mai
juca cu composerul (ca sa fac o paralela e oarecum cazul in care
instalezi un pachet si dupa aia vii si compilezi o versiune noua din
surse, ceea ce inseamna cam ciorba)
ori privesti vhostul tau ca si un tot unitar, unde ai in vendor toate
dependintele la nivel de clase (desigur ca modulele necesare de php,
daca e cazul vor fi instalate global); in cazul asta instalezi inclusiv
roundcube-ul din surse, nu din pachetul de distributie
in mod normal, de la psr-4 citire, daca folosesti composerul iti va crea
el automat un script autoload pe care sa-l incluzi in scripturile "tale"
(de fapt cu arhitectura actuala ar trebui doar in front-controller, ca
cica nu mai avem jde mii de scripturi de intrare - da, stiu, gluma buna,
trebuia sa o pastrez pentru 1 aprilie); dat fiind ca folosesti
roundcube-ul din pachet, ar trebui sa vezi ce spl_autoload_register are
hardcodat prin el, ca sa vezi de unde-ti incarca clasele
mai e si varianta veche cu include_path, insa mi se pare old school si
de kko, de cand cu namespace-urile de la 5.3 sau 5.4 in sus
de ce exact ai apelat la cocktail de apt si composer ?
Alex
On 08-Jan-21 12:37 PM, Mihai Badici wrote:
> Salut,
>
> Am întâlnit o problemă legată de composer (și cumva am și rezolvat-o)
> doar că aș vrea să pricep cum funcționează.
>
>
> Am un modul de roundcube care folosește biblioteca sabre ( pentru
> formatul ical)
>
> Din ce văd eu în debian buster ( dar problema a tot reapărut de-a
> lungul timpului și în altele) biblioteca default nu conține toate
> clasele pe care le vreau eu.
>
> am la început următoarele incluziuni:
>
> use \Sabre\VObject;
> use \Sabre\VObject\DateTimeParser;
>
> În formatul ăsta plugin-ul plânge după o anume clasă Text.php care
> într-adevăr nu există în VObject
>
> în composer.json plugin-ul are:
>
> "require": {
> "php": ">=5.4.0",
> "roundcube/plugin-installer": ">=0.1.3",
> "sabre/vobject": "~3.5.3"
> }
>
> după ce dau composer install nu se întâmplă nimic însă, aparent el
> caută tot în clasele php-ului .
>
> Dacă adaug un:
>
> include("/usr/share/roundcubemail/plugins/libcalendaring/vendor/sabre/vobject/lib/Property/Text.php");
>
> eroarea dispare, însă apar alte probleme legate de incompatibilitatea
> între vobject-ul de aici și cel din
>
> /usr/share/php/Sabre . Definițiile din php sunt mai vechi decât cele
> cerute de plugin
>
> Soluția mea provizorie și funcțională a fost să copiez manual tot ce e
> în "vendor" referitor la VObject în folderul Sabre de mai sus.
>
> Dar evident e o soluție ciobănească. Interesul meu ar fi ca cel puțin
> tot ce e în roundcube (dacă nu tot ce e php) să folosească versiunea
> actualizată a bibliotecilor sabre, evident fără să stric package
> manager-ul.
>
> Pe scurt: în ce ordine folosește php-ul bibliotecile în cazul în care
> are mai multe versiuni disponibile și cum se procedează să le
> folosești pe cele pe care le vrei tu, unde vrei tu?
>
> Danke,
>
> Mihai
>
>
>
>
>
>
>
> _______________________________________________
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
