Bug #62527
migration vers bullseye et changement d’interface django tables (?)
0%
Description
à investiguer, mais ça a l’air d’être ce qui se passe dans #62520.
Fichiers
Révisions associées
Historique
Mis à jour par Paul Marillonnet il y a environ 2 ans
Oui c’est ça, cf le py3dist-overrides de authentic2/debian et la variation de version entre celle de buster et celle de bullseye.
Mis à jour par Paul Marillonnet il y a environ 2 ans
- Statut changé de Nouveau à En cours
- Assigné à mis à Paul Marillonnet
Mis à jour par Paul Marillonnet il y a environ 2 ans
- Fichier 0001-misc-add-compatibility-with-bullseye-s-django_tables.patch 0001-misc-add-compatibility-with-bullseye-s-django_tables.patch ajouté
- Statut changé de En cours à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a environ 2 ans
On va se traîner un peu de buster encore, il faut faire en sorte d'avoir un environnement tox pour buster et un autre pour bullseye, et comme c'est déjà en place pour Django Rest Framework il suffit de suivre, genre :
envlist = - authentic-py3-dj22-drf39 - authentic-py3-dj22-drf312 + authentic-py3-dj22-drf39-djtables1212 - pour https://packages.debian.org/buster/python3-django-tables2 = 1.21.2 + authentic-py3-dj22-drf312-djtables211 - pour https://packages.debian.org/bullseye/python3-django-tables2 = 2.1.1 ... ... et ce qu'il faut en dessous comme déclaration pour djtables1212 et djtables211
Mis à jour par Paul Marillonnet il y a environ 2 ans
Thomas Noël a écrit :
On va se traîner un peu de buster encore, il faut faire en sorte d'avoir un environnement tox pour buster et un autre pour bullseye, et comme c'est déjà en place pour Django Rest Framework il suffit de suivre, genre :
[...]
Arf oui j’avais zappé ça et d’ailleurs le changement de version majeure de django-tables2 casse la rétrocompatibilité.
Si on veut avoir le support des deux versions, on va se retrouver avec des branchements conditionnels partout dans les méthodes des classes de ce authentic2.manager.tables (initialisateurs qui ne prennent pas du tout les mêmes arguments par mot-clé, méthodes de rendu html dont l’ordre des arguments positionnels change, etc). C’est grave docteur ?
Mis à jour par Paul Marillonnet il y a environ 2 ans
Paul Marillonnet a écrit :
Arf oui j’avais zappé ça et d’ailleurs le changement de version majeure de django-tables2 casse la rétrocompatibilité.
Si on veut avoir le support des deux versions, on va se retrouver avec des branchements conditionnels partout dans les méthodes des classes de ceauthentic2.manager.tables(initialisateurs qui ne prennent pas du tout les mêmes arguments par mot-clé, méthodes de rendu html dont l’ordre des arguments positionnels change, etc).
Est-ce que quelqu’un voit une solution plus élégante ou bien je me lance là-dedans ?
Mis à jour par Thomas Noël il y a environ 2 ans
Paul Marillonnet a écrit :
Est-ce que quelqu’un voit une solution plus élégante ou bien je me lance là-dedans ?
Je donne ma langue au chat...
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
On peut pas juste backporter le package de django-tables 2 ?
Mis à jour par Paul Marillonnet il y a environ 2 ans
Benjamin Dauvergne a écrit :
On peut pas juste backporter le package de django-tables 2 ?
J’avais ça en tête en évoquant une "solution plus élégante", mais le doute m’habite, je donne ma langue au chat aussi.
Mis à jour par Paul Marillonnet il y a environ 2 ans
Paul Marillonnet a écrit :
Benjamin Dauvergne a écrit :
On peut pas juste backporter le package de django-tables 2 ?
J’avais ça en tête en évoquant une "solution plus élégante", mais le doute m’habite, je donne ma langue au chat aussi.
Bon, le patch qui gère dans authentic2.tables le support des deux versions django-tables2 concurrentes n’est pas aussi volumineux que ce que je m’imaginais.
Encore deux trois petits détails à régler (dont un crash pylint qui me laisse perplexe, bogue dans le parseur semblerait-il) et il n’y aura pas besoin de backporter.
Mis à jour par Paul Marillonnet il y a environ 2 ans
Paul Marillonnet a écrit :
Encore deux trois petits détails à régler (dont un crash pylint qui me laisse perplexe, bogue dans le parseur semblerait-il)
Quelqu’un a déjà vu passer ce genre de chose, i.e. un gros crash lors du parcours de l’arbre de syntaxe abstraite ?
pylint run-test: commands[1] | ./pylint.sh tests/ src/
[429528] /var/lib/jenkins/workspace/wip_wip_62527-djtables2-bullseye$ /var/lib/jenkins/workspace/wip_wip_62527-djtables2-bullseye/pylint.sh tests/ src/
Traceback (most recent call last):
File "/tmp/authentic-wip/wip%2F62527-djtabl-5/tox-jenkins/authentic/pylint/lib/python3.9/site-packages/pylint/utils/ast_walker.py", line 72, in walk
callback(astroid)
File "/tmp/authentic-wip/wip%2F62527-djtabl-5/tox-jenkins/authentic/pylint/lib/python3.9/site-packages/pylint/checkers/classes.py", line 1126, in visit_functiondef
self._check_signature(node, parent_function, "overridden", klass)
File "/tmp/authentic-wip/wip%2F62527-djtabl-5/tox-jenkins/authentic/pylint/lib/python3.9/site-packages/pylint/checkers/classes.py", line 2015, in _check_signature
f"{method1.parent.name}.{method1.name}",
AttributeError: 'If' object has no attribute 'name'
Exception on node <FunctionDef.render l.52 at 0x7f56279f88b0> in file '/var/lib/jenkins/workspace/wip_wip_62527-djtables2-bullseye/src/authentic2/manager/tables.py'
************* Module src.authentic2.manager.tables
src/authentic2/manager/tables.py:1: [F0001(fatal), ] Fatal error while checking 'src/authentic2/manager/tables.py'. Please open an issue in our bug tracker so we address this. There is a pre-filled template that you can use in '/var/lib/jenkins/.cache/pylint/pylint-crash-2022-03-11-10.txt'.
Sinon je vais ouvrir un rapport de bogue.
Mis à jour par Paul Marillonnet il y a environ 2 ans
- Fichier 0004-pylint-ignore-file-causing-abstract-syntax-tree-chec.patch 0004-pylint-ignore-file-causing-abstract-syntax-tree-chec.patch ajouté
- Fichier 0003-tox-add-django-tables2-oldstable-and-stable-test-env.patch 0003-tox-add-django-tables2-oldstable-and-stable-test-env.patch ajouté
- Fichier 0002-setup-increase-django-tables2-upper-version-bound-62.patch 0002-setup-increase-django-tables2-upper-version-bound-62.patch ajouté
- Fichier 0001-misc-add-compatibility-with-bullseye-s-django-tables.patch 0001-misc-add-compatibility-with-bullseye-s-django-tables.patch ajouté
Paul Marillonnet a écrit :
Paul Marillonnet a écrit :
Encore deux trois petits détails à régler (dont un crash pylint qui me laisse perplexe, bogue dans le parseur semblerait-il)
Quelqu’un a déjà vu passer ce genre de chose, i.e. un gros crash lors du parcours de l’arbre de syntaxe abstraite ?
[...]
Sinon je vais ouvrir un rapport de bogue.
Et en attendant, puisque c’est bloquant pour la migration bullseye, j’ai tapé un # pylint: skip-file en début de fichier.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Statut changé de Solution proposée à Information nécessaire
On pouvait pas juste mettre bound_column=None ?
Aussi tout faire en un patch, tout ça n'a pas tellement d'intérêt l'un sans l'autre.
Mis à jour par Paul Marillonnet il y a environ 2 ans
- Fichier 0001-misc-add-compatibility-with-bullseye-s-django-tables.patch 0001-misc-add-compatibility-with-bullseye-s-django-tables.patch ajouté
- Statut changé de Information nécessaire à Solution proposée
Benjamin Dauvergne a écrit :
On pouvait pas juste mettre
bound_column=None?
Ça ne suffirait pas pour ne plus avoir les if … else sur ces parties, l’ordre des arguments positionnels record et value s’inverse lors du passage à la v2 de django-tables2 (wtf).
Aussi tout faire en un patch, tout ça n'a pas tellement d'intérêt l'un sans l'autre.
Ok no souci. Je vais tenir une liste de qui me dit de splitter les patches quand on touche à la fois setup, au tox, au code applicatif etc, et qui me dit de tout réunir, pour directement adapter les patches en fonction du relecteur potentiel :)
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Statut changé de Solution proposée à Solution validée
Ok si l'ordre change en plus, misère comme dirait l'autre.
Mis à jour par Paul Marillonnet il y a environ 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit d423c6c7c76e70ee81c459798727457274aad769
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date: Fri Mar 11 09:38:53 2022 +0100
misc: add compatibility with bullseye's django-tables2 (#62527)
Mis à jour par Transition automatique il y a environ 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
misc: add compatibility with bullseye's django-tables2 (#62527)