[spip-dev] Distributions SPIP "officielles"

Dev
1

Hello !

Puisqu’on en est à relancer un peu le débat sur les distrib, je renvoie de façon plus large ce mail qui date de Septembre :

En regardant le pied de page actuel du site http://svp.smellup.net/, on peut lire :
→ “Ce site sous SPIP 3.0.0-alpha2 SVN [18405] utilise les plugins : ….” suivi de la liste des plugins hors extensions (je vous dis pas la boucle plugins avec un NOT IN de la mort…).

Mais cette information est “fausse” car justement elle ne fait pas référence à ces “extensions”. Il serait plus judicieux de pouvoir écrire :
→ “Ce site sous SPIP 3.0.0-alpha2 SVN [18405] édition "La Totale "utilise les plugins : ….”

Donc mon propos c’est bien sur les distributions de SPIP 3, car à mon avis, nous ne pouvons plus faire l’économie de cette notion avec cette version qui a exporté 24 fonctionnalités hors du core. Et il faut faire cela pour la sortie officielle de SPIP 3 car le terme SPIP 3.0.0 ne désigne a priori que le core et qu’il est fort probable que nous ne le distribuerons jamais car il ne fonctionne pas seul !

Donc :

  1. il faut définir deux ou trois distributions “officielles” gérée en configuration par le Core et accessible au téléchargement ou en svn. Je vois simplement déjà :
  • la distribution minimale “édition bikini” avec le core SPIP 3 + mots et la dist qui est a priori la PPDF :slight_smile:
  • la distribution maximale “édition la totale” avec le core SPIP 3 + tous les “plugins du core” actuel.
    Ces distributions doivent être nommée (un peu comme ubuntu) et posséder un fichier descriptif (on verra plus tard, j’en reste ici aux concepts).
  1. Il faut aussi clarifier la notion “d’extensions” en la limitant à :
  • une extension est un plugin ni plus ni moins
  • le répertoire extensions/ n’est qu’un mécanisme technique pour définir une liste de plugins non désactivables “simplement” mais on pourrait très bien le remplacer par un autre mécanisme comme nous l’avons proposer avec Denis et Romy dans la nouvelle interface des plugins : http://blog.smellup.net/spip.php?article38
  • une distribution SPIP installe toujours ses plugins en “extensions”
  1. En corollaire du 2) :
  • il faudrait déplacer les plugins de core/plugins vers plugins/ comme tous les autres.
  • créer les “liens” pour extraire par svn chaque distribution et les “archivelist” pour zipper chaque distribution.
  • distribuer sur les espaces habituels uniquement les zips des distributions.

A votre avis ?

2

29/12/2011, Eric:

Donc mon propos c'est bien sur les distributions de SPIP 3, car à mon
avis, nous ne pouvons plus faire l'économie de cette notion avec
cette version qui a exporté 24 fonctionnalités hors du core. Et il
faut faire cela pour la sortie officielle de SPIP 3 car le terme SPIP
3.0.0 ne désigne a priori que le core et qu'il est fort probable que
nous ne le distribuerons jamais car il ne fonctionne pas seul !

Donc :

0) Il faut que le core puisse fonctionner seul. Si une extension est
nécessaire, alors aucun intérêt de la sortir du core.

1) il faut définir deux ou trois distributions "officielles" gérée en
configuration par le Core et accessible au téléchargement ou en svn.
Je vois simplement déjà :
- la distribution minimale "édition bikini" avec le core SPIP 3 +
mots et la dist qui est a priori la PPDF :slight_smile:

J'adore le terme de distribution bikini ! Par contre je sais pas si
c'est une bonne idée de distribution, ou alors peut-être que j'ai pas
compris son but. Un bikini c'est quand même enlevable (pour avoir le
core nu), du coup cette distribution bikini ne doit pas être juste un
palliatif au point 0 soulevé plus haut.

- la distribution maximale "édition la totale" avec le core SPIP 3 +
tous les "plugins du core" actuel.
Ces distributions doivent être nommée (un peu comme ubuntu) et
posséder un fichier descriptif (on verra plus tard, j'en reste ici
aux concepts).

C'est peut-être ce que tu dis mais je vais formuler comment je le vois:
les distributions sont finalement des "collections" ou "cocktails" de
plugins pour certains usages (journal/news, media, blog, etc.).

Quant à la source de ces cocktails, effectivement on peut en suggérer
officiellement certains, tout en laissant la possibilité aux gens
d'élaborer et distribuer les leurs facilement.

2) Il faut aussi clarifier la notion "d'extensions" en la limitant à :
- une extension est un plugin ni plus ni moins

À fond.

- le répertoire extensions/ n'est qu'un mécanisme technique pour
définir une liste de plugins non désactivables "simplement" mais on
pourrait très bien le remplacer par un autre mécanisme comme nous
l'avons proposer avec Denis et Romy dans la nouvelle interface des
plugins : Une nouvelle interface d'administration des Plugins - La Taverne à Tonton

Carrément.

- une distribution SPIP installe toujours ses plugins en "extensions"

Oui et non. "Livré par défaut" et "non désactivable" sont deux besoins
différents. Par exemple une distribution de publication facile peut
décider de fournir les crayons par défaut sans pour autant les rendre
obligatoires.

Du coup une distribution pourrait par exemple juste pré-remplir le
répertoire plugins (c'est juste une idée d'implémentation).

3) En corollaire du 2) :
- il faudrait déplacer les plugins de _core_/plugins vers _plugins_/
comme tous les autres.

Grave.

- créer les "liens" pour extraire par svn chaque distribution et les
"archivelist" pour zipper chaque distribution.
- distribuer sur les espaces habituels uniquement les zips des
distributions.

Lapin compris.

3

Hello,

Avec ces distributions, quels seront les mécanismes de mise à jour
pour maintenir la cohérence de l'ensemble tout en permettant son évolution ?

Je ne vois pas bien si ceux dans SVP suffiront ou si il faut une gestion plus 'globale',
au niveau d'une distrib.

JLuc

4

Yop,

J’adore le terme de distribution bikini ! Par contre je sais pas si
c’est une bonne idée de distribution, ou alors peut-être que j’ai pas
compris son but. Un bikini c’est quand même enlevable (pour avoir le
core nu), du coup cette distribution bikini ne doit pas être juste un
palliatif au point 0 soulevé plus haut.

Ben en fait nous ne pouvons pas actuellement distribuer le « core nu », non pas par censure, mais parce qu’il ne fonctionne pas. Le bikini est nécessaire (cad mots + dist et breves a vérifier).
Alors pour la dist c’est pas vraiment elle qu’il nous faut mais quelques pages pour les articles, rubriques par défaut dans le public donc c’est surement contournable mais mots je sais pas.

C’est peut-être ce que tu dis mais je vais formuler comment je le vois:
les distributions sont finalement des « collections » ou « cocktails » de
plugins pour certains usages (journal/news, media, blog, etc.).

Quant à la source de ces cocktails, effectivement on peut en suggérer
officiellement certains, tout en laissant la possibilité aux gens
d’élaborer et distribuer les leurs facilement.

Absolument, on est d’accord, je ne parle ici que de ce que SPIP distribue « officiellement ».
MediaSPIP est aussi une distribution par exemple.

  • une distribution SPIP installe toujours ses plugins en « extensions »

Oui et non. « Livré par défaut » et « non désactivable » sont deux besoins
différents. Par exemple une distribution de publication facile peut
décider de fournir les crayons par défaut sans pour autant les rendre
obligatoires.

Du coup une distribution pourrait par exemple juste pré-remplir le
répertoire plugins (c’est juste une idée d’implémentation).

Ben je serais plutôt pour que la distribution, qui est un tout soit verrouillée par défaut mais oui pourquoi pas un fonctionnement avec des plugins optionnels dirons nous.

  • créer les « liens » pour extraire par svn chaque distribution et les
    « archivelist » pour zipper chaque distribution.
  • distribuer sur les espaces habituels uniquement les zips des
    distributions.

Lapin compris.

Oui, à partir du moment ou ce ne sont plus des externals il faudra bien un moyen de regrouper un zip de la distribution. C’est du second ordre j’en conviens.

5

Cependant, je serais plutôt d'avis de trouver comment corriger ce point là pour SPIP 3. Autant aller jusqu'au bout de la démarche d'avoir sorti tout ce qu'on voulait du core, tout en permettant à celui ci de fonctionner non ?
Cela ressemble plus à un bug qu'à un véritable besoin.

6

Bonjour,

si, pour ceux qui veulent se servir de Spip comme d'un framework, ce qu'il est aussi, avant même d'être un cms prêt à l'emploi.
La seule chose indispensable dans ce core, c'est une page de réglage des options de spip. Pour le reste ...
Donc la "nécessité" doit être appréciée par rapport au fonctionnement de spip comme framework.

A côté de cela, il y a les extensions-plugins qui étendent le framework spip à un cms prêt à l'emploi.

Cordialement,
Bonnes fêtes,
RB

7

Yep,