Re: Piste de conception d'interface SPIP-Composer

RastaPopoulos <[email protected]>
Newsgroups gmane.comp.web.spip.devel
Message-ID <[email protected]>
Le 01/04/2019 à 11:29, JLuc a écrit :
> Moi je m'interroge sur la qualité de Composer.
> Pas évident ni basique, mais la gestion d'un graphe de dépendances
> semble être un problème algorythmique très classique.
> Qu'est ce qui nécessite donc des ressources mémoire et matérielles
> aussi lourdes ?

Euh faut pas exagérer… Composer gère un graphe beaucoup plus gros que ce
que nous on gérait, et y compris par rapport à la version de PHP
installé, enfin ya plein de contraintes. C'est le cœur de l'éco-système
PHP depuis des années, c'est utilisé littéralement par des millions de
gens et maintenu par beaucoup aussi, donc je ne m'inquiète absolument
pas de la qualité et de la pérennité de Composer lui-même.

Moi là je parle de *l'ensemble* de ce qu'il faut mettre en œuvre pour
juste arriver à avoir un truc iso-fonctionnel : pouvoir chercher et
installer des plugins depuis l'interface d'un SPIP. Et là ça parait
foufou tout ce qu'il faut faire (et qu'on a pas encore, et qui n'existe
toujours pas en libre) pour arriver à obtenir ce qu'on avait avec SVP,
et que la plupart de nos utilisateurices ne veulent pas perdre.

Mais on perd aussi énormément en s'isolant de Composer pour les plugins
(pour le core c'est bon c'est pas un problème)… Bref, ça fait encore
réfléchir…
(Je le redis encore pour que ce soit hyper clair, je parle pas du core,
mais bien de comment on va continuer à développer nos plugins.)

-- 
RastaPopoulos

_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.