Produits Entr'ouvert » w.c.s.

Manu était volontaire pour regarder à ça, je le laisse tester.

Bof.

============= 15 failed, 2172 passed, 49 skipped, 12 warnings, 36 error in 1174.91 seconds ==============
ERROR: InvocationError for command '/tmp/tox-cazino/wcs/coverage-django111-pylint-pg/bin/py.test --junit-xml=test_results.xml --cov=wcs --cov-report xml --cov-config .coveragerc tests' (exited with code 1)     
________________________________________________ summary ________________________________________________
ERROR:   coverage-django18-pylint-pg: commands failed
ERROR:   coverage-django111-pylint-pg: commands failed

coverage-django18-pylint-pg

Clairement à dégager.

Ensuite, peut-être que "ça marche" c'était "ça me permet de faire tourner un test ciblé", et peut-être que c'est déjà une étape utile en soit.

Frédéric Péters a écrit :

Ensuite, peut-être que "ça marche" c'était "ça me permet de faire tourner un test ciblé", et peut-être que c'est déjà une étape utile en soit.

Pour ma part je n'ai pas encore renoncé au plan ambitieux, un tox qui marche pour tout les tests et qui utilisé également par jenkins (parce que si jenkins ne s'en sert pas, ça pourra se casser allégrement sans que personne ne s'en rende compte etc).

Et donc si tu n'y vois pas d'inconvénients Benj je vais essayer de reprendre ça en faisant en sorte que ça utilise au maximum les paquets système (cf https://dev.entrouvert.org/projects/reunions-internes/wiki/Dev-2019-09-16).

Emmanuel Cazenave a écrit :

Et donc si tu n'y vois pas d'inconvénients Benj je vais essayer de reprendre ça en faisant en sorte que ça utilise au maximum les paquets système (cf https://dev.entrouvert.org/projects/reunions-internes/wiki/Dev-2019-09-16).

misère ...

Primo je ne comprends pas que w.c.s. reçoive un traitement particulier (surtout que le strawman utilisé pour le justifier c'est python-cryptography et ça concerne combo) par rapport aux autres briques,

Deuxio rien n'empêche d'utiliser l'option sitepackages=True/skipsdist=True sur Jenkins dans des debootstrap/cowbuilder des versions de debian où veut voir que ça marche (parce que tant qu'à dire qu'on veut voir que ça marche en vrai dans debian autant aller jusqu'au bout) mais ça m'irait de viser en premier que ça fonctionne avec sitepackages=False/skipsdist=False, le but premier c'est quand même de pouvoir développer avant même d'être sûr que ça va marcher une fois déployé, actuellement personne ne peut développer dans w.c.s. à part les petits malins chez EO ou à qui on donne la recette mais c'est peut-être l'objectif.

Déjà je ne sais plus pourquoi la moitié des dépendances ne sont pas déclarées dans setup.py (genre vobject) plutôt que dans tox.ini.

Primo je ne comprends pas que w.c.s. reçoive un traitement particulier (...)

Il ne doit pas y avoir de traitement particulier, il y a un historique particulier, comme par exemple l'existence d'un paquet authentic2-multitenant dans authentic.

Benjamin Dauvergne a écrit :

misère ...

En ce qui me concerne, pragmatisme avant tout, c'est le truc qui semble le plus rapidement atteignable. Ça ramènerais la procédure de tests en local à installer les paquets debian de debian/control une bonne fois pour toute, puis lancer tox. Ça me semblerait déjà beaucoup plus propre que ça ne l'est aujourd'hui, on verra pour la suite.

Emmanuel Cazenave a écrit :

Benjamin Dauvergne a écrit :

misère ...

En ce qui me concerne, pragmatisme avant tout, c'est le truc qui semble le plus rapidement atteignable. Ça ramènerais la procédure de tests en local à installer les paquets debian de debian/control une bonne fois pour toute, puis lancer tox. Ça me semblerait déjà beaucoup plus propre que ça ne l'est aujourd'hui, on verra pour la suite.

Si tox fait les apt-truc ou même de simples :

(dpkg-query -W -f='${Status}' truc | grep installed >/dev/null) || echo "missing truc, do: apt install truc"

ça irait.

Tout ce que je souhaite c'est que le réflexe reste "je tape tox", pas: je lis le README, je lis setup.py, je lis debian/control, je fais pleins de trucs, enfin je peux faire tox.