Re: [rlug] prioritate biblioteci php
On 08-Jan-21 4:46 PM, Mihai Badici wrote: >> > Momentan am încercat să redenumesc folderul VObject din php și să > rulez composer install în plugin-ul respectiv. > > Nu a mers. Acum mai e o chestiune, că s-ar putea să am nevoie de el și > în alt plugin ( ăsta e libcalendaring, dar mai există și plugin-ul > calendar care folosește biblioteca asta) vezi ca nu cumva fiecare plugin sa aiba directorul lui separat de vendor, ca path-ul initial era un pic cam ciudat > > O să mai încerc să îl adaug direct la roundcube. > > Oricum, mulțumesc. Eu am ridicat problema tocmai pentru că e oarecum > universală, sigur că biblioteca asta e mai exotică, dar în general > dacă ai o aplicatie care are nevoie de o bibliotecă mai nouă mi se > pare un pic pe dos că întâi caută în php și după aia în vendor , în > viziunea mea ar fi trebuit să fie invers. tocmai de aia prefer organizare pe namespace-uri, adio php_include_path si balarii de genul din 1900 toamna; sa stii sigur ce si cand incarci, si fiecare proiect sa aiba dependintele lui, nu sa se bazeze pe cine stie ce versiuni globale bine, acum de cand cu containerizarea izolarea e mult mai simpla si mult mai buna, insa mai e pana cand toata lumea o sa se apuce de kuberneti sau ce o mai veni in viitorul apropiat, mai ales pentru un server de webmail Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
da, incearca sa scoti pachetul de debian (care cel mai probabil e vechi) si sa lasi composerul sa-si faca treaba de dependinte si sa genereze autoloadul cu siguranta ca se poate si fara uninstall (heck, e doar php) insa nu pot sa-ti dau un raspuns concret ce si cum fara sa-mi fi bagat surubelnita prin cod sa vad cu ce se mananca ... poate doar daca vreun colistas s-o fi lovit de fix aceeasi problema si deja stie o cale de rezolvare concreta Momentan am încercat să redenumesc folderul VObject din php și să rulez composer install în plugin-ul respectiv. Nu a mers. Acum mai e o chestiune, că s-ar putea să am nevoie de el și în alt plugin ( ăsta e libcalendaring, dar mai există și plugin-ul calendar care folosește biblioteca asta) O să mai încerc să îl adaug direct la roundcube. Oricum, mulțumesc. Eu am ridicat problema tocmai pentru că e oarecum universală, sigur că biblioteca asta e mai exotică, dar în general dacă ai o aplicatie care are nevoie de o bibliotecă mai nouă mi se pare un pic pe dos că întâi caută în php și după aia în vendor , în viziunea mea ar fi trebuit să fie invers. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
On 08-Jan-21 4:23 PM, Mihai Badici wrote: > în principiu mie mi-ar fi util să am clasele astea disponibile în > roundcube ( să fie aceleași și în main și în plugins) Doar că nu am > știut cum să fac . > > În variantele mai vechi îmi mergea cu php-sabre ( sau cum se numește) > din distribuție. Nu știu exact cum face composer-ul: în roundcube > fișierul config.json nu face referință la sabredav, doar în plugin-ul > respectiv am referința la el. Îmi sugerezi că dacă dezinstalez > php-sabre php va căuta automat în "vendor" ? Încerc un pic mai încolo > și zic :) în principiu toate componentele sistemului meu importă > plugin-urile astea din roundcube, deci ar fi ideal așa că aș avea > structurile consecvente. > da, incearca sa scoti pachetul de debian (care cel mai probabil e vechi) si sa lasi composerul sa-si faca treaba de dependinte si sa genereze autoloadul cu siguranta ca se poate si fara uninstall (heck, e doar php) insa nu pot sa-ti dau un raspuns concret ce si cum fara sa-mi fi bagat surubelnita prin cod sa vad cu ce se mananca ... poate doar daca vreun colistas s-o fi lovit de fix aceeasi problema si deja stie o cale de rezolvare concreta Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
On 1/8/21 4:00 PM, Alex 'CAVE' Cernat wrote:
On 08-Jan-21 1:58 PM, Mihai Badici wrote:
roundcube-ul e și el din surse.
Se pare că dacă vrei să folosești modulul de calendar la justa lui
valoare ( să poți invita alți useri de exemplu la un meeting)
VObject-ul pe care îl am eu în debian nu are toate atributele. Deci e
musai să folosesc sabre ăla, 3.5.3 pe care îl zice composerul.
Aș putea să schimb la roundcube să încarce clasele din altă parte?
Dacă da, cum?
de aia ziceam ca ori instalez tot din pachete (ceea ce la pachete de
clase php ... personal slabe sanse), ori totul "de la sursa"; din ce vad
tu ai instalat cumva "distribution based", folosind path-urile de sistem
(/usr & friends), de aia banuiam ca ai fi instalat din pachet
vezi daca are referinte de autoload si de unde incarca, si atunci ai
putea sa pui ceva de genul:
"autoload": {
"psr-4": {
"Path\\To\\FQCNDir\\": "app/"
}
în principiu mie mi-ar fi util să am clasele astea disponibile în
roundcube ( să fie aceleași și în main și în plugins) Doar că nu am
știut cum să fac .
În variantele mai vechi îmi mergea cu php-sabre ( sau cum se numește)
din distribuție. Nu știu exact cum face composer-ul: în roundcube
fișierul config.json nu face referință la sabredav, doar în plugin-ul
respectiv am referința la el. Îmi sugerezi că dacă dezinstalez php-sabre
php va căuta automat în "vendor" ? Încerc un pic mai încolo și zic :)
în principiu toate componentele sistemului meu importă plugin-urile
astea din roundcube, deci ar fi ideal așa că aș avea structurile
consecvente.
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
On 08-Jan-21 1:58 PM, Mihai Badici wrote:
>
>
> roundcube-ul e și el din surse.
>
> Se pare că dacă vrei să folosești modulul de calendar la justa lui
> valoare ( să poți invita alți useri de exemplu la un meeting)
> VObject-ul pe care îl am eu în debian nu are toate atributele. Deci e
> musai să folosesc sabre ăla, 3.5.3 pe care îl zice composerul.
>
> Aș putea să schimb la roundcube să încarce clasele din altă parte?
> Dacă da, cum?
de aia ziceam ca ori instalez tot din pachete (ceea ce la pachete de
clase php ... personal slabe sanse), ori totul "de la sursa"; din ce vad
tu ai instalat cumva "distribution based", folosind path-urile de sistem
(/usr & friends), de aia banuiam ca ai fi instalat din pachet
vezi daca are referinte de autoload si de unde incarca, si atunci ai
putea sa pui ceva de genul:
"autoload": {
"psr-4": {
"Path\\To\\FQCNDir\\": "app/"
}
}
in exemplul de mai sus tot ce e namespace-ul \Path\To\FQCNDir (aplicatia
"ta") va fi incarcat din directorul app, iar la composer dump-autoload
se va uita el prin vendor si va genera un autoload cat sa incarce la
nevoie si ce e prin vendor
iarasi, vorbesc chestii generale, nu am mai lucrat de mult cu roundcube
ca sa ma uit prin surse, insa dupa cum spuneam prefer ca tot ce tine de
proiect php sa fie intr-un $project_root, iar doc_root-ul sa fie
$project_root/public, asa cum e la moda de la laravel incoace (prima
data si eu am injurat, ca era ceva nou, insa daca te gandesti bine face
foarte mult sens sa nu expui direct decat minimul de surse necesare,
recte front-controllerul si ideal doar atat, restul statice)
mai mult, daca folosesti nginx cu try_files poti sa "ascunzi" si
front-controller-ul intr-un alt director separat, dar aici deja vorbim
de specializari prea mari :-P
Alex
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
On 1/8/21 1:32 PM, Alex 'CAVE' Cernat wrote: 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 ? roundcube-ul e și el din surse. Se pare că dacă vrei să folosești modulul de calendar la justa lui valoare ( să poți invita alți useri de exemplu la un meeting) VObject-ul pe care îl am eu în debian nu are toate atributele. Deci e musai să folosesc sabre ăla, 3.5.3 pe care îl zice composerul. Aș putea să schimb la roundcube să încarce clasele din altă parte? Dacă da, cum? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
Re: [rlug] prioritate biblioteci php
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
Re: [rlug] prioritate biblioteci php
Eu as incerca asa.
As face un mv vendor vendor.bak (sau macar sterge/redenumeste sabre) si as
incerca sa instalez iarasi pachetele folosind composer install (atentie, nu
face modificari in composer.json/.lock)
Din ce vad problema la tine pare sa fie ca ai instalat initial pachetul
manual -- si de-aia e posibil sa fi ramas cumva vechile fisiere.
De asemenea, ai incercat un composer dump-autoload ?
On Fri, Jan 8, 2021 at 12:39 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
>
--
Cu drag,
madalin
http://madalin.eu
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
[rlug] prioritate biblioteci php
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
