[PHP] Compatibiliteit van composer-packages: howto?

[StephanVierkant]

Ik ontwikkel veel in Symfony2 en maak daarbij veel gebruik van alle aanverwante pakketten die te gebruiken zijn: Doctrine, Twig, Assetic, FOSUserBundle, etc. etc. Het werkt allemaal fantastisch samen en als er een tegenovergestelde is van het NIH-syndrome, dan kan ik die zelf-diagnose denk ik wel stellen.

Er is alleen een pijnpunt waar ik nog mee zit. Zodra ik een nieuwe versie wil gebruiken van een bepaalde Bundle of package (nieuwe features, opgelost bugs, you name it), begint het hele circus aan problemen met de compatibiliteit. Het bij elkaar zoeken van de juiste versies kost me steeds weer erg veel tijd. Een nieuwe versie legt soms problemen in andere packages bloot, maar oudere versies bevatten dan juist zelf weer bugs.

Compatibiliteit van software is natuurlijk een groot issue in het algemeen (wie kent het gezeik niet met nieuwe versies van besturingssystemen?), maar ik kan me voorstellen dat een slimme collega-programmeur zich hier al een keer in heeft verdiept en die kennis wil delen met de rest van de wereld.

Hoe verloopt jullie zoektocht naar de ideale combinatie van dependencies? Is het ook zo'n puzzel, of gebruik je een slimme methode of een handige tool?

Mijn achtergrond is voornamelijk Symfony2, maar het probleem is natuurlijk groter dan dat. Ook inzichten vanuit andere frameworks zijn natuurlijk welkom!

[Cartman!]

Ik loop er eigenlijk maar zeer zelden tegenaan. Als je echt bizar veel dependencies hebt dan kan ik me voorstellen dat het splitsen naar losse (micro)services een oplossing kan zijn omdat iedere service eigen dependencies heeft.

[Gomez12]

Ik heb nooit composer gebruikt, maar zoals jij het beschrijft is het dan niet simpelweg overbodig?

Want in wezen verwacht ik juist van een programma wat zich noemt "Dependency Manager for PHP" dat het ook je dependency's managed en dat gewoon regelt.

Dat is wmb ook wat een nuget doet bij .Net of een Maven bij Java of een apt-get bij ubuntu etc. etc.

Tuurlijk kan er zo heel af en toe wel eens een conflict optreden, maar zoals jij het beschrijft heb ik het gevoel dat ik dat had toen alles handmatig van git af zat te clonen en op schijf een beetje bij elkaar zat te graaien.

Een dependance manager moet je juist hiervan af helpen.
Weet je wel zeker dat je composer gebruikt zoals het bedoeld is ,dus bijv niet in de dependency's zelf zitten editten alhoewel ik vermoed dat het wel kan omdat alles plain text is of zelf even een git patch draaien of ... of... want anders beland je in een dependance hell omdat je zit te vechten tegen je dependance manager.

Of zit je bijv alles van unstable/alpha te pakken (ik neem aan dat er zo'n soort branch is binnen composer) waardoor je het zelf deels uitlokt (wil je het niet moet je naar stable gaan)

Want als het echt zo is als jij omschrijft dan zou Composer wmb compleet waardeloos zijn en direct te vervangen door een git-clone scriptje. En ik meen meegekregen te hebben dat Composer best wel aardig in elkaar zit, dus ik vermoed dat jij iets fout doet.

[Cartman!]

Composer zit zeer goed in elkaar ja dus volgens mij is de TS best een uitzondering.

[Pin0]

Composer regelt inderdaad alle dependencies van de geïnstalleerde packages. (eye opener voor mij was: edit nooit handmatig je composer.json, alles kan je met het composer commando doen)

Verder wanneer je code stuk gaat omdat het twee dependencies gebruikt die niet meer werken kan je gaan denken aan unit tests. Dan hoef je na een update enkel je tests te runnen en weet je of het fout gaat of niet.

Dit alles is makkelijker gezegd dan gedaan...

[Barryvdh]

Als je packages gebruikt die zich houden aan SemVer, gaat het meestal wel goed. Voor Symfony kies je dus meestal voor een LTS versie (2.3 als het kan, anders 2.7). Voor andere packages de minimale versie die werkt. Dus ^2.1.3 als alles boven die versie werkt (want SemVer, dus 2.1.4, 2.2.0 en 2.3 moeten ook werken, 3.0 niet).

Meestal geeft het alleen problemen als je 0.x versies gebruiken (want die zijn nog niet zo stabiel) of als de major versie veranderd. Standaard voorbeeld is Guzzle. Omdat dat de meeste populaire HttpClient is, wordt die door voor packages gebruikt. Versie 3 en 4+ kunnen naast elkaar gebruikt worden (want andere namespace), maar 4, 5 en 6 zijn in anderhalf jaar uitgebracht. Als je dus een package maakt op Guzzle 5 en iemand anders met Guzzle 6, krijg je een conflict.

Bij Laravel heb je soortgelijke problemen, als je Laravel 4 ondersteund, is het net iets anders als Laravel 5. Dus of je ondersteund 2 versies tegelijk, met versie checks in je code, of je onderhoudt zelf 2 versies.

Ik zou proberen zo flexibel mogelijk te zijn in je packages en framework implementaties los te trekken van je hoofd package. Dus agnostic ontwikkelen. Evt. een eigen interface gebruiken voor Http of andere zaken, zodat je die makkelijk om kan wisselen (of bijv. een Guzzle 5 en Guzzle 6 adapter maken).

En tenslotte kan je met Travis makkelijk verschillende PHP versies testen, maar ook je minimale dependancies ophalen ( `composer update --prefer-lowest`)


En als je alleen afhankelijk bent van packages, is het een kwestie van bij voorkeur stable SemVer packages gebruiken en even op de readme kijken wat de requirements zijn. Normaal gesproken pak je dus de nieuwste versie. 'composer install require vendor/package' pakt zelf de laatste versie al, dus dat kan je eerst proberen.

[ Voor 9% gewijzigd door Barryvdh op 03-09-2015 13:06 ]

[Cartman!]

Barryvdh schreef op donderdag 03 september 2015 @ 09:16:
Normaal gesproken pak je dus de nieuwste versie. 'composer require vendor/package' pakt zelf de laatste versie al, dus dat kan je eerst proberen.

Ik corrigeer je even

[Barryvdh]

Cartman! schreef op donderdag 03 september 2015 @ 11:26:
[...]

Ik corrigeer je even

Oepsie, aangepast.

[StephanVierkant]

Gomez12 schreef op donderdag 03 september 2015 @ 00:46:
Ik heb nooit composer gebruikt, maar zoals jij het beschrijft is het dan niet simpelweg overbodig?

Want in wezen verwacht ik juist van een programma wat zich noemt "Dependency Manager for PHP" dat het ook je dependency's managed en dat gewoon regelt.

Dat is wmb ook wat een nuget doet bij .Net of een Maven bij Java of een apt-get bij ubuntu etc. etc.

Tuurlijk kan er zo heel af en toe wel eens een conflict optreden, maar zoals jij het beschrijft heb ik het gevoel dat ik dat had toen alles handmatig van git af zat te clonen en op schijf een beetje bij elkaar zat te graaien.

Een dependance manager moet je juist hiervan af helpen.
Weet je wel zeker dat je composer gebruikt zoals het bedoeld is ,dus bijv niet in de dependency's zelf zitten editten alhoewel ik vermoed dat het wel kan omdat alles plain text is of zelf even een git patch draaien of ... of... want anders beland je in een dependance hell omdat je zit te vechten tegen je dependance manager.

Of zit je bijv alles van unstable/alpha te pakken (ik neem aan dat er zo'n soort branch is binnen composer) waardoor je het zelf deels uitlokt (wil je het niet moet je naar stable gaan)

Want als het echt zo is als jij omschrijft dan zou Composer wmb compleet waardeloos zijn en direct te vervangen door een git-clone scriptje. En ik meen meegekregen te hebben dat Composer best wel aardig in elkaar zit, dus ik vermoed dat jij iets fout doet.

Dit zou inderdaad zo zijn als je het volledig aan Composer over laat welke versie packages je gebruikt. Dat is in mijn geval vaak niet (volledig) zo.

Het kan zo zijn dat package A package X 1.0.0 vereist, maar package B wil X 1.1.0 wil hebben. Als je zelf een nieuwe feature uit X wil gebruiken, dan wil je misschien wel X 1.3.0 hebben. A verwacht dus minimaal 1.0.0 en 1.3.0 voldoet daar aan. Daarmee is compatibiliteit niet gegarandeerd.

[Cartman!]

Volgens semver zou 1.0.0 en 1.3.0 gewoon compatible moeten zijn en daar zou Composer dan ook niet over gaan zeuren

Het enige praktijkprobleem wat ik tegenkom is Guzzle die Barry al noemde, een paar packages wilden ~5.0 hebben terwijl AWS SDK ~6.0 wilde en dat kan niet. Geen probleem van Composer opzich want die kan daar niks aan doen. Gelukkig ondersteunt AWS SDK momenteel ook ~5.0 nog

[Gomez12]

StephanVierkant schreef op donderdag 03 september 2015 @ 22:31:
[...]
Dit zou inderdaad zo zijn als je het volledig aan Composer over laat welke versie packages je gebruikt. Dat is in mijn geval vaak niet (volledig) zo.

Het kan zo zijn dat package A package X 1.0.0 vereist, maar package B wil X 1.1.0 wil hebben. Als je zelf een nieuwe feature uit X wil gebruiken, dan wil je misschien wel X 1.3.0 hebben. A verwacht dus minimaal 1.0.0 en 1.3.0 voldoet daar aan. Daarmee is compatibiliteit niet gegarandeerd.

Waarom zeg je in je 1e zin dat het niet zo is, terwijl het wel zo zou moeten zijn in jouw voorbeeld (in mijn optiek)...

Composer hoort de nieuwste versie te pakken van een dependency, een dependency moet imho geen specifieke versies vereisen, alleen een onderversie (en wellicht een bovenversie bij breaking changes als een major release)

Volgens alle gangbare dependency logica die ik ken moet een 1.3.0 (extreme uitzonderingen daargelaten) compatibel zijn met 1.0.0.
Is dit niet zo dan moet je de maker van de dependency aanschrijven en met de voeten stemmen, want makers die zich niet aan conventies houden veroorzaken dit soort dependency hells en daar gaat geen tooltje bij helpen, daar moet echt de maker iets aan doen.

Maar ook jij moet er iets aan doen, want als jij een nieuwe feature uit 1.3 wilt gebruiken maar die is niet compatibel met 1.1 dan moet je misschien 1.3 maar even laten liggen en wachten op 1.4.

Zoals jij het beschrijft maken de makers van de dependency's er een bende van, maar binnen die bende valt op zich nog wel enigszins te werken. Alleen jij lijkt er bewust voor te kiezen om die (al gecreëerde) bende te verergeren door het nog complexer te maken.

Ik ken het wel hoor wat jij beschrijft, maar dan incidenteel en dan kies ik er veelal voor om of zelf de dependency los te laten en de source binnen mijn project te trekken, of ik laat de hippe feature zitten.
Het is alleen een keuze die je gewoon eenmalig moet maken en dan ook doorvoeren, niet op 2 paarden wedden en dan verbaasd zijn dat er maar 1 kan winnen.