composer configuration & remove /vendor

[pifou25]

Description

Dépendances Composer:

• "symfony/http-client": "^5.4" c'est la version minimale pour PHP7.3
• composer.lock mis à jour via composer update
• suppression du rep /vendor
• exclusion de /vendor dans le backup et la resauration, il est regénéré après restore
• ajouter un workflow pour passer l'installation composer, en php7.3 et php8.2
• oter les .github/workflow et composer.lock du fichier .gitignore

note pour le release-manager : il est conseillé de mettre à jour le composer.lock régulièrement, genre à chaque mise à jour du core, même mineur. Pour cela une seule commande: composer update puis commit le composer.lock modifié
Le composer.json ne sera mis à jour que exceptionnellement si des besoins spécifiques l'exigent (de nouvelle lib ou upgrade de lib existante)

TODO : inclure ces maj de dépendances dans un dependabot ?

Suggested changelog entry

configuration composer & remove /vendor from repository

Related issues/external references

Fixes #2418

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the [La ligne directrice pour contribuer à ce projet / Contribution guidelines for this project).
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[zoic21]

Bonjour,
Merci pour ce PR je le planifie pour la 4.5 qui devrait pas tarder a arriver en alpha.

[pifou25]

le plugin composer sous VSCode affiche entre parenthèse sur le fichier composer.json la vrai version des packages installés...
résultat sous php7.3:

et pour php8.2 après avoir fait un composer update

[zoic21]

Bonjour,
On va pouvoir reprendre ca, j'ai deja supprimé pas mal de dépendances pas vraiment utile (en reprenant le code en interne dans le code). Je pense qu'il y a encore pas mal de dépendance inutiles a nettoyer.
J'ai aussi supprimé les restrictions a php 8 pour l'installation et l'update des dépendances composer. Cela se fera maintenant tout le temps.
J'ai aussi tenté une expérience en supprimant le fichier composer.lock (sinon composer ne nettoie pas les dépendances supprimé de composer.json).

Je pense donc qu'il reste a :

• gérer les versions des dépendances en fonction des versions de php
• supprimer le dossier vendor du GitHub
• ne plus le backuper (ca je suis pas sur, j'ai peur que ca pose soucis lors de certaine restauration)

[zoic21]

Lors d'une mise a jour le core supprime le dossier vendor avant de copier les fichiers maintenant, a voir si tous se passe bien et si c'est le cas on pourra le retirer du git.

[pifou25]

Bonjour,
Je ne vois pas tes modifs, c'est sur une autre PR ? en plus celle-ci est en conflit maintenant :'(

• gérer les versions des dépendances en fonction des versions de php

Je ne vois pas comment on peut faire ça : proposer 2 fichiers composer.lock, 1 pour php8+ et 1 pour php7 ?
Pour moi il vaut mieux juste conserver pour chaque package la version la plus haute qui reste compatible avec php7.3 et s'assurer qu'elle est aussi compatible php8.2 : c'est le job "Validate Composer dependencies / build-test" qui fait ça, que j'ai ajouté dans cette PR il fait un "composer validate"

• ne plus backuper le /vendor

dans cette PR je l'ai exclu du backup & du restore, et le restore refait la commande "composer install". Dans quel cas on doit faire un update pour php8 ?

[pifou25]

J'ai tenté de corriger les conflits, et du coup j'ai compris tes modifs, ... il ne faut pas supprimer le composer.lock à chaque install (sinon, pourquoi on l'aurait versionné?) par contre, il faut en effet nettoyer le fichier lorsqu'on modifie le composer.json - et je l'ai fait dans cette PR.
Il faut lancer la commande composer update puis commiter le composer.lock ... et en effet il y a eu grand ménage :)

Lock file operations: 0 installs, 14 updates, 24 removals

• Removing abbadon1334/sun-position-spa-php (2.0.0)
• Removing clue/stream-filter (v1.7.0)
• Removing doctrine/cache (1.13.0)
• Removing knplabs/github-api (v3.14.1)
• Removing league/flysystem (1.1.10)
• Removing league/flysystem-webdav (1.0.10)
• Removing league/mime-type-detection (1.12.0)
• Removing php-http/cache-plugin (2.0.0)
• Removing php-http/client-common (2.7.1)
• Removing php-http/discovery (1.19.4)
• Removing php-http/httplug (2.4.0)
• Removing php-http/message (1.16.1)
• Removing php-http/multipart-stream-builder (1.3.1)
• Removing php-http/promise (1.3.1)
• Removing psr/http-client (1.0.3)
• Removing sabre/dav (4.6.0)
• Removing sabre/event (5.1.4)
• Removing sabre/http (5.1.10)
• Removing sabre/uri (2.2.4)
• Removing sabre/vobject (4.5.5)
• Removing sabre/xml (2.2.7)

En passant, ceci corrige le test "Validate Composer dependencies" qui plantait justement pour cette raison:

Building PHP 7.3 with extensions: ...
./composer.json is valid, but with a few warnings
See https://getcomposer.org/doc/04-schema.md for details on the schema

Lock file errors

• The lock file is not up to date with the latest changes in composer.json, it is recommended that you run composer update or composer update <package name>.

Aussi, je rajoute "platform.php=7.3" dans le composer.json pour que l'on update bien les dépendances en respectant cette version minimale de compatibilité - sinon quand on fait composer update en local, ça le fait avec la version dispo et j'étais en php8

[zoic21]

Salut,

Pas sur de tout comprendre :

• pour le menage des dépendances c'est pas fini yen reste encore (monologue par exemple)
• pour le lock je suis partagé dans le composer.json je fix les versions deja et il respect ca donc si je supprime le lock il se realigne avec le composer.json et c'est bon non ?
• pour platform.php=7.3 pour moi non, si tu es en php8 il doit prendre les dépendances php8 ya pas de soucis la dessus jeedom est compatible avec les 2 sans probleme.

[pifou25]

Les versions dans composer.json ne sont pas stricte, ça permet une mise à jour avec la dernière version sortie, en particulier avec cette syntaxe:
"symfony/expression-language": "5 - 7" => n'importe quelle version entre 5 ou 7
"guzzlehttp/guzzle" : "^6.5.8", n'importe quelle version entre 6.5.8 et 7.0.0 exclu
(cf https://getcomposer.org/doc/articles/versions.md les contraintes du fichier composer.json)

Ou alors il faudrait tout fixer jusqu'au numéro majeur / mineur / fix pour chaque package, ce qu'on ne fait jamais, et encore même la, on n'est pas à l'abri d'une livraison d'un RCx ou versionning ésotérique...
Donc, à chaque fois que tu supprime le .lock et que tu reinstalle, tu n'es pas sûr d'avoir les mêmes versions de tous ces packages... une mise à jour imprévue qui pourrait casser une compatibilité avec un autre package ou contenir une regression sera donc automatiquement installée sur toute nouvelle installation.
Au contraire, lorsqu'on modifie le composer.json - typiquement si on fait du ménage, on supprime monolog par ex. - on refait le composer update => maj du .lock et on commit ces modifs. Déjà on a fait un minimum de test avant en local ;) et ensuite, il y a les 2 checks dédié dont 1 que j'ai rajouté sur cette PR 👍

• Validate Composer dependencies : fait un "composer validate" donc vérifie la validité des fichiers json & lock https://getcomposer.org/doc/03-cli.md#validate
• Docker Build and Test Image : fait un build docker de l'image, démarre le container (initialisation incluant l'install composer), et lance le test sick.php ... pour php7.3 et 8.2 (en fait pour bullseye et bookworm)

Maintenant, si on veut avoir des packages plus récents sur php8 que ceux dispo pour php7... Je ne vois qu'une seule solution : il faudrait créer un fichier composer.lock.php8 et lors de l'install, si on est en php8 on remplace le composer.lock par celui-ci avant de faire l'installation composer... Mais est-ce vraiment nécessaire ?

[pifou25]

bon dsl j'ai fait une nouvelle PR qui annule et remplace, celle-ci ça devient trop le bordel... :/
#2905