[spip-dev] distribution

Dev
1

Pour avancer sur la question des distributions je propose un (début
de) format de fichier de description :

<distribution>
  <nom>Un SPIP maison</nom>
  <description>Un SPIP tout nu avec les crayons en extension</description>
  <paquet id="core" methode="svn" options="--ignore-externals"
url="svn://trac.rezo.net/spip/branches/spip-2.1/" />
  <paquet id="crayons" methode="svn"
url="svn://zone.spip.org/spip-zone/_plugins_/crayons/"
path="extensions/crayons" />
</distribution>

et un script qui lit ce fichier et installe les paquets demandés :

http://zone.spip.org/trac/spip-zone/browser/dev/distribution

-- Fil

2

On notera que :
-- j'essaie de rester au plus proche de plugin.xml afin de pouvoir
mutualiser les outils
-- il y a du franglais (paquet / path)
-- ça ne règle pas la question des plugins "activés de force", qu'on
pourrait cependant peut-être traiter avec un actif="yo" dans le
<paquet> ? Mais du coup il faudrait que SPIP lise ce fichier de
description lui aussi, et pas seulement build.php

-- Fil

3

* Fil tapuscrivait, le 20/04/2011 11:23:

On notera que :
-- ça ne règle pas la question des plugins "activés de force",

Ben si, un plugin placé dans extensions/ est activé d'office.
Bon, il est pas désactivable sans accès FTP...

En tout cas, merci pour cette première brique !

-- RealET

4

* Fil tapuscrivait, le 20/04/2011 11:17:

Pour avancer sur la question des distributions je propose un (début
de) format de fichier de description :

<distribution>
  <nom>Un SPIP maison</nom>
  <description>Un SPIP tout nu avec les crayons en extension</description>
  <paquet id="core" methode="svn" options="--ignore-externals"
url="svn://trac.rezo.net/spip/branches/spip-2.1/" />
  <paquet id="crayons" methode="svn"
url="svn://zone.spip.org/spip-zone/_plugins_/crayons/"
path="extensions/crayons" />
</distribution>

et un script qui lit ce fichier et installe les paquets demandés :

Connexion · GitLab

Je note que ça ne gère *que* la méthode SVN (pour l'instant)

Du coup, quid des .zip ?
A priori, le php pour gérer les zip est :
- dans spip_loader
- dans le code de SPIP pour plugins/auto et libs/

Mais est-ce qu'il faut prévoir
- un .xml de distribution par méthode ?
- ou dans le même .xml les différentes méthodes ?

-- RealET

5

-- ça ne règle pas la question des plugins "activés de force",

Ben si, un plugin placé dans extensions/ est activé d'office.

oui c'est bien ça qui est la question non réglée : j'aimerais (avec
Eric) supprimer extensions/ afin de ne plus avoir de confusion entre
plugins/ et extensions/

-- Fil

6

* Fil tapuscrivait, le 20/04/2011 11:33:

-- ça ne règle pas la question des plugins "activés de force",

Ben si, un plugin placé dans extensions/ est activé d'office.

oui c'est bien ça qui est la question non réglée : j'aimerais (avec
Eric) supprimer extensions/ afin de ne plus avoir de confusion entre
plugins/ et extensions/

Un fichier activation.xml qui permettrait d'indiquer :
- activé par défaut oui/non
- désactivable via l'admin oui/non

?

--RealET

7

Je note que ça ne gère *que* la méthode SVN (pour l'instant)
Du coup, quid des .zip ?

ben il faut les coder (doigts, tout ça…)

Un fichier activation.xml qui permettrait d'indiquer :

dès lors qu'on a distribution.xml, c'est dommage de ne pas l'utiliser
pour y ajouter cette donner

-- Fil

8

pour y ajouter cette donner

oui je devrer me relier avent d'anvoiller

9

Coucou,

Bon je réponds ici car c’est le premier fil lancé sur les distributions mais je réponds aussi à des remarques sur celui du commit distribution.

dès lors qu’on a distribution.xml, c’est dommage de ne pas l’utiliser
pour y ajouter cette donner

En fait je suis un peu perplexe sur cette proposition de distribution car elle omet le point initial qui a fait naitre cette discussion, à savoir, le remplacement du répertoire extensions/.

La fonctionnalité de chargement (zip, svn) est prévue aujourd’hui dans SVP/STEP et j’ai l’impression qu’en orientant la distribution ainsi que tu le proposes on se marche sur les pieds (à moins que ce code commun finisse dans le core ?).
SVP/STEP manipulent déjà des paquets et sont aussi destinés à manipuler des collections (un peu comme ffx) c’est à dire des ensembles cohérents de plugins. J’ai du mal à voir si ta distribution correspond ou pas à une collection.

Ensuite, c’est déjà une remarque que j’avais faite à Rasta suite à son article sur la Taverne http://blog.smellup.net/spip.php?article33, je ne suis pas sur qu’il faille mélanger deux déclarations dans le même fichier de distribution, à savoir:

  • l’information qui donne la liste des plugins devant toujours etre actifs
  • l’information qui permet de construire le zip (ou le chargement svn). Par exemple, les zips sont aujourd’hui construits pas smart-paquets, il serait assez simple de construire des collections de plugins comme un zip unique qui serait alors distribué comme les autres zips par SVP/STEP (demande juste la création d’une table collections).

De ce fait, je vois plutôt le fichier de distribution comme un fichier déclaratif des plugins indispensables (toujours actifs) accompagné par une liste de collections.

xxxxxxx <necessite nom="compresseur"

Bon c’est surement largement perfectible mais c’est une autre piste à explorer.
Voilà voila.

Eric

10

Suite aux remarques d'Eric j'ai raccroché la syntaxe de
distribution.xml sur celle proposée par
http://blog.smellup.net/spip.php?article33

Details: http://zone.spip.org/trac/spip-zone/changeset/46912

j'ai dû toutefois ajouter des attributs, afin d'indiquer au script où
et comment aller chercher les éléments à installer.

-- Fil

11

Il faut lire aussi ce commentaire:
http://blog.smellup.net/spip.php?article33#forum96
qui mentionne des erreurs de conception à ne pas faire en XML.

Committo,Ergo:Sum

12

Il faut lire aussi ce commentaire:
Extensions et Distributions - La Taverne à Tonton
qui mentionne des erreurs de conception à ne pas faire en XML.

certes, mais ça ne concerne pas la partie sur laquelle j'ai travaillé :wink:

-- Fil

13

Ben si: dans
http://zone.spip.org/trac/spip-zone/changeset/46912

tu utilises une balise "version" alors que le commentaire dit qu'il vaut mieux utiliser un attribut dans ce cas, et tu utilises l'atttibut "id" qui doit être réservé à des situations d'unicité qui ne sont pas garanties ici. Il est aussi incohérent d'avoir une balise et un attribut qui portent même nom ("url"), le fait d'utiliser un attribut permettant un contrôle de valeur et une moindre verbosité.

Committo,Ergo:Sum

14

certes, mais ça ne concerne pas la partie sur laquelle j'ai travaillé :wink:

Ben si: dans
Connexion · GitLab
tu utilises une balise "version" alors que le commentaire dit qu'il vaut mieux utiliser un attribut dans ce cas, et tu utilises l'atttibut "id" qui doit être réservé à des situations d'unicité qui ne sont pas garanties ici. Il est aussi incohérent d'avoir une balise et un attribut qui portent même nom ("url"), le fait d'utiliser un attribut permettant un contrôle de valeur et une moindre verbosité.

Oui mais ce n'est pas la partie sur laquelle j'ai travaillé ! Ce que
tu pointes est un bête copier/coller de la proposition de l'article33,
mes modifications (ajout d'attributs) ne visant qu'à résoudre le
problème de savoir où télécharger les éléments. Quand la proposition
aura évolué je reporterai les modifs dans mon fichier.

-- Fil

15

Ah ok. En tout cas le modèle à suivre maintenant c'est la DTD de Plugonet:
http://zone.spip.org/trac/spip-zone/browser/plugins/plugonet/paquet.dtd

Je signale que ce plugin est maintenant bien opérationnel,
traduisant les 921 plugin.xml de la zone en un paquet.xml valide,
les 19 cas où ça ne passe pas révélant de vraies erreurs dans le plugin.xml
d'origine non dénoncées par la code analysant ce fichier.
Eric devrait présenter tout ça à la Party du 30 avril.

Committo,Ergo:Sum

16

Je ne comprends pas l’argument disant de mettre en attributs les valeurs devant être restreintes. Les patterns sont supportés dans XML Schema aussi pour les valeurs, depuis longtemps.

Je ne me souviens pas non plus avoir vu dans XML de restriction particulière sur un attribut qui se nommerait “id”. Une bonne pratique, peut-être.

-Nicolas

17

Il faut lire aussi ce commentaire:
Extensions et Distributions - La Taverne à Tonton
qui mentionne des erreurs de conception à ne pas faire en XML.

Je ne comprends pas l'argument disant de mettre en attributs les valeurs devant être restreintes. Les patterns sont supportés dans XML Schema aussi pour les valeurs, depuis longtemps.

Quand tu définis un attribut, tu as la possibilité d'énumérer les valeurs possibles quand elles sont en nombre fini, par un formalisme de mini-Regexp propre au DTD, possibilité inexistante pour un texte balisé dans une DTD. De surcroit dans le validateur intégré à SPIP, j'ai étendu ces mini-RegExpà toute RegExp. Il est vrai que les XML-Schema ont introduit une notion de type pour les textes balisés, mais c'est un formalisme plus difficile à lire, et l'ensemble des types est fini ce qui me paraît insatisfaisant.

Je ne me souviens pas non plus avoir vu dans XML de restriction particulière sur un attribut qui se nommerait "id".

Tu es sûr que tu l'as lu ? Il y a des tartines sur les notions de ID, de IDREF et de IDREFS stipulant que tout attribut nommé ID doit avoir une valeur utilisée par aucun autre attribut ID dans le document, et si tu ne respectes pas ça, tous les validateurs jetteront ton document.

Committo,Ergo:Sum

18

2011/4/21 Committo,Ergo:sum <esj@rezo.net>

Il faut lire aussi ce commentaire:
http://blog.smellup.net/spip.php?article33#forum96
qui mentionne des erreurs de conception à ne pas faire en XML.

Je ne comprends pas l’argument disant de mettre en attributs les valeurs devant être restreintes. Les patterns sont supportés dans XML Schema aussi pour les valeurs, depuis longtemps.

Quand tu définis un attribut, tu as la possibilité d’énumérer les valeurs possibles quand elles sont en nombre fini, par un formalisme de mini-Regexp propre au DTD, possibilité inexistante pour un texte balisé dans une DTD. De surcroit dans le validateur intégré à SPIP, j’ai étendu ces mini-RegExpà toute RegExp. Il est vrai que les XML-Schema ont introduit une notion de type pour les textes balisés,

Ah oui, OK, ce sont des DTD qui sont utilisées, par des XSD, j’avais oublié…

mais c’est un formalisme plus difficile à lire

???

C’est du XML, donc même formalisme que le doc qu’on essaie d’y décrire, c’est un sérieux avantage sur les DTD qui ont un autre formalisme à mon avis. L’avantage des DTD est plutôt dans leur antériorité, donc les connaissances déjà existantes.

, et l’ensemble des types est fini ce qui me paraît insatisfaisant.

L’ensemble de base est fini, certes, mais il est extrêmement simple de rajouter des types supplémentaires, simples ou complexes.

Je ne me souviens pas non plus avoir vu dans XML de restriction particulière sur un attribut qui se nommerait « id ».

Tu es sûr que tu l’as lu ? Il y a des tartines sur les notions de ID, de IDREF et de IDREFS stipulant que tout attribut nommé ID doit avoir une valeur utilisée par aucun autre attribut ID dans le document, et si tu ne respectes pas ça, tous les validateurs jetteront ton document.

Je ne parlais pas de l’unicité, mais de sa valeur, désolé pour l’imprécision.

19

mais c'est un formalisme plus difficile à lire

???

C'est du XML, donc même formalisme que le doc qu'on essaie d'y décrire, c'est un sérieux avantage sur les DTD qui ont un autre formalisme à mon avis. L'avantage des DTD est plutôt dans leur antériorité, donc les connaissances déjà existantes.

Un document XML est difficile à lire quand l'auteur de sa DTD ou XMLSchema n'a pas veillé à contenir le piège de la verbosité inhérente au formalisme. C'est aussi pour cela que je crois indispensable d'utiliser systématiquement un attribut quand c'est possible, car c'est moins verbeux qu'un balisage. Compare la lisibilité d'un plugin.xml et d'un paquet.xml, pour qqch d'aussi petit c'est déjà perceptible. A l'inverse, les XMLSchema sont excessivement verbeux, ce qui ravale l'argument que c'est du XML à une séduction théorique qui ne se vérifie pas en pratique. RelaxNG est plus crédible à mon avis. Mais comme tu dis, les DTD sont connues de longue date et très intuitives, ça suffit bien.

Il y a des tartines sur les notions de ID, de IDREF et de IDREFS stipulant que tout attribut nommé ID doit avoir une valeur utilisée par aucun autre attribut ID dans le document, et si tu ne respectes pas ça, tous les validateurs jetteront ton document.

Je ne parlais pas de l'unicité, mais de sa valeur, désolé pour l’imprécision.

Meme pour la valeur c'est contraint.
http://www.w3.org/TR/REC-xml/#attdecls
dit:
Values of type ID must match the Name production. A name must not appear more than once in an XML document as a value of this type; i.e., ID values must uniquely identify the elements which bear them.

et le "Name Production" est défini ici:

http://www.w3.org/TR/REC-xml/#NT-Name

qui exige, en gros, une lettre initiale suivie de lettres, chiffres ou soulignés.

Committo,Ergo:Sum

20

2011/4/21 Committo,Ergo:sum <esj@rezo.net>

2011/4/21 Committo,Ergo:sum <esj@rezo.net>

mais c’est un formalisme plus difficile à lire

???

C’est du XML, donc même formalisme que le doc qu’on essaie d’y décrire, c’est un sérieux avantage sur les DTD qui ont un autre formalisme à mon avis. L’avantage des DTD est plutôt dans leur antériorité, donc les connaissances déjà existantes.

Un document XML est difficile à lire quand l’auteur de sa DTD ou XMLSchema n’a pas veillé à contenir le piège de la verbosité inhérente au formalisme.

Certes.

C’est aussi pour cela que je crois indispensable d’utiliser systématiquement un attribut quand c’est possible, car c’est moins verbeux qu’un balisage.

Néanmoins, la verbosité n’est pas toujours un mal, si elle ajoute de la lisibilité.

Compare la lisibilité d’un plugin.xml et d’un paquet.xml

Où trouve-t-on des « paquet.xml » ?

A l’inverse, les XMLSchema sont excessivement verbeux, ce qui ravale l’argument que c’est du XML à une séduction théorique qui ne se vérifie pas en pratique. RelaxNG est plus crédible à mon avis.

Attention, on oublie trop ici à mon avis que des outils existent pour faire des XSD sans écrire soi-même toutes les balises. J’en ai fait pas mal, la plupart du temps avec un outil plus ou moins graphique.

Mais comme tu dis, les DTD sont connues de longue date et très intuitives, ça suffit bien.

Dans mon cas perso, ça ne s’applique pas, je n’ai jamais fait de SGML, donc j’ai directement commencé avec XML et XSD. Du coup je suis un peu paumé quand j’ouvre une DTD… :wink:

Il y a des tartines sur les notions de ID, de IDREF et de IDREFS stipulant que tout attribut nommé ID doit avoir une valeur utilisée par aucun autre attribut ID dans le document, et si tu ne respectes pas ça, tous les validateurs jetteront ton document.

Je ne parlais pas de l’unicité, mais de sa valeur, désolé pour l’imprécision.

Meme pour la valeur c’est contraint.
http://www.w3.org/TR/REC-xml/#attdecls
dit:
Values of type ID must match the Name production. A name must not appear more than once in an XML document as a value of this type; i.e., ID values must uniquely identify the elements which bear them.
et le « Name Production » est défini ici:
http://www.w3.org/TR/REC-xml/#NT-Name
qui exige, en gros, une lettre initiale suivie de lettres, chiffres ou soulignés.

Ah bin oui, tiens, j’avais complètement oublié. Ce qui tombe bien, c’est que j’applique ça systématiquement.

-Nicolas