Re: [SPIPremix] Une distribution SPIP alternative

Le 5 juillet 2018 à 10:40, [email protected] <[email protected]>
a écrit :

> Salut
>

Salut,


>
> Je sors ma casquette d'hébergeur. Sur l'ensemble des sites/serveurs
> que j'héberge je n'ai eu qu'une seule demande pour avoir un accès
> ssh/composer. Et c'est un cas particulier car c'est une agence web qui
> développe des sites avec une machine dédiée pour ceci.
>
> Dans tous les autres cas hébergés, c'est du (s)ftp(s) et usage des
> méthodes web pour installer les modules du cms utilisés. Et il ne
> seront ni prêt à payer une prestation pour qu'une personne s'occupe
> d'installer les modules (perte d'autonomie et de maîtrise) et ni prêt
> à se former à ssh/composer (on ne peut pas tout maîtriser). Dans ce
> cas ce sera un changement de crémerie.
>

Merci pour ce retour.

Peut-on savoir quels cms sont utilisés sur tes plates-formes et parmi eux,
lesquels, si c'est pas SPIP, offrent aussi une méthode web, stp ?
Cela permettrait d'aller les étudier et de faire des comparaisons. On a
peut-être là l'occasion d'améliorer spip_loader si nécessaire.


>
> Composer est une bonne solution pour gérer des dépendance et il est
> inutile de réinventer la roue quand celle ci existe et n'est pas
> carrée (la roue). Une des forces de SPIP c'est de ne pas être orienté
> développement php, ce qui est tout le contraire de composer. Il semble
> utile d'avoir un compromis et cela ne me semble pas incompatible.
>

Pour dissiper un malentendu, je me permets une petite précision :

composer n'oriente pas sur la technologie de développement. C'est, comme tu
l'indiques un gestionnaire de dépendances, pas un framework de
développement alors que SPIP pourrait être considéré comme tel. C'est
difficilement comparable. Donc a fortiori opposable.
Certes, composer est écrit en PHP, comme SPIP. Mais l'objet de la démo
SPIPRemix était bien de démontrer qu'il permet de gérer les dépendances de
SPIP, a priori pas orienté PHP.

Et ça marche : spip/dist est un squelette essentiellement basé sur html,
spip/prive aussi. Le squelettes de geodiv dans la distribution alternative
aussi. toujours dans geodiv, on peut s'apercevoir, si on regarde de près,
que certains plugins servent à distribuer des librairies javascript. Etc.

Ce qui oriente sur la technologie, et accessoirement les méthodes de
conception php différentes de ce qu'on fait dans SPIP aujourd'hui, ce sont
les PSR. Il y a déjà eu une discussion sur spip-dev à ce sujet et il est
vrai que Matthieu, entre autres, a très envie qu'on s'y intéresse.
J'avais pris la précaution de bien distinguer les deux choses (composer
d'un coté et PSR de l'autre) en arrêtant la démonstration à la seule
gestion de dépendances. Si cette solution est adoptée, il deviendrait
beaucoup plus facile de s'intéresser aux bénéfices que les PSRs
apporteraient à SPIP.

Le fait que SPIPRemix fait cohabiter des fichiers composer.json et
paquet.xml me semble prouver que le compromis est déjà trouvé, même s'il a
des cotés frustrants pour l'instant.
Je le rappelle, c'était la limite de la maquette. La suite demande qu'on
modifie du code.

>
>
>
> Km
>

Amicalement,
-- 
James