Re: Maquette SPIPRemix, intégration de Co mposer dans le développement de SPIP

Le 18 mai 2018 à 13:52, [email protected] <[email protected]> a
écrit :

> Salut
>

Salut,


>
> En remarque :
> * J'ai l'impression qu'on pourrait proposer des vendors réservés
> utilisable par défaut comme genre "spip-plugins"  (qui pourrait
> reprendre la logique de découpage actuel)
>

Je ne suis pas sûr de comprendre, mais a priori, on ne peut pas "réserver"
des vendors, en tout cas techniquement. Le rôle de la partie vendor dans le
nom d'un composant est informatif et désigne grosso/modo l'équipe de
maintenance. Le type suffit amplement pour produire des effets lors de
l'installation. Le choix des termes qui identifient ces types s'appuie sur
les recommandations qu'on trouve un peu partout, notamment dans la doc de
Composer.


> * Cela ne résout pas la confusion qu'on entretien avec les squelettes/
> , là on ne prend en charge que ceux qui fonctionnent comme des
> plugins.
>

Je ne comprends pas. Vous entretenez quoi comme confusion ? Et je ne vois
pas ce qu'il y a à faire avec des contributions qui ne sont pas des
plugins/composants. Vu que l'idée et la proposition qui est faite, c'est de
gérer des composants...


> * On range au même niveau des outils comme l'écran de sécurité qui ne
> sont ni plugins, ni squelettes , ni rien d'autres. Du coup ça fait un
> gros fourre tout qui mélange des concepts
>
>
Tout est composant, on ne mélange rien avec composer. C'est un mécanisme de
distribution et de gestion de dépendances. C'est ce qu'on développe (en
l’occurrence ici SPIP) qui définit ses concepts pour lequel Composer est
totalement agnostique (comme il l'est pour Symfony, Drupal et une multitude
d'autres logiciels). Je ne comprends pas ta remarque du coup.

Km
>

Amicalement,
-- 
James