Re: [SPIPremix] Une distribution SPIP alternative

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.

Pour les cas hébergés wordpress, spip et Prestashop. 3 solutions qui
actuellement proposent une interface pour gérer tant les extensions
que les mise à jour. Plus du php/html legacy/maison.

Pour le cas avec composer, c'est suite à une installation Thelia.
Sachant que l'ecommerçant ne maitrise rien, c'est l'agence qui bose.
Pour les autres cas ce sont des dev maisons de l'agence qui pousse
ensuite via ftp sur l'hébergement concerné.


>> 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.

Il n'oriente pas sur la technologie c'est technologique. Je reformule
donc ma remarque initiale en enlevant PHP de ma phrase.
Composer est un truc de développeur pour développeur (quelque soit son langage).

Et encore parmi les personnes qui développe que je côtoie, parler de
ligne de commande c'est parfois compliqué.


> C'est difficilement
> comparable. Donc a fortiori opposable.

Maîtriser ssh et la ligne de commande n'est pas équivalent à utiliser
une interface web.A mon sens ce n'est pas pas opposable et l'un ne
remplace pas l'autre. Les publics et usages sont différents et se
croisent.


> 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.

Ma remarque n'avait rien à voir avec ce point. Désolé si on s'est mal compris.


> 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.

Pas rapport à la remarque initiale, cela me semble hors sujet. En tant
qu'hébergeur le choix du développement (psr ou autre) n'a aucune sorte
d'importance.

> 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.

Oui c'est là où ça coince car la maquette montre qu'on peut utiliser
composer comme gestionnaire de dépendance mais ne remplace pas le
gestionnaire actuel qu'est SVP.
Au vu de l'objectif et du fonctionnement pour la partie spip_loader on
peut contourner le problème vu qu'on fournit une archive à installer.

L'utilisabilité de la chose est aussi importante que la faisabilité
(ce qui est démontré)

Km