Salut Rasta,
Bien sûr, si c'est un choix assumé pour spip-cli, pas de soucis, mais tu
peux ménager le chou et la chèvre avec la version 2.8 de symfony/console
qui sera maintenue jusqu'en nombre 2019. Ce qui laisse le temps de voir
venir
Oui ça ne me convient pas, et je suis d'accord. Je vais revenir en arrière.
avec un composer.json qui contiendrait ça :
C'est quoi config platform ?
D'autres part, je pense que tu pourrais suggérer lors de l'installation
d'utiliser la commande "composer install" après le "svn co/svn up". Si
l'utilisateur dispose d'un php-cli, il peut assez facilement installer
composer (il y a par exemple un paquet composer natif dans fedora depuis
quelques temps, merci Rémi Collet)
Ça je suis encore indécis. Dans l'absolu je préférerais. Moi, en tant
que dev, j'ai évidemment Composer installé. Mais ce n'est pas pareil de
forcer à l'installer juste pour *utiliser*. Or dans l'écosystème SPIP,
on n'a pas l'habitude de ça, et on n'utilise pas cette outil. Là ça
permet d'avoir tout prêt quasi packagé dans un même dossier, on peut
même le ziper avec les outils déjà existant de archivelist. Du coup j'ai
du mal à sauter le pas encore sur ce point, tant qu'on ne l'utilise pas
vraiment (et tant que là c'est juste un unique composant installé, si
c'était une appli avec 25 trucs, ça ne serait pas viable). Mais je suis
d'accord que ça ne devrait pas être comme ça normalement…
--
RastaPopoulos
Le 20 mars 2018 à 23:45, RastaPopoulos <rastapopoulos@spip.org> a écrit :
C'est quoi config platform ?
Un attribut qui permet tromper le résolveur de dépendances pour garantir le
choix des versions des composants qui fonctionneront sur un environnement
de production dont on sait quelle sera la version de PHP. Dans l'exemple
que je donne, pour les version 5 à partir de 5.4 et 7
On peut aussi jouer sur la version d'une extension de PHP.
Outre le constitution du répertoire vendor/, composer génére et met à jour
un fichier composer.lock, qu'il est recommandé de versionner. Cela
économise le recalcul effectué sur la machine du développeur pour
l'installation sur les plates-formes cible ou les systèmes de packaging et
garanti que les versions seront identiques d'une installation à l'autre.
> D'autres part, je pense que tu pourrais suggérer lors de l'installation
> d'utiliser la commande "composer install" après le "svn co/svn up". Si
> l'utilisateur dispose d'un php-cli, il peut assez facilement installer
> composer (il y a par exemple un paquet composer natif dans fedora depuis
> quelques temps, merci Rémi ColletÇa je suis encore indécis. Dans l'absolu je préférerais. Moi, en tant
que dev, j'ai évidemment Composer installé. Mais ce n'est pas pareil de
forcer à l'installer juste pour *utiliser*. Or dans l'écosystème SPIP,
on n'a pas l'habitude de ça, et on n'utilise pas cette outil.
Je comprends ton raisonnement et ta démarche. Mais :
Il n'y a peut-être pas que SPIP d'installé sur les plates-formes des
utilisateurs. Il est peut-être déjà présent.
Comme dit plus haut, composer sert aussi dans certaines phases de
packaging, des installations et dans certains cas pour les mises à jour,
tout dépend de la méthode de déploiement utilisée.
Proposer aux utilisateurs de l'installer maintenant pour spip-cli, c'est
aussi s'assurer que ce ne sera pas un problème pour d'autres usages dans le
futur.
Là ça permet d'avoir tout prêt quasi packagé dans un même dossier, on peut
même le ziper avec les outils déjà existant de archivelist.
On pourrait avantageusement produire un fichier phar directement exécutable
par un php-cli et directement téléchargeable (via curl ou wget, ou à la
main depuis un navigateur). Et là, plus besoin d'exiger la présence de
composer sur la plate-forme cible, ni de versionner le répertoire vendor/
dans le dépôt.
Là encore, la méthode de compilation en phar peut être codée dans le même
dépôt et la machine qui produirait le phar aurait besoin de php-cli et de
composer. Il n'y aurait plus qu'à le déposer dans un répertoire web.
Je veux bien regarder, si ça t'intéresse, mais je ne peux pas garantir de
délai ! 
Du coup j'ai du mal à sauter le pas encore sur ce point, tant qu'on ne
l'utilise pas
vraiment (et tant que là c'est juste un unique composant installé, si
c'était une appli avec 25 trucs, ça ne serait pas viable). Mais je suis
d'accord que ça ne devrait pas être comme ça normalement…
Y a pas le feu. Cependant, faut bien commencer un jour.
--
RastaPopoulos
--
James
Le 21 mars 2018 à 00:20, James <james@rezo.net> a écrit :
Le 20 mars 2018 à 23:45, RastaPopoulos <rastapopoulos@spip.org> a écrit :
C'est quoi config platform ?
Un attribut qui permet tromper le résolveur de dépendances pour garantir
le choix des versions des composants qui fonctionneront sur un
environnement de production dont on sait quelle sera la version de PHP.
Dans l'exemple que je donne, pour les version 5 à partir de 5.4 et 7
Oups, c'est parti trop vite !
Dans l'exemple que je donne pour une 5.4 minimum :
"require" indique que le code de spip-cli "nécessite" une version PHP 5 à
partir de 5.4 ou 7 et plus
"config.plateform.php" dit qu'il faut rechercher les versions des
composants (ici symfony/console) comme s'il s'agissait d'une machine avec
php 5.4.45
--
James
Le 20/03/2018 à 23:10, James a écrit :
ou bien pour une version PHP5.4 mini en fonction du code même de spip-cli
{
"require": {
"php": "^5.4|^7",
"symfony/console": "^2.8"
},
"config": {
"platform": {
"php": "5.4.45"
}
}
}
Yo,
j'ai donc mis à jour pour revenir à la version 2.8 et PHP 5.4 (ping
b_b), supprimé le dossier vendor/ complètement, mis à jour svn:ignore
pour ignorer désormais tout vendor/, et enfin mis à jour la
documentation pour dire d'avoir Composer et de faire composer install.
--
RastaPopoulos
Hop,
Le 24/03/2018 à 12:14, RastaPopoulos a écrit :
Yo,
j'ai donc mis à jour pour revenir à la version 2.8 et PHP 5.4 (ping
b_b), supprimé le dossier vendor/ complètement, mis à jour svn:ignore
pour ignorer désormais tout vendor/, et enfin mis à jour la
documentation pour dire d'avoir Composer et de faire composer install.
Super, merci mignon
++
b_b
Mise à jour OK chez moi sur OSX.
Merci !