Re: Mise à jour git.spip.net

>     Merci Luis, meilleur résumé ever!

Bé non, le meilleur résumé, c'est aussi le point rappelé par Marcimat
juste avant, pour l'instant.

Et c'est pour ce genre de merdouille, que non ça ne suffit absolument
pas que juste "spip/spip" soit sur packagist, et que donc juste
"spip/spip" soit sur Github, avec tout le reste ailleurs.

Et pareil pour les plugins donc ou autre projet de la communauté qui
pourraient être utilisés ailleurs (y compris d'autres distributions
donc, pas perso mais bien maintenues par la communauté, geodiv ou autre).

> Finalement après tous ces échanges, certains supplémentaires sur IRC et
> même de honteuses discussions en privé (gnarf, gnarf) j'en arrive à me
> dire que je préfèrerais continuer le travail Gitea actuellement mené par
> Camille pour passer définitivement la zone et spip en Git, et ce
> rapidement. 

D'après ce que je comprends toujours de Composer, je ne vois toujours
pas de solution vraiment pour que les choses soient ailleurs et que ce
soit facile de tout installer *ou dépendre* depuis un autre projet, afin
de s'insérer un peu dans l'écosystème PHP.

Le but c'est pas juste pour nous qui connaissons tout déjà (dans ce cas
fuck composer), mais bien à la fois pour pouvoir dépendre de libs
externes facilement, et de pouvoir déployer des choses SPIP avec
composer (donc installer et dépendre avec les require).

Techniquement, pour le noyau dans un projet temps, c'est pas des trucs
nouveaux à coder, quasiment tout est là (voire vraiment tout). Mais il
faut que tout soit sur Packagist, donc sur github.com ou gitlab.com. Et
le problème se posera encore plus pour les plugins ensuite, le garder en
tête.

Là on doit déjà passer un peu de temps à débattre et définir vers quelle
infrastructure on bascule, donc autant passer direct à un truc qui a une
vue un peu plus loin que juste Git ou juste "la dist de base" en
composer. Ce n'est pas comme si c'était un chantier plus important que
de rester avec nos trucs maintenus persos, c'est justement plutôt l'inverse.

Dépendre de services tiers, ça se réfléchit évidemment au cas par cas,
suivant quelle dépendance on accepte : si on est assuré que tout 100%
peut être déplacé en peu de temps ailleurs, si un jour ça se gâte, ya
quand même immensément moins de frein. Car là on ne le fait pas parce
qu'on trouve le Grand Capital super plus cool et ergonomique (avoir son
instance Gitlab c'est très bien), mais prosaiquement parce que Packagist
ne gère que github.com. Si un jour c'est facile d'installer depuis son
instance sans demander de la config aux utilisateurs, on se barre
ailleurs et basta.

J'ai lu des trucs sur IRC qui disaient "au moins là on aura Git
rapidement, ça sera déjà ça, et Composer ça n'existe pas encore, on
verra quand ça avancera". Mais justement ! Ça va vers l'argument inverse
: ça fait longtemps que Composer ça traine, et si on choisit une
infrastructure qui va rendre encore plus embêtant sa mise en place et
son utilisation, bah ça augmentera sûrement la probabilité que ça recule
encore.

Mais si on me prouve qu'on peut avoir nos trucs persos *sans gêner
aucune utilisation facile*, et pas juste pour la dist de base (un des
multiples buts du découpage et de composer, c'est de pouvoir avoir plus
de distributions complètes, et facile à maintenir, donc à distribuer
aussi), alors super, moi aussi évidemment je trouve mieux quand on a des
outils libres (et que plus d'une personne sait).

-- 
RastaPopoulos

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