OK
AJAX error!

Les forumsGrammalecteProcessus de build et de tests à partir des sources

Processus de build et de tests à partir des sources

Bonjour,

Je suis développeur Debian et je découvre Dicollecte/Grammalecte. J'aimerais bien voir ce programme dans Debian directement disponible pour une installation facile... J'ai ouvert un "ITP" (Intent To Package) dans les trackers de Debian ici: bugs.debian.org…

Je me demande la bonne façon de construire un paquet pour tout ceci. J'ai trouvé le code source sur la page d'accueil et tout, mais je ne suis pas certain de comment construire les extensions Firefox et LibreOffice à partir du .7z et je n'ai pas trouvé d'instructions à cet égard dans le paquet... Des idées?

Merci!

A.
le 18 avril 2017 à 23:34
Bonjour,

Pour une mini-aide:

make.py fr -h



Pour tout ce qui est en Python (extension pour LO et serveur), c’est simple. Installez Python 3.5, puis tapez:

make.py fr



Si vous voulez en plus reconstruire les structures de données:

make.py fr -b -d



Pour construire les éléments en JavaScript, c’est plus complexe:
— installez Node.js
— installez le module `npm` de Node.js
— installez le module `jpm` de `npm`
— installez Firefox Nightly (optionnel, pour les tests et le débogage)
— installez Thunderbird (optionnel, pour les tests et le débogage)

Ensuite, tapez:

make.py fr -b -d -js


Les options -b -d ne sont utiles que la première fois et à chaque fois que vous modifiez les sources pour les structures de données.
Vous pouvez ajouter les options -fx et/ou -tb pour lancer Firefox et Thunderbird à la suite de la compilation.

Pour Thunderbird, il faut auparavant lancer le logiciel avec l’option -P et créer un profil nommé `debug` que vous créerez dans le répertoire `_build/tb-debug.profile`. Et il faut installer l’extension la première fois. Ensuite, vous pouvez utiliser l’option -tb.

Si vous modifiez le code source en Python ou les règles grammaticales, pour les tests, lancez :

make.py fr -t


En revanche, il n’y a pas de tests pour JavaScript hors de Firefox.

make.py fr -js -fx


Puis tapez: CTRL+MAJ+F12 pour arriver dans le panneau de test.
le 19 avril 2017 à 00:05
Hmm... d'accord. Ensuite, j'installe quoi? Il y a un target "install" ou un truc du genre? Où se trouve l'extension libreoffice? Le machin dans _build?

Je vois qu'il y a les options "-b -d" pour le js, c'est obligatoire de reconstruire les structures de données pour construire les plugins Javascript?

À noter que nodejs et npm sont bien dans Debian, mais pas "jpm". Je doute aussi que jpm fasse son entrée dans Debian, vu que, pour citer la page d'accueil du projet, "Firefox is planning to deprecate the type of add-ons that are built by jpm. If you're building a new add-on, consider a WebExtension instead and check out the web-ext tool which has all the same features as jpm." (web-ext n'est pas non plus dans Debian, remarquez bien, mais ça serait probablement mieux de packager ça au lieu de jpm.)

Est-ce qu'il y a des plans de basculer à web-ext?

Je cherche aussi à packager le machin flycheck, et je me demande comment l'installer en mode "partagé", pour que le package puisse fonctionner pour libreoffice, firefox et emacs en même temps... Voir aussi gitlab.com…

Finalement, si je peux me permettre - tout ceci ne me semble pas très standard. :) J'ai une vaste expérience de packaging de différents logiciels et en particulier en Python. Celui-ci me semble assez ... particulier... Il serait peut-être mieux de considérer une approche standard avec setup.py au lieu d'un make.py custom. Il serait alors beaucoup plus facile pour les distributeurs de *toutes* les distributions de packager grammalecte sans avoir à vous demander conseil. :) J'ai trouvé que packaging.python.org… était une excellent référence sur les bonnes pratiques dans Debian. Sinon un bon vieux "Makefile" pour emballer tout ça et/ou au moins un fichier INSTALL qui résume ce thread serait bien apprécié. :)

Merci de la réponse!
le 19 avril 2017 à 02:42
Oui, les extensions construites arrivent dans _build.

Je vois qu'il y a les options "-b -d" pour le js, c'est obligatoire de reconstruire les structures de données pour construire les plugins Javascript?


Oui.

Est-ce qu'il y a des plans de basculer à web-ext?


Il faut passer à WebExtension avant fin novembre. Quand j’ai commencé, WebExtension était en version alpha. Mozilla disait: Ne vous inquiétez pas, utilisez le SDK, il n’y aura pas de problème. J’ai donc utilisé le SDK. WebExtension est sorti en version finale peu de temps après Grammalecte pour Firefox. Enfin, “finale”, c’est vite dit. Beaucoup d’auteurs d’addons se plaignent que c’est loin d’être complet. Mozilla disait que les anciennes API d’extensions pour Firefox seraient rendues obsolètes, sauf le SDK de haut niveau (ce que j’ai utilisé)… Mais finalement, patatras, Mozilla a décidé il y a quelques mois de tout rendre obsolète fin novembre, sauf WebExtension. C’est extrêmement frustrant de mon point de vue, mais je ne vois pas comment j’aurais pu faire autrement.

tout ceci ne me semble pas très standard.


Oui, ce n’est pas standard, mais faire un setup.py n’est pas le fond du problème. LibreOffice, Firefox et Thunderbird se foutent complètement d’avoir un setup.py. Ça ne peut être utile que pour un paquet Python standalone. Sur ce point, je n’ai pas fait de setup, parce que l’API ne me satisfait pas, et qu’il faut que j’en fasse une de moins bas niveau, plus intuitive. Et comme il n’y a aucune urgence pour ça…

Par ailleurs, setup.py ne pourra en aucun cas remplacer make.py.
Parce que Grammalecte, c’est du code généré pour une grande partie.

Bref, je vais essayer de faire une doc plus complète. :)

Petite note en passant sur les standards… :) Ça fait des années que je peste contre les distributions qui se foutent complètement du “standard” pour LibreOffice. LO a pour dépendance Python 3.3… Je ne compte plus le nombre de Linuxiens qui se sont plaints que ça ne fonctionnait pas parce que LO était lié à Python 2.6, 2.7, 3.2, voire 2.4… ou parce que le passerelle Python-UNO de LO n’était pas la bonne. Bref…
le 19 avril 2017 à 09:14

Je cherche aussi à packager le machin flycheck, et je me demande comment l'installer en mode "partagé", pour que le package puisse fonctionner pour libreoffice, firefox et emacs en même temps... Voir aussi gitlab.com…


Je ne sais pas. Je ne suis pas l’auteur des plugins pour Vim et Emacs.
le 19 avril 2017 à 11:39

Par ailleurs, setup.py ne pourra en aucun cas remplacer make.py.
Parce que Grammalecte, c’est du code généré pour une grande partie.



Je ne vois pas pourquoi setup.py ne pourrait pas remplacer make.py. C'est un script python comme les autres, et il est possible d'y ajouter les commands de son choix, sans problème. J'ai construit des manpages, packagé des icônes, des scripts et d'autres fichiers arbitraires avec setup.py.

Après, que d'autres ne respectent pas les standards n'est guère une excuse pour ne pas les respecter soi-même. :)

Un autre question: dans le thread précédent sur Debian, le packager indiquait qu'il manquait des fichiers sources. Est-ce toujours le cas? Le .7z est complet?

Je cherche aussi à packager le machin flycheck, et je me demande comment l'installer en mode "partagé", pour que le package puisse fonctionner pour libreoffice, firefox et emacs en même temps... Voir aussi gitlab.com…



Je ne sais pas. Je ne suis pas l’auteur des plugins pour Vim et Emacs.



Je sais. Ce que je demandais, c'est plutôt comment installer grammalecte de façon plus globale:

Hmm... d'accord. Ensuite, j'installe quoi? Il y a un target "install" ou un truc du genre? Où se trouve l'extension libreoffice? Le machin dans _build?



J'imagine que les plugins vim et emacs n'installent pas leur propre copie de grammalecte et s'attendent à trouver grammalecte quelquepart. Où est le point d'entrée? Quels fichiers je dois installer?

J'ai aussi posé la question du côté Emacs, en passant - j'attends la réponse à ce sujet: gitlab.com…

Merci.
le 19 avril 2017 à 14:10

Je ne vois pas pourquoi setup.py ne pourrait pas remplacer make.py. C'est un script python comme les autres, et il est possible d'y ajouter les commands de son choix, sans problème. J'ai construit des manpages, packagé des icônes, des scripts et d'autres fichiers arbitraires avec setup.py.


Ah oui, bien sûr, je m’aperçois que j’ai mal compris la remarque. Je pensais que c’était une critique de la complexité de mon make à remplacer au profit d’un simple setup déclaratif.

Je viens de comprendre (désolé, j’ai passé une mauvaise nuit). Ce qu’il te faut, c’est un setup qui déclare le paquet Python (répertoire /grammalecte), afin d’être installé dans les librairies Python. Oui, pourquoi pas…

Pour l’instant, le paquet Python se trouve utilisable tel quel dans l’extension pour LO ainsi que dans les sources. Je crois que le plugin de Vim dézippe l’extension de LO. Je ne sais pas ce que fait celui de Flycheck.

OK, on va essayer de clarifier tout ça.

Un autre question: dans le thread précédent sur Debian, le packager indiquait qu'il manquait des fichiers sources. Est-ce toujours le cas? Le .7z est complet?


À l’époque, je ne fournissais pas le processus de build. Ça ne me plaisait pas de devenir un fork officiel de Lightproof. Je savais qu’on allait me bassiner avec le dépôt. Le côté “officiel”, ça me saoule. Être un tout petit projet, c’était bien…

Donc, oui, c’est complet pour faire le build. Ce qu’il n’y a pas, ce sont des gigaoctets de PDF, de lexiques, d’archives, de bouts de code annexes, qui ne sont pas utiles pour le build, et pas vraiment utiles tout court, en fait. Je pourrais aussi bien tout effacer.
Il y a aussi le code de ce site, qui ne sera pas fourni, parce que je n’ai aucune envie d’avoir à gérer autre chose que cette installation présente.

Il y a quand même un truc qui manque sans être indispensable : le script qui transforme le dictionnaire pour Hunspell en lexique (ce qu’on compile avec l’option -d), mais je vais l’ajouter prochainement pour que ce soit vraiment complet.
le 19 avril 2017 à 15:28

Admin :

Je ne vois pas pourquoi setup.py ne pourrait pas remplacer make.py. C'est un script python comme les autres, et il est possible d'y ajouter les commands de son choix, sans problème. J'ai construit des manpages, packagé des icônes, des scripts et d'autres fichiers arbitraires avec setup.py.



Ah oui, bien sûr, je m’aperçois que j’ai mal compris la remarque. Je pensais que c’était une critique de la complexité de mon make à remplacer au profit d’un simple setup déclaratif.

Je viens de comprendre (désolé, j’ai passé une mauvaise nuit). Ce qu’il te faut, c’est un setup qui déclare le paquet Python (répertoire /grammalecte), afin d’être installé dans les librairies Python. Oui, pourquoi pas…

Pour l’instant, le paquet Python se trouve utilisable tel quel dans l’extension pour LO ainsi que dans les sources. Je crois que le plugin de Vim dézippe l’extension de LO. Je ne sais pas ce que fait celui de Flycheck.

OK, on va essayer de clarifier tout ça.



Le mieux serait d'avoir un machin dans PIP qui contient un package Python avec un exécutable (ou peu importe ce que les extensions ont besoin) et qu'on peut maintenir de façon fiable. Dans Debian, on essaie d'éviter la duplication de code, pour faciliter la maintenance de sécurité à long terme (3-5 ans pour des vieux codebase!). Donc, dans le cas-type, l'extension Vim, Emacs et Libreoffice reprendraient toutes la même dépendance sur le paquet Python et seraient, en quelquesorte, simplement de coquilles vides... :) Ça ne veut pas dire que ça doit être la façon dont le code est distribué sur dicollecte.org, remarque bien, mais ça serait plus simple à packager si cela serait simplement *possible*.

De plus, ce que je suggérais était de *convertir* le make.py en setup.py. Je sais qu'il fait beaucoup plus qu'un "simple" paquet Python, mais mon argument est que, justement, setup.py est conçu pour remplacer des outils de constructions tels que les makefiles et les trucs custom comme make.py. Il n'y a pas de raison, a priori, pourquoi setup.py ne pourrait pas faire tout ce que make.py fait. setup.py n'est pas seulment déclaratif - c'est un programme Python complet qui peut exécuter du code arbitraire.

Quelques exemples... Borg backup construit des libraires en C et leur binding Python dans son setup.py. Il construit aussi de la docu en .rst à partir du output de "--help" du programme pour donner une aide en ligne dans la documentation. Il créé aussi des manpages, tant qu'à être parti. ;) github.com…

La magie se trouve dans l'argument cmdclass qui détermine quelles "commandes" (des fonctions python, vraiment) appeler pour construire toutes les parties du truc. Tu pourrais, de cette façon, avoir une commande "build_webext" (au lieu de "-js"), "build_writer" (au lieu de l'ambigu "fr"), "build_dicts" (au lieu de "-b -d"), etc...

Admin :

Un autre question: dans le thread précédent sur Debian, le packager indiquait qu'il manquait des fichiers sources. Est-ce toujours le cas? Le .7z est complet?


À l’époque, je ne fournissais pas le processus de build. Ça ne me plaisait pas de devenir un fork officiel de Lightproof. Je savais qu’on allait me bassiner avec le dépôt. Le côté “officiel”, ça me saoule. Être un tout petit projet, c’était bien…

Donc, oui, c’est complet pour faire le build. Ce qu’il n’y a pas, ce sont des gigaoctets de PDF, de lexiques, d’archives, de bouts de code annexes, qui ne sont pas utiles pour le build, et pas vraiment utiles tout court, en fait. Je pourrais aussi bien tout effacer.



Ça serait effectivement mieux d'effacer tout ça si ce n'est pas inclus dans le build. Dans Debian, on a tendance à retirer les documents sans la source originale, et ça pourrait compliquer la maintenance si de tels documents sont inclus dans la source...

Admin :
Il y a aussi le code de ce site, qui ne sera pas fourni, parce que je n’ai aucune envie d’avoir à gérer autre chose que cette installation présente.



Pas de problème - le code du site n'entre pas dans la construction du programme, à ce que je sache, donc on peut reconstruire le programme sans le site...

Admin :
Il y a quand même un truc qui manque sans être indispensable : le script qui transforme le dictionnaire pour Hunspell en lexique (ce qu’on compile avec l’option -d), mais je vais l’ajouter prochainement pour que ce soit vraiment complet.



Super, merci de faire le bon choix. ;)
le 19 avril 2017 à 15:59
Bon, ça mérite réflexion.

A priori, je ne suis pas trop partant pour mettre tout le make dans le setup. L’exemple de Borg, c’est de la belle bureaucratie, c’est joli, faut admettre, mais c’est de la bureaucratie. Un setup pour le paquet Python, c’est utile. Mais pourquoi vouloir y intégrer tout le processus de build? Je ne vois pas trop ce que ça apporte, à part se compliquer la vie. Intégrer tout le build pour JavaScript avec des procédures pour installer npm, jpm, Firefox Nightly, Thunderbird et que sais-je encore? Qui va s’en soucier? Pas grand-monde, et ceux-là peuvent télécharger les sources… Bref, c’est overkill, de mon point de vue.

Quant aux options de build, elles ne vous conviennent pas forcément comme elles sont, mais elles me sont utiles. Il faudra donc ajouter des options “englobantes” éventuellement.

Je ne suis pas fermement opposé à tout ça, notez bien… mais bon, pas urgent et utilité discutable (sauf pour le paquet Python)…

Notez bien que j’ai toujours plus eu le souci des utilisateurs finaux que du ronronnement des scripts d’arrière-cour qui plaisent aux informaticiens. Les faux positifs, ça m’embête beaucoup plus que les processus de build un peu crades. :)

Ça serait effectivement mieux d'effacer tout ça si ce n'est pas inclus dans le build.


Ce que vous téléchargez, c’est déjà le strict nécessaire. Il n’y a pas de superflu. Ça pèse déjà 63 Mo, au lieu des 4 Mo nécessaire pour le seul paquet Python.

Pas de problème - le code du site n'entre pas dans la construction du programme, à ce que je sache, donc on peut reconstruire le programme sans le site...


Ça n’y entre pas vraiment. Mais le site, c’est ce qui exporte les données nécessaires pour la construction du lexique…
Tout dépend jusqu’où vous avez besoin de remonter. Hunspell et le lexique sont fournis sur le site, mais vous pourriez penser que le lexique fourni dans les sources ne suffit pas et qu’il faut pouvoir le générer à partir de la base de données…
le 19 avril 2017 à 17:15

Admin :
Je ne vois pas trop ce que ça apporte, à part se compliquer la vie.



Ça évite les threads du genre. S'il y avait un setup.py, j'aurais juste fait "setup.py build install" et basta, j'aurais déjà fini de packager grammalecte. Pour l'instant je sais toujours pas comment installer le truc, pcq non-standard...

Admin :
Notez bien que j’ai toujours plus eu le souci des utilisateurs finaux que du ronronnement des scripts d’arrière-cour qui plaisent aux informaticiens. Les faux positifs, ça m’embête beaucoup plus que les processus de build un peu crades. :)



Je veux bien, mais à priori, je bosse aussi pour les utilisateurs finaux. Je veux m'assurer que c'est possible pour eux d'installer grammalecte en tapant dans leur outil de gestion des paquets. Présentement, c'est pas possible pour vim et emacs.

Admin :
Tout dépend jusqu’où vous avez besoin de remonter. Hunspell et le lexique sont fournis sur le site, mais vous pourriez penser que le lexique fourni dans les sources ne suffit pas et qu’il faut pouvoir le générer à partir de la base de données…



Hmm... si le lexique peut être construit à partir de hunspell, ça devrait pas trop poser problème...
le 19 avril 2017 à 18:20
OK. Noté.
le 19 avril 2017 à 19:05
Ah oui, voilà… J’avais oublié pourquoi j’avais finalement à chaque fois refusé de publier le script qui convertit le dico en lexique. Ce n’est pas pour faire chier tout le monde.
Mais ça pèse 260 Mo… Ce n’est pas le script évidemment qui est aussi lourd, ce sont les fichiers de données statistiques de Wikipédia, de Wikisource et de Google Ngrams, qui pèsent 251 Mo à eux seuls.
Et encore, ces fichiers sont purgés, et le fichier de Google Ngrams est même tronqué… sinon il pèserait encore bien plus lourd, plus d’un gigaoctet peut-être, je ne suis plus très sûr.

Bon, mais cette fois, je vais m’y résoudre. On verra.
le 20 avril 2017 à 11:18

Notification par e-mail    2