Re: [spip-dev] Mise à jour git.spip .net

Salut
> Cette discussion tombe à pic car j'avoue ne plus être sur de la fin de la saison précédente et je me demande si les producteurs ont décidé ou pas de renouveler la série "Git & Composer" pour une nouvelle saison.
>
> Si je résume (surement très approximativement) ce que je comprends de la situation :
> - le "groupe de travail Composer" propose de passer SPIP (core + plugins-dist ?) sous Composer et donc pour faciliter l'administration (et patati patata) de migrer les sources sur la plateforme GitHub qui simplifie l'utilisation de Packagist. Le hic semble être GitHub pour certains même si on y a tous un compte...
> - Camille a tout préparé pour que les sources de SPIP soit sous GIT avec la plateforme open-source Gitea qui n'est pas totalement compatible avec Packagist en l'état. Et Camille fait remarquer que si on migre sous GitHub on ne reviendra jamais sur Gitea, si dans le futur, Gitea devient "compatible Packagist" ou le contraire.
>
> Le problème c'est que personne n'a vraiment tort et donc résultat : on est bloqué comme cela nous est déjà arrivé et j'ai l'impression que cette idée de Composer est repoussée aux calendes grecques alors qu'elle est prometteuse et permettrait de sortir un peu de notre torpeur estivale.
>
> Aussi, a-t-on une porte de sortie rapide à cette situation ?
> Je trouve la situation actuelle plus délétère qu'une potentielle "erreur" d'aiguillage.
> Le choix GitHub est-il vraiment si terrible ?
>
>
> Vos avis ?

Comme depuis un moment les 2 trucs sont compatibles et n'ont pas grand
chose à voir.
Par exemple wordpress refuse composer et travaille avec svn et
pourtant il existe une solution composer

Parmi les freins identifiés (et que j'ai compris)
* le problème des versions, dans le svn les tags sont relatifs à SPIP
et non au plugin lui même
* la possibilité de télécharger les zip (raison de github)
* une nomenclature des organisations pour respecter la logique de
nommage de composer.
* le choix de la forge
* la mise à disposition des paquets au format composer


Pour le premier point, cela est réglé via
https://git.spip.net/_outils_/creer_tags (il y a déjà un mail
spécifique pour expliquer son comportement)

Pour le second point, le plus simple serait de fournir un driver gitea
pour composer qui permettrait de choisir git ou zip.
 Ce point me semble mineur car si on utilise composer on a très
probablement la main sur la machine cible et donc la possibilité
d'installer aussi git
 L'api de gitea est proche de celle de de github, on peut donc
envisager de proposer le dit driver à composer pour supporter les
archives zip.
 Enfin il est toujours possible d'avoir github en miroir de gitea
(c'est déjà le cas pour la partie core de spip)

Pour le troisième point, il n'y a toujours pas eu de décision aux
diverses questions soulevées par mail. Cette non décision bloque la
pérennité de nommage dans les dépôts git ( peu importe la forge)
  Ce point me semble le plus problématique car il est uniquement organisationnel

Pour le quatrième point, je pense toujours que github est un mauvais
choix par défaut
  Ce mois ci une partie des contributeurs ont été bloqués juste pour
une histoire de politique américaine
  Ensuite il est tout à fait possible d'avoir github en miroir, c'est
déjà le cas
  git.spip.net fonctionne
  De mon coté j'aurais le même discours pour toute autre forge
propriétaire qui aurait pour vocation de gérer une communauté
complète. Il n'y a pas de transparence, pas de maîtrise, ...

Pour le cinquième point, packagist, satis simplifient énormément
l'écriture du fichier composer.json  (car ils fournissent les
correspondances de téléchargement/version/paquet).
  On peut s'en passer à condition d'écrire un fichier assez verbeux
(ce que j'ai testé et qui fonctionne)
  De ce que j'ai identifié il y a 2 morceaux importants
https://github.com/spipremix/composer-installer pour ranger les
différents projets git à leur place et le metapaquet pour piloter tout
ça


Actuellement il est possible d'utiliser composer (certes c'est un gros
fichier) d'autant plus qu'il est tout à fait possible d'améliorer
l'existant sans remettre en cause et tout casser car le futur c'est
mieux.
En tout cas de mon coté je travaille sur les différents points qui
seraient considérés comme bloquant.


Km
----
[email protected] - https://listes.rezo.net/mailman/listinfo/spip-zone