Project

General

Profile

Développement #81739

passer de tox à nox (?)

Added by Frédéric Péters over 1 year ago. Updated 6 months ago.

Status:
Solution validée
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
28 September 2023
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No
Club:
No

Description

Parce que #81735 a été posé, pour pouvoir discuter plus globalement :

On chercherait à améliorer quoi ?

Perso mon problème principal avec tox c'est dans les moments où il y a des instructions conflictuelles sur les versions, typiquement on met explicitement django>=4.2,<4.3 pour tester avec cette version de django mais parce que dans un setup.py du module ou d'une de ses dépendances il se trouve à finalement rester sur l'ancienne version et il faut penser à aller vérifier ce qu'il a installé comme versions pour se rendre compte du problème.


Related issues

Related to Lingo - Développement #81735: Tester noxFermé28 September 2023

Actions
Related to Combo - Développement #93872: nox, afficher les versions installées par pip sur la sortie jenkinsFermé05 August 2024

Actions
Related to BiJoe - Développement #95310: Utiliser noxFermé12 September 2024

Actions
Related to Fargo - Développement #93755: Utiliser noxFermé01 August 2024

Actions
Related to Hobo - Développement #95798: utiliser nox pour debian-django-tenant-schemasNouveau23 September 2024

Actions
Related to Zoo - Développement #95619: Passage à noxFermé19 September 2024

Actions
Related to EOPayment - Développement #95959: Passage à noxFermé26 September 2024

Actions
Related to Combo - Développement #95974: combo-plugin-gnm : passer à noxFermé26 September 2024

Actions
Related to Plugin Carte eID (fedict/bosa) - Développement #96156: Utiliser noxFermé01 October 2024

Actions
Related to Chrono - Développement #91376: Utiliser noxFermé03 June 2024

Actions
Related to Combo - Développement #97095: combo-plugin-imio-townstreet: passer à noxFermé17 October 2024

Actions
Related to Intégrations graphiques Publik - Développement #97115: Passer à noxFermé17 October 2024

Actions
Related to Godo - Développement #97535: utiliser noxRésolu (à déployer)24 October 2024

Actions
Related to Gadjo - Développement #97552: utiliser noxFermé24 October 2024

Actions
Related to Scrutiny - Développement #98853: Passer à noxSolution proposée21 November 2024

Actions

History

#1

Updated by Frédéric Péters over 1 year ago

#2

Updated by Corentin Séchet over 1 year ago

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

Perso mon problème principal avec tox c'est dans les moments où il y a des instructions conflictuelles sur les versions, typiquement on met explicitement django>=4.2,<4.3 pour tester avec cette version de django mais parce que dans un setup.py du module ou d'une de ses dépendances il se trouve à finalement rester sur l'ancienne version et il faut penser à aller vérifier ce qu'il a installé comme versions pour se rendre compte du problème.

Je sais pas si j'ai bien compris. J'ai testé en local, si on fait un session.install('-e', '.', 'django>3.4') par exemple, dans nox, ça prend en compte à la fois les contraintes de versions du setup.py et de celles qui sont passées à nox. Donc ça permet d'ajouter des contraintes de version dans noxfile.py par dessus celles du setup.py (et de lever une erreur s'il y aucune version ne satisfait les deux).

Mon problème avec tox, c'est qu'il est très rigide. Par exemple il s'attend à avoir une liste de dépendances qui sont des packages pythons, ce qui oblige à bricoler avec des scripts bash pour installer un environnement node pour les tests JS. Il installe aussi systématiquement le projet en cours dans l'environnement, alors que j'en ai pas besoin (et du coup ça prend beaucoup plus de temps que ça devrait). La config de nox se fait en python, c'est plus flexible et ça me permet d'installer un environnement avec juste node et ce qu'il faut pour les tests JS.

De manière plus générale, dès que j'ai eu à configurer un truc dans tox, je me suis noyé dans la doc. Je trouve celle de nox beaucoup plus concise. Et le DSL dans un .ini je trouve ça très dur à lire, tandis que le python, ça parle à tout le monde. Le python permet aussi de factoriser des choses simplement avec des méthodes, par ex. les mêmes dépendances déclarées à deux endroits différents pour pylint ou les tests unitaires dans tox, ça se factorise très simplement dans nox.

#3

Updated by Frédéric Péters over 1 year ago

Je sais pas si j'ai bien compris. J'ai testé en local, si on fait un session.install('-e', '.', 'django>3.4') par exemple, dans nox, ça prend en compte à la fois les contraintes de versions du setup.py et de celles qui sont passées à nox. Donc ça permet d'ajouter des contraintes de version dans noxfile.py par dessus celles du setup.py (et de lever une erreur s'il y aucune version ne satisfait les deux).

Le problème que j'ai avec tox est sur des instructions contradictoires, j'ai posé https://jenkins.entrouvert.org/job/gitea/job/welco/job/wip%252Ftox-version/1/console en exemple, il y a là un environnement qui demande explicitement django 2.2 mais quand on regarde ce que ça installe, surprise, on a 3.2 :

10:31:02  py3-django22-drf312 installed: ...,Django==3.2.21,...

Ensuite le build échoue pour d'autres raisons mais parfois le build fonctionne très bien avec la version qui a été tirée et on ne va pas se rendre compte que l'environnement mis en place pour valider que ça va être ok avec telle version n'utilise en fait pas la version demandée.

~~

ce qui oblige à bricoler avec des scripts bash

La démonstration de cet avantage pourrait passer par la suppression de session.run('bash', './getlasso3.sh', external=True) ?

~~

Je n'ai vraiment aucune objection à quitter tox, il y aurait par contre je trouve à tester nox sur une situation moins simple, typiquement la validation sur plusieurs versions de django, pour valider l'affaire mais aussi pour avoir un exemple de comment ça se ferait (parce qu'avec le temps je peux ajouter un environnement au tox.ini pour arriver à faire ça, mais sur le noxfile.py je ne saurais évidemment pas faire sans aller aujourd'hui lire la documentation).

Aussi la PR lingo conserve un bout avec tox, ce qui est moyen mais j'imagine c'est parce que la version packagée debian est jugée trop ancienne et qu'il faut d'une manière ou d'une autre bootstrapper ça ?

#4

Updated by Corentin Séchet over 1 year ago

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

Le problème que j'ai avec tox est sur des instructions contradictoires, j'ai posé https://jenkins.entrouvert.org/job/gitea/job/welco/job/wip%252Ftox-version/1/console en exemple, il y a là un environnement qui demande explicitement django 2.2 mais quand on regarde ce que ça installe, surprise, on a 3.2 :

Je vais regarder en détail et m'assurer que ça serait corrigé par Nox.

ce qui oblige à bricoler avec des scripts bash

La démonstration de cet avantage pourrait passer par la suppression de session.run('bash', './getlasso3.sh', external=True) ?

Ok.

Je n'ai vraiment aucune objection à quitter tox, il y aurait par contre je trouve à tester nox sur une situation moins simple, typiquement la validation sur plusieurs versions de django, pour valider l'affaire mais aussi pour avoir un exemple de comment ça se ferait (parce qu'avec le temps je peux ajouter un environnement au tox.ini pour arriver à faire ça, mais sur le noxfile.py je ne saurais évidemment pas faire sans aller aujourd'hui lire la documentation).

Ok

Aussi la PR lingo conserve un bout avec tox, ce qui est moyen mais j'imagine c'est parce que la version packagée debian est jugée trop ancienne et qu'il faut d'une manière ou d'une autre bootstrapper ça ?

Non, j'ai fait attention de faire quelque chose qui fonctionne avec la version de Nox packagée dans la version de Debian sur laquelle tourne le worker Jenkins. J'ai juste fait ça parce que je ne sais pas comment y installer un paquet.

#7

Updated by Frédéric Péters over 1 year ago

Réflexion supplémentaire, parce qu'avec nox ça doit devenir possible, arriver à un module commun pour certaines choses, pour par exemple ne pas avoir à aller modifier 20 modules pour y mettre (astroid<3 pylint<3) (#81905).

#8

Updated by Corentin Séchet over 1 year ago

Sur https://git.entrouvert.org/entrouvert/lingo/pulls/113 :

  • Pour la démonstration, j'ai ajouté une paramétrisation pour lancer les tests sur Django 3.1 & 3.2. Ça illustre le fait que le souci de mauvaise version installée serait résolu, puisque l'installation en 3.1 lève une erreur, aucune version ne pouvant satisfaire ce qu'on demande à pip.
  • Utilisé les posargs pour lancer les tests / pylint uniquement sur certains fichier, et activer le coverage (ce qui permet d'utiliser le même venv pour les tests avec ou sans coverage)
  • Déplacé getlasso3.sh et pylint.sh dans le noxfile. Pour pylint, il est possible de faire quelque chose de moins convolué en utilisant une version de nox plus récente qui permet de rediriger la sortie d'un session.run (C.F le code avant le commit "fix output pipe not available on Jenkin's nox version").
  • Utilisé session.interactive pour déterminer si on est sur Jenkins ou pas (en local, user --non-interactive permet de simuler le fonctionnement sur Jenkins)
  • J'ai eu l'erreur avec la nouvelle version de pylint évoqué dans #81905, j'ai downgradé la version à installer mais ça lève des faux positifs

Réflexion supplémentaire, parce qu'avec nox ça doit devenir possible, arriver à un module commun pour certaines choses, pour par exemple ne pas avoir à aller modifier 20 modules pour y mettre (astroid<3 pylint<3) (#81905).

Oui, on pourrait installer un package python en local & sur Jenkins, ou demander à nox de cloner un repo puis de l'importer, ou aller chercher un fichier de config partagé quelque part...

#9

Updated by Benjamin Dauvergne about 1 year ago

  • Tracker changed from Support to Développement
  • Status changed from Nouveau to Solution validée

Go.

#10

Updated by Benjamin Dauvergne 8 months ago

Je pose ça ici même si c'est un peu tard; les soucis de version conflictuelles n'ont rien à voir avec tox mais sont liés à la version de pip (< 20, https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020), ici avec tox j'ai bien les conflits qui sont rapportés:

dauvergne@revestel:~/wd/eo/authentic$ tox -e py3-stable-oldstable
py3-stable-oldstable: install_deps> python -I -m pip install coverage cssselect django-filter 'django-import-export<2.6,>=2.5' 'django-import-export<3.1,>=3.0' 'django-model-utils<4.3,>=4.2' 'django-select2<7.8,>=7.7' django-tables2==2.4.1 django-webtest 'django<3.3,>=3.2.12' 'djangorestframework<3.13,>=3.12' 'djangorestframework<3.15,>=3.14' 'enum34<=1.1.6' faker 'jwcrypto<0.9' 'jwcrypto<1.3,>=1.1' 'ldaptools>=0.24' lxml 'Markdown<3' 'mock<4' numpy 'pip>9' psycopg2-binary pyquery 'pytest!=5.3.3' pytest-cov pytest-django pytest-freezegun pytest-random pytest-xdist pytz responses uwsgidecorators WebTest git+https://git.entrouvert.org/entrouvert/gadjo.git@main
Collecting git+https://git.entrouvert.org/entrouvert/gadjo.git@main
  Cloning https://git.entrouvert.org/entrouvert/gadjo.git (to revision main) to /home/bdauvergne/.tmp/pip-req-build-9yimrlzm
  Resolved https://git.entrouvert.org/entrouvert/gadjo.git to commit f3879b91b2bc03f718e1b89f643a56e6331ec437
  Preparing metadata (setup.py) ... done
Collecting coverage
  Using cached coverage-7.5.3-cp311-cp311-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (8.2 kB)
Collecting cssselect
  Using cached cssselect-1.2.0-py2.py3-none-any.whl.metadata (2.2 kB)
Collecting django-filter
  Using cached django_filter-24.2-py3-none-any.whl.metadata (5.1 kB)
Collecting django-import-export<2.6,>=2.5
  Using cached django_import_export-2.5.0-py3-none-any.whl.metadata (3.9 kB)

The conflict is caused by:
    The user requested django-import-export<2.6 and >=2.5
    The user requested django-import-export<3.1 and >=3.0

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

  Running command git clone --filter=blob:none --quiet https://git.entrouvert.org/entrouvert/gadjo.git /home/bdauvergne/.tmp/pip-req-build-9yimrlzm
ERROR: Cannot install django-import-export<2.6 and >=2.5 and django-import-export<3.1 and >=3.0 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

py3-stable-oldstable: exit 1 (4.34 seconds) /home/bdauvergne/wd/eo/authentic> python -I -m pip install coverage cssselect django-filter 'django-import-export<2.6,>=2.5' 'django-import-export<3.1,>=3.0' 'django-model-utils<4.3,>=4.2' 'django-select2<7.8,>=7.7' django-tables2==2.4.1 django-webtest 'django<3.3,>=3.2.12' 'djangorestframework<3.13,>=3.12' 'djangorestframework<3.15,>=3.14' 'enum34<=1.1.6' faker 'jwcrypto<0.9' 'jwcrypto<1.3,>=1.1' 'ldaptools>=0.24' lxml 'Markdown<3' 'mock<4' numpy 'pip>9' psycopg2-binary pyquery 'pytest!=5.3.3' pytest-cov pytest-django pytest-freezegun pytest-random pytest-xdist pytz responses uwsgidecorators WebTest git+https://git.entrouvert.org/entrouvert/gadjo.git@main pid=446059
  py3-stable-oldstable: FAIL code 1 (4.58 seconds)
  evaluation failed :( (4.81 seconds)

Ça me paraissait bizarre cette histoire parce que nox et tox exécutent exactement les mêmes commandes (à part que tox est plus malin pour détecter s'il faut ré-installer ou non des paquets dans le venv)...

#11

Updated by Valentin Deniaud 8 months ago

Je recopie un commentaire de Benjamin dans https://git.entrouvert.org/entrouvert/authentic/pulls/324#issuecomment-38309 qui me semble alimenter ce ticket :

Le ticket nox d'origine parlait de gestion des contraintes et de partager du code en commun, y a rien de tout ça là. C'est du boulot inutile alors si en plus ça complexifie un tox.ini qui marchait très bien (et ça allait plus vite aussi) ça ne me va pas. Et l'argument du collectif est éculé. Je vais juste pousse ma branche vous ferez ce que vous voulez.

Niveau avantages qui n'ont pas été notés (mais qui recoupent quand même un peu la vision de Corentin #81739-2) :
#12

Updated by Benjamin Dauvergne 8 months ago

Valentin Deniaud a écrit :

Je recopie un commentaire de Benjamin dans https://git.entrouvert.org/entrouvert/authentic/pulls/324#issuecomment-38309 qui me semble alimenter ce ticket :

Le ticket nox d'origine parlait de gestion des contraintes et de partager du code en commun, y a rien de tout ça là. C'est du boulot inutile alors si en plus ça complexifie un tox.ini qui marchait très bien (et ça allait plus vite aussi) ça ne me va pas. Et l'argument du collectif est éculé. Je vais juste pousse ma branche vous ferez ce que vous voulez.

Niveau avantages qui n'ont pas été notés (mais qui recoupent quand même un peu la vision de Corentin #81739-2) :
  • nox -R (réutiliser venv + pas de réinstallation des packages) lance les tests vachement plus vite que tox (mais peut-être y a-t-il une option tox que je ne connais pas)

Avec la même option qui fait la même chose coté tox c'est pareil pour moi:

bdauvergne@revestel:~/wd/eo/authentic$ time nox -R -e tests -- tests/test_utils_crypto.py 
Installing customizaion of /usr/bin/nox/ /home/bdauvergne/.local/lib/python3.11/site-packages/usercustomize.py
nox > Running session tests
nox > Re-using existing virtual environment at .nox/tests.
nox > py.test -c .pytestrc tests/test_utils_crypto.py --pdbcls=IPython.terminal.debugger:TerminalPdb
=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.11.9, pytest-8.2.2, pluggy-1.5.0
django: version: 3.2.25, settings: authentic2.settings (from env)
rootdir: /home/bdauvergne/wd/eo/authentic
configfile: .pytestrc
plugins: Faker-25.5.0, random-0.2, cov-5.0.0, django-webtest-1.9.11, freezegun-0.4.2, django-4.8.0, xdist-3.6.1
collected 7 items                                                                                                                                                                                                 

tests/test_utils_crypto.py .......                                                                                                                                                                          [100%]

================================================================================================ warnings summary =================================================================================================
nox > Session tests was successful.

real    0m2,926s
user    0m2,565s
sys    0m0,351s

bdauvergne@revestel:~/wd/eo/authentic$ time tox --skip-pkg-install -e py3 -- tests/test_utils_crypto.py 
py3: skip building and installing the package
py3: commands[0]> ./getlasso3.sh
py3: commands[1]> py.test tests/test_utils_crypto.py
=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.11.9, pytest-8.2.2, pluggy-1.5.0
cachedir: /home/bdauvergne/.tmp/tox-bdauvergne/authentic/py3/.pytest_cache
django: version: 3.2.25, settings: authentic2.settings (from env)
rootdir: /home/bdauvergne/wd/eo/authentic
configfile: tox.ini
plugins: random-0.2, cov-5.0.0, django-webtest-1.9.11, Faker-25.4.0, freezegun-0.4.2, django-4.8.0, xdist-3.6.1
collected 7 items                                                                                                                                                                                                 

tests/test_utils_crypto.py .......                                                                                                                                                                          [100%]

================================================================================================ 7 passed in 0.30s ================================================================================================
  py3: OK (2.38=setup[0.01]+cmd[0.06,2.31] seconds)
  congratulations :) (2.65 seconds)

real    0m2,983s
user    0m2,687s
sys    0m0,288s

à 60ms d'écart, mais oui l'option est plus longue avec tox. Ce qui me gêne c'est que sans -R nox est plus, beaucoup plus lent (je pense que tox fait tout seul la détection de la compatibilité du venv exitant avec les préqrequis, sans passer par pip).

-r test_requirements.py fait pareil et ça document ces pré-requis, on a tendance à mélanger les pré-requis des tests, les pré-requis du paquet (j'ai du le corriger récemment dans le noxfile passerelle, zeep<3.3 qui est faux, c'est 4.x en prod bookworm et bullseye) et les pré-requis pour tester un environnement particulier (dj4.2, une version de debian, etc..) ce serait bien de justement séparer tout ça.

Mais vu le commentaire pointé je répond à coté; mais je ne vois pas ce que le noxfile a apporté on doit encore fixer les versions de pylint à la main dans chaque noxfile il me semble, on a rien changé là. On avancerait si on pouvait mutualiser un bout du noxfile dans un module python importé ou lu à distance.

Ça ok, coté a2 j'a trouvé bien pratique de réintégrer check-migrations par contre je ne comprends pas que coté combo on ait encore du shell compliqué pour l'appel à pylint:

        session.run(
            'bash',
            '-c',
            f'{shlex.join(pylint_command)} | tee pylint.out ; test $PIPESTATUS -eq 0',
            external=True,
        )

C'est le contraire de ce point pour moi. Coté a2 j'ai tenté de toute faire en python en suivant juste l'API de nox.

#13

Updated by Frédéric Péters 6 months ago

Je m'aperçois qu'il manque un truc aux builds nox, c'est l'affichage des versions des dépendances installées; avec tox il y a dans les logs une ligne comme

11:10:51  py3-django32-codestyle-coverage installed: asgiref==3.8.1,astroid==3.2.4,beautifulsoup4==4.12.3,bleach==5.0.1,...

et c'est très pratique (limite essentiel) pour identifier précisément l'origine de l'échec d'un build (quand rien d'autre n'a changé).

#14

Updated by Valentin Deniaud 6 months ago

  • Related to Développement #93872: nox, afficher les versions installées par pip sur la sortie jenkins added
#15

Updated by Frédéric Péters 5 months ago

#16

Updated by Yann Weber 5 months ago

#17

Updated by Yann Weber 5 months ago

#18

Updated by Yann Weber 5 months ago

#19

Updated by Emmanuel Cazenave 5 months ago

#20

Updated by Emmanuel Cazenave 5 months ago

#21

Updated by Emmanuel Cazenave 4 months ago

#23

Updated by Gael Pasgrimaud 4 months ago

#24

Updated by Emmanuel Cazenave 4 months ago

#25

Updated by Gael Pasgrimaud 4 months ago

#26

Updated by Gael Pasgrimaud 4 months ago

#27

Updated by Gael Pasgrimaud 4 months ago

#28

Updated by Gael Pasgrimaud 3 months ago

Also available in: Atom PDF