Sur les configurations requises

Dev
1

https://www.spip.net/fr_article4351.html

Je pense ne présenter (de manière automatique) que les branches « stable », actuellement la 3.2, en « security-fix », la 3.1. Et pourquoi pas, la version « future » (vu qu’il y a une alpha pour celleux qui voudraient tester, autant présenter les infos pour installer)

On pourrait toujours trouver les pré-requis des versions non-maintenues ailleurs …

Pour JQuery, ce n’est pas « requis », c’est « fourni ». Je pense que la nuance compte, même si ça peut être présenté au même endroit.

Pour PHP, l’info est déjà disponible, pas de problème.

Pour les bases SQL, c’est plus épineux : aucune n’est requise vraiment, du moment qu’il y en a au moins un serveur, ne fusse que SQLite … du coup, je pensais à « suggérer » les types de serveurs SQL (et leur inerrvalle de versions). Faudrait-il d’ailleurs faire un distinguo entre mysql et mariadb ?

De même pour les outils système et/ou les extensions PHP (certaines sont requises, d’autres sont suggérées)

Pour apache, je ne sais pas. :slight_smile: est-ce vraiment nécessaire de présenter Serveur Apache ou compatible (versions supérieures à la 1.2x) ?

du coup, ça fait 3 façons d’associer des informations technologiques : requiert, fourrnit et suggère

Y a-t-il autre chose, qui ne serait pas affiché actuellement, qui serait intérressant de présenter dans une telle page ?

2

Oui cette distinction serait bienvenue, le mélange actuel me semble un peu chiffonant :slight_smile:

Je ne vois pas d’objection à séparer en 2 sections pour les branches stables et les autres. Sur une autre page, ou sur la même mais séparé ? À voir.

En tout cas l’automatisation est bienvenue.

3

Top !

Normalement non, même si les deux semble diverger avec le temps je n’ai aucun problème en utilisant mariadb partout depuis perpète, par contre c’est peut-être mysql qui pourrait poser problème si beaucoup des devs n’utilisent que mariadb.

Amha non, d’autant plus que ça fonctionne aussi avec nginx, mais il faut bien l’indique manuellement quelque part.

1 « J'aime »
4

ah, mais oui, bien vu !

Un serveur http configuré pour fonctionner avec PHP ça irait ?

genre apache+mod_php, apache+fcgi+php-fpm, nginx+php-fpm, caddy+php-fpm, …

5

En précisant que seul le .htaccess pour apache est fourni par SPIP (parce qu’il y a des modes d’urls et des plugins qui ne fonctionnent pas sans, en particulier Bank)

7

yep

9

vous pouvez créer un thread à part pour vos histoires de nginx svp ? merci :slight_smile:

1 « J'aime »
10

wala, j’ai supprimé mon message.

11

Pour en revenir à la question initiale, et même si c’est pas gros du tout et très stable - ou justement parce que c’est pas gros et très maîtrisé jusqu’à présent - je trouverais intéressant de présenter l’encombrement sur le disque et la mémoire requise a minima, pour l’installation et pour un fonctionnement correct.
Ce sont des informations qui figurent habituellement pour la configuration requise des jeux et logiciels à installer sur un ordi perso, et donc bien connus, et des indicateurs de sobriété intéressants à mettre en avant.

12

Est-ce que tu parles exclusivement de l’encombrement du code (on connait la taille de l’archive mais effectivement, c’est une autre dimension une fois décompressé) ? ou bien l’idée serait aussi de fournir une estimation de l’encombrement maximal avec les caches ?

Faudrait-il mentionner les plugins supplémentaires et les documents (IMG/) d’une manière ou d’une autre ?

Je note pour la RAM. :+1:

pour l’installation et pour un fonctionnement correct

est-ce que c’est une notion « textuelle » ou est-ce que tu vois ça comme un distinguo « minimum/recommandé » ?

13

Que veux tu dire par « notion textuelle » ? Je pige pas.
En tout cas ce n’est pas la config « recommandée » car les besoins varient trop en fonction du site, de son squelette et de sa fréquentation pour faire une recommandation générique.

Donc c’est les ressources d’un site minimal pour un fonctionnement correct : l’estimation de l’espace disque requis pour le fonctionnement correct d’un petit site opérationnel à faible trafic.
Donc avec : dist dézippé installé + 2 ou 3 plugins économes en cache + rédactionnel de 3 rubriques et 6 articles + 20 Mo de cache…

Pour me rendre compte, j’ai regardé un mini site spip fait avec mon fils https://pyromania.alwaysdata.net. Il y a 5 mini-articles, 4 rubriques, et 4 plugins : zcore, html5upforty, adaptive images et saisies. Les volumes sont :

  • 145,2 Mo au total (d’après la console de l’hébergeur)
  • 3,9 Mio pour MYSQL
  • 131 Mo au total pour les fichiers (141Mo d’après l’hébergeur)
  • dont 31,6 Mo incompressibles pour ecrire, plugins-dist, squelettes-dist, prive (SPIP 3.3-dev avant allégement de plugins-dist)
  • 16 Mo pour /IMG (dont 11Mo « distantes » [EDIT] et incompressibles pour les data récupérées par SVP)
  • 53 Mo pour /local (les caches images, dont 39Mo pour adapt-img, qui ne doit pas figurer dans le site modèle pour la configuration requise !),
  • 26Mo pour /tmp/cache

C’est des quantités « non contraintes ». Le site fonctionne encore avec le cache squelette vidé et désactivé. On peut vider le cache image, mais il n’y a pas d’UI prévue pour fonctionner sans cache image alors je ne sais pas ce que ça donne (#improveme ?). Au passage je vois que les fichiers caches de adapt-img restent même quand le cache image est vidé - #ticket.

14

Pour la définition du périmètre, j’ai évoqué « 2 ou 3 plugins économes en cache ». Ça peut sembler un peu flou sans préciser quels plugins, mais ça correspond à une réalité perçue. Inversement, définir un périmètre « spip dist » (0 plugin supplémentaire, 0 squelette perso) serait s’éloigner du concret et du « requis minimal » car les sites même minimaux mais opérationnels ont une couche de personnalisation.
Au passage on voit que quand spip 4.0.0 s’allège de quelques plugins-dist, le site minimal opérationnel n’est pas gêné : il n’a pas besoin de vertebres breves squelettes-par-rubriques et petition. Et donc dans ce cas le périmètre peut bien sans problème suivre l’évolution de plugin-dist et la page afficher une petite baisse de l’espace disque requis.

15

Beh je ne sais pas pourquoi j’ai écrit « textuelle » :slight_smile: j’ai sans doute voulu dire « éditoriale » ? un bout de texte dans un article en fait, comme pour le serveur http.

En tout cas, merci pour ces infos !

De mon coté, j’ai regardé si on utilisait memory_limit et le résultat n’a pas bougé depuis 2015 ! :slight_smile:

16

Le chantier reprend.

La première étape a consisté à transformer le format JSON du fichier des releases. En effet, chaque branche de SPIP était représentée par le format suivant :

{
    "branch": "X.Y",
    ...
    "php": [..., "5.6", ..., "7.1", ...],
    ...
}

Pour prendre en compte les propositions, je suis passé à ce format :

{
    "branch": "X.Y",
    ...
    "technologies": {
        "require": {
            "php": [..., "5.6", ..., "7.1", ...]
        }
    },
    ...
}

et j’ai donc refait les modèles et filtres pour sa prise en compte.

Je vais pouvoir insérer les suggest et les provide et produire le modèle de remplacement des articles « Configuration requise ».

Pourquoi je raconte ça alors que pour le moment, c’est juste un changement de format et qu’il n’y a pas de grosse avancée ? Parce que je suis assez content de la méthode que j’ai utilisée avec l’utilitaire jq, que je recommande à ceux qui aiment bien les outils en lignes de commande.

Pour les aspects RAM et espace disque, je pense créer un attribut system au même niveau que technologies. À ce propos:

Pour l’espace utilisé, je pense qu’il faudrait que le plugin debardeur ou un autre outil calcule ou estime la taille des paquets SPIP une fois décompressés. Taille à laquelle le modèle pourrait ajouter des valeurs similaires aux infos que @JLuc a fourni. Idéalement, il faudrait retrouver cette info dans les fichiers archives.xml des paquets SPIP.

Pour la RAM, j’aimerais avoir des retours sur les besoins que vous avez rencontrés, je doute que 16Mo suffisent aujourd’hui.

17

Je vois que sur un mutu OVH on a un memory_limit à 512M, « beaucoup » donc, mais tous mes sites en local tournent sans problème avec un memory_limit à 128M.

18

En démonstration Configuration requise - SPIPremix

Le modèle SPIP qui affiche le contenu est ici : Resolve "Assembler des informations techniques par branches" (!17) · Merge requests · James / supported-versions · GitLab

un texte d’article spip peut ressembler à ça du coup :

{{{Prochaine version}}}

<supportedversions|configuration|state=future>

{{{Versions maintenues}}}

<supportedversions|configuration|state=stable,security>

{{{Fin de vie}}}

<supportedversions|configuration|state=eol>

Ce qui permet d’ajouter des précisions avant, après, au milieu …

Enfin, les données poussées sur le rebooteux ne sont pas définitives

19

Super, deux remarques :

  • ajouter un espace avant les : (à moins qu’on puisse faire passer typo là dessus automatiquement)
  • dans les suggestions, remplacer le terme SQL par Base de données (?)
20

hop !

et c’est à jour sur le site de démo : Configuration requise - SPIPremix

21

Ah bah ça semble pas mal ça.

22

Et donc, Configuration requise - SPIP

et en preview en anglais https://www.spip.net/en_article6659.html?var_mode=preview

1 « J'aime »