spike(deps): auditer le fork ADNPolymerase/pronotepy sans engager de migration #22

New Issue

AntoineVe · 2026-09-10T14:14:12+02:00

AntoineVe commented

2026-09-10 14:14:12 +02:00

Objectif

Audit (spike) du fork ADNPolymerase/pronotepy pour évaluer s'il corrige les bugs upstream qui nous impactent (#20, #21), sans engager de migration.

Blocage explicite

⚠️ Ce ticket ne doit pas être traité avant la clôture de #20 et #21, ou au minimum avant qu'ils aient établi une conclusion écrite sur la localisation de la cause racine (notre code vs pronotepy upstream). Si la cause est interne à pronote-sync, cet audit est prématuré.

Contexte

bain3/pronotepy est en mode maintenance (« We will continue to fix bugs and adapt to PRONOTE changes, but will not be adding new features »).
Nos tickets #20 et #21 pointent vers des issues upstream non résolues :
- bain3/pronotepy#344 — fuites de sessions, multiples authentifications
- bain3/pronotepy#309 — erreur 20 « La page a expiré » en mode token/QR
Un fork par ADNPolymerase semble poursuivre le développement : https://github.com/ADNPolymerase/pronotepy

Périmètre autorisé (lecture seule)

Diff et historique : comparer le fork contre bain3/pronotepy@2.15.7 (commits ajoutés, fichiers touchés, divergence totale)
Correction effective : vérifier factuellement que le fork corrige #344 et #309 (lien commit → issue, pas supposition)
Maintenance : dernière activité, nombre de mainteneurs, présence de CI/tests dans le fork, licence inchangée, bus factor
Compatibilité API : vérifier la compatibilité stricte des signatures pour :
- qrcode_login(qr_code, pin, uuid)
- token_login(pronote_url, username, password, uuid, ...)
- export_credentials()
- ParentClient vs Client
- Gestion des erreurs (PronoteAPIError, codes d'erreur notamment le code 20)
Distribution : le fork est-il publié sur PyPI ou uniquement via git URL ? Impact sur pyproject.toml et la reproductibilité des builds

Interdit dans ce ticket

❌ Toute modification de pyproject.toml
❌ Toute exécution des tests contre le fork (viendrait dans un ticket ultérieur de bascule)
❌ Toute promesse de calendrier de bascule
❌ Toute modification de code de production

Critères d'acceptation

Rapport écrit dans le ticket répondant explicitement à :
- Le fork corrige-t-il #344 et #309 ?
- Est-il activement maintenu ou dormant ?
- Introduit-il une divergence d'API sur les points listés ci-dessus ?
- Quel est le mode de distribution (PyPI ou git+commit SHA) ?
Recommandation binaire formulée :
- Adopter (avec plan de bascule en ticket séparé)
- Rejeter (rester sur bain3/pronotepy, documenter pourquoi)
- Patch local ciblé (override de méthode en attendant, sans changer de dépendance)
Aucune ligne de code de production modifiée

Conditions de révision

Si #20 et #21 concluent (avec preuve) que la cause est exclusivement côté pronotepy, cet audit devient prioritaire et peut être lancé immédiatement.
Si le mode qr_token devient totalement bloquant en production avant la clôture de l'audit, réévaluer l'urgence : un patch local ciblé (override du comportement de refresh) peut être justifié en pont.
Si le fork s'avère être un simple miroir sans divergence réelle, clore ce ticket avec la recommandation « rejeter ».

## Objectif Audit (spike) du fork `ADNPolymerase/pronotepy` pour évaluer s'il corrige les bugs upstream qui nous impactent (#20, #21), **sans engager de migration**. ## Blocage explicite ⚠️ Ce ticket ne doit **pas** être traité avant la clôture de #20 et #21, ou au minimum avant qu'ils aient établi une conclusion écrite sur la localisation de la cause racine (notre code vs pronotepy upstream). Si la cause est interne à `pronote-sync`, cet audit est prématuré. ## Contexte - `bain3/pronotepy` est en mode maintenance (« We will continue to fix bugs and adapt to PRONOTE changes, but will not be adding new features »). - Nos tickets #20 et #21 pointent vers des issues upstream non résolues : - [bain3/pronotepy#344](https://github.com/bain3/pronotepy/issues/344) — fuites de sessions, multiples authentifications - [bain3/pronotepy#309](https://github.com/bain3/pronotepy/issues/309) — erreur 20 « La page a expiré » en mode token/QR - Un fork par `ADNPolymerase` semble poursuivre le développement : https://github.com/ADNPolymerase/pronotepy ## Périmètre autorisé (lecture seule) 1. **Diff et historique** : comparer le fork contre `bain3/pronotepy@2.15.7` (commits ajoutés, fichiers touchés, divergence totale) 2. **Correction effective** : vérifier factuellement que le fork corrige #344 et #309 (lien commit → issue, pas supposition) 3. **Maintenance** : dernière activité, nombre de mainteneurs, présence de CI/tests dans le fork, licence inchangée, bus factor 4. **Compatibilité API** : vérifier la compatibilité stricte des signatures pour : - `qrcode_login(qr_code, pin, uuid)` - `token_login(pronote_url, username, password, uuid, ...)` - `export_credentials()` - `ParentClient` vs `Client` - Gestion des erreurs (`PronoteAPIError`, codes d'erreur notamment le code 20) 5. **Distribution** : le fork est-il publié sur PyPI ou uniquement via git URL ? Impact sur `pyproject.toml` et la reproductibilité des builds ## Interdit dans ce ticket - ❌ Toute modification de `pyproject.toml` - ❌ Toute exécution des tests contre le fork (viendrait dans un ticket ultérieur de bascule) - ❌ Toute promesse de calendrier de bascule - ❌ Toute modification de code de production ## Critères d'acceptation - [ ] Rapport écrit dans le ticket répondant explicitement à : - Le fork corrige-t-il #344 et #309 ? - Est-il activement maintenu ou dormant ? - Introduit-il une divergence d'API sur les points listés ci-dessus ? - Quel est le mode de distribution (PyPI ou git+commit SHA) ? - [ ] Recommandation binaire formulée : - **Adopter** (avec plan de bascule en ticket séparé) - **Rejeter** (rester sur `bain3/pronotepy`, documenter pourquoi) - **Patch local ciblé** (override de méthode en attendant, sans changer de dépendance) - [ ] Aucune ligne de code de production modifiée ## Conditions de révision - Si #20 et #21 concluent (avec preuve) que la cause est **exclusivement** côté pronotepy, cet audit devient prioritaire et peut être lancé immédiatement. - Si le mode `qr_token` devient totalement bloquant en production avant la clôture de l'audit, réévaluer l'urgence : un patch local ciblé (override du comportement de refresh) peut être justifié en pont. - Si le fork s'avère être un simple miroir sans divergence réelle, clore ce ticket avec la recommandation « rejeter ».

AntoineVe added the bug investigation labels 2026-09-10 14:14:12 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#22