routeros-client 0.6.0__tar.gz

routeros_client-0.6.0/.env.example

@@ -0,0 +1,17 @@
+# Configuration de la campagne de tests réels (test_live_router.py).
+# Copiez ce fichier en .env et adaptez-le, ou exportez ces variables.
+# .env est ignoré par git : n'y mettez que des identifiants de LABORATOIRE.
+
+ROS_HOST=192.168.88.1
+ROS_USER=admin
+ROS_PASSWORD=change-me
+
+# Ports RouterOS — à ne surcharger que si vos services n'écoutent pas
+# sur les ports standards.
+ROS_PORT_API=8728
+ROS_PORT_API_SSL=8729
+ROS_PORT_SSH=22
+ROS_PORT_REST=80
+
+# Nom de la liste d'adresses jetable créée puis supprimée par les tests.
+ROS_TEST_LIST=rosapi-selftest

routeros_client-0.6.0/CHANGELOG.md

@@ -0,0 +1,437 @@
+# Changelog — routeros_api
+
+## v0.6.0
+
+Trois axes : **23 bugs corrigés**, **9 optimisations de performance**, **transport SSH ajouté**.
+La compatibilité ascendante avec la v0.5.0 est préservée (voir la section dédiée en fin de document).
+
+L'ancienne version est conservée telle quelle dans `routeros_api_v0.5.0.bak.py`.
+
+### Validation
+
+| Campagne | Commande | Résultat |
+| --- | --- | --- |
+| Hors-ligne (aucun routeur requis) | `python -m unittest test_routeros_api -v` | **90/90** |
+| Hors-ligne, contre la **wheel installée** | idem depuis un répertoire neutre | **90/90** |
+| Routeur réel | `python test_live_router.py` | **62/62** |
+| Analyse statique | `ruff check routeros_api.py` | **0 finding** |
+| Version Python minimale du code | `vermin routeros_api.py` | **3.7** (installation déclarée 3.9+, voir §5) |
+| Métadonnées de distribution | `twine check --strict dist/*` | **PASSED** |
+
+La campagne hors-ligne passe **avec et sans `paramiko` installé**, aussi bien depuis les sources que
+depuis la wheel installée en site-packages.
+
+Les tests concernés par un bug sont nommés `test_bugN_…`.
+
+La campagne réelle a été exécutée contre un **RouterOS 7.23.3 (stable), CHR** sur
+`192.168.117.132`, aux ports par défaut — API 8728, API-SSL 8729, SSH 22, REST 80 — et couvre les
+quatre transports, les écritures (`add`/`set`/`remove`/`ensure`/`bulk_*`/pipelining), `listen()`,
+`export()`, `ping_host()`, les bascules de transport, et la cohérence des données entre API et SSH.
+Tous les objets créés pendant les tests sont supprimés en fin de campagne (vérifié).
+**Les bugs 20, 21 et 22 ci-dessous n'ont été révélés que par cette campagne réelle** — aucun test
+hors-ligne ne pouvait les détecter.
+
+---
+
+## 1. Bugs corrigés
+
+### BUG-1 — 🔴 Critique : désynchronisation permanente du flux après une erreur
+
+`_read_response()` levait `RouterOSCommandError` **dès la réception du `!trap`** quand aucun tag
+n'était attendu — c'est-à-dire pour tous les appels de `cmd()`, `talk()`, `print()`, `add()`, `set()`…
+puisque `use_tag` vaut `False` par défaut.
+
+Le protocole termine **toujours** une commande par un `!done`, y compris après un `!trap`. Ce `!done`
+restait donc dans le tampon et était lu par la commande **suivante** comme si c'était sa réponse.
+
+Conséquence : après la moindre erreur de syntaxe ou de permission, toutes les commandes suivantes
+étaient décalées d'une réponse — `print()` renvoyait des listes vides, `add()` semblait réussir sans
+rien créer. Le tout sans aucune erreur visible.
+
+**Correctif** : le `!trap` est mémorisé, la lecture continue jusqu'au `!done`, puis l'exception est levée.
+Un délai de garde (`trap_drain_timeout`, 5 s) évite un blocage si un routeur n'envoie pas le `!done`.
+*(test `test_bug1_trap_keeps_stream_in_sync`)*
+
+### BUG-2 — 🔴 `cmd_timeout` laissait le socket définitivement en mode non bloquant
+
+La restauration était conditionnée par `if prev_timeout is not None`. Or `gettimeout()` renvoie
+précisément `None` pour un socket bloquant — le cas par défaut. Après un seul appel avec
+`cmd_timeout=…`, le socket gardait ce timeout **pour toute la session** : les commandes longues
+(`/export`, gros `print`) échouaient ensuite en timeout sans raison apparente.
+
+**Correctif** : sentinelle `_UNSET` pour distinguer « non modifié » de « était None ».
+*(test `test_bug2_timeout_restored_on_blocking_socket`)*
+
+### BUG-3 — 🔴 La reconnexion automatique détruisait la file de tâches
+
+`_ensure_connected()` appelait `self.close()`, qui exécute `queue.shutdown()` puis `self.queue = None`.
+Après une reconnexion réussie : `api.queue.submit(...)` → `AttributeError: 'NoneType'`.
+Pire, si la reconnexion partait d'un worker de la file, `close()` faisait joindre le thread courant
+à lui-même → `RuntimeError: cannot join current thread`.
+
+**Correctif** : nouveau `_reset_connection()` qui ne ferme que le socket ; `ApiQueue.shutdown()`
+ignore le thread courant.
+
+### BUG-4 — 🔴 Réponses taguées d'une autre commande interprétées comme siennes
+
+Le filtre `if expected_tag and phrase_tag and phrase_tag != expected_tag` ne s'appliquait que
+lorsqu'un tag était attendu. Sans tag, une phrase taguée (reliquat d'un `listen()` annulé, d'un
+`/cancel` tardif) était intégrée aux enregistrements de la commande en cours.
+
+**Correctif** : toute phrase portant un tag différent de celui attendu est écartée vers
+`_ResponseRouter`. `!fatal` reste traité en priorité, quel que soit son tag.
+*(test `test_bug4_foreign_tag_is_not_consumed_as_own`)*
+
+### BUG-4b — 🔴 `/cancel` hors verrou et jamais consommé
+
+`cancel()` écrivait sur le socket **sans** `_socket_lock` : la trame pouvait s'entrelacer avec celle
+d'un autre thread. De plus, `/cancel` n'était pas tagué : le `!done` qu'il provoque était attribué à
+la commande suivante (même symptôme que BUG-1).
+
+**Correctif** : envoi sous verrou, `/cancel` porte son propre tag, sa réponse est identifiée et écartée.
+
+### BUG-5 — 🔴 `ApiQueue.shutdown()` abandonnait les futures en attente
+
+Les tâches encore en file n'étaient ni exécutées, ni annulées, ni marquées `task_done()` :
+un `future.result()` bloquait **indéfiniment**, et `ApiQueue.join()` ne revenait jamais.
+
+**Correctif** : purge de la file au shutdown, chaque future est annulée et chaque tâche marquée terminée.
+*(test `test_bug5_shutdown_resolves_pending_futures`)*
+
+### BUG-6 — 🟠 Fuite mémoire du routeur de réponses
+
+`_ResponseRouter.dispatch()` empilait les phrases dans des `Queue` que rien ne consommait, et
+`release()` n'était jamais appelé. Sur un service de longue durée utilisant des tags, la mémoire
+croissait sans borne.
+
+**Correctif** : routeur borné (1000 phrases, éviction des plus anciennes avec log), `release()` appelé
+en fin de chaque commande taguée, `clear()` à la déconnexion.
+
+### BUG-7 — 🟠 `talk()` modifiait la liste de l'appelant
+
+`_execute_talk()` faisait `words = msg` (sans copie) puis `words.append(".tag=…")`. La liste passée par
+l'appelant était donc modifiée, et un retry (`enable_resilience`) ajoutait un **second** `.tag=` à la
+même commande — que RouterOS rejette.
+
+**Correctif** : la liste est copiée dès qu'un tag doit être ajouté.
+*(test `test_bug7_caller_list_is_not_mutated`)*
+
+### BUG-8 — 🟠 Régression : les guillemets étaient stockés dans les valeurs
+
+Le « BUG-9 FIX » de la v0.5.0 conservait les guillemets englobants dans le mot encodé.
+Le protocole binaire délimitant les mots par **longueur**, aucun quoting n'est nécessaire :
+`=comment="hello world"` créait un commentaire contenant littéralement les guillemets.
+
+**Correctif** : retour au comportement correct (guillemets retirés), plus le support de `\"`.
+Ancien comportement disponible via `RouterOSProtocol.KEEP_QUOTES = True`.
+*(tests `test_split_command_*`)*
+
+### BUG-9 — 🟡 `APIResponse.error_message` documenté mais jamais renseigné
+
+Le champ était annoncé dans le code comme « peuplé par `_read_response()` » ; il valait toujours `None`.
+
+**Correctif** : nouveau paramètre `raise_on_trap=False` sur `talk()` / `_read_response()` qui renvoie
+la réponse avec `error_message` et `error_category` renseignés. Ajout de `.ok` et `.raise_for_error()`.
+
+### BUG-10 — 🟠 `listen(timeout=…)` sans effet
+
+L'échéance était vérifiée **avant** un `read_sentence()` bloquant. Sur une connexion sans timeout socket
+(le défaut), l'appel restait bloqué pour toujours et le paramètre `timeout` n'avait aucun effet.
+
+**Correctif** : lecture par tranches d'une seconde, échéance réévaluée à chaque tranche.
+*(test `test_bug10_listen_timeout_is_enforced`)*
+
+### BUG-11 — 🟡 `ApiQueue.submit(timeout=…)` silencieusement ignoré
+
+Le paramètre était accepté puis jamais utilisé.
+**Correctif** : transmis comme `cmd_timeout` à `talk()`. *(test `test_bug11_submit_timeout_is_applied`)*
+
+### BUG-12 — 🟠 Filtres `id=` sans effet dans `get_filtered()` et `ResourceProxy.get()`
+
+Seul `get_proplist()` normalisait les clés système. `proxy.find(id="*1")` envoyait `?id=*1`, que
+RouterOS ignore : la requête retournait **toute la table** au lieu d'une entrée — silencieusement.
+Une valeur `None` produisait par ailleurs le filtre absurde `?key=None`.
+
+**Correctif** : normalisation centralisée dans `_query_words()` ; `None` produit `?key` (test
+d'existence) ; support des opérateurs `?>`, `?<`. *(test `test_bug12_query_words_normalize_id`)*
+
+### BUG-13 — 🟡 `ping_host()` : intervalle tronqué et latences non analysées
+
+* `interval=1.5` produisait `interval=1s` (`ms // 1000`) ;
+* `float("12ms490us".replace("ms",""))` lève `ValueError`, silencieusement avalée : `min/avg/max_ms`
+  restaient à 0 sur RouterOS v7, qui renvoie systématiquement ce format.
+
+**Correctif** : `parse_duration_ms()` gère `12ms490us`, `2s500ms`, `1w2d3h`, `00:00:01.5` ;
+l'intervalle sub-seconde est émis en millisecondes. *(test `test_bug13_ping_parses_sub_ms_and_interval`)*
+
+### BUG-14 — 🟡 `get_multi()` fragile
+
+Indexation `responses[i]` sans garde (IndexError possible) et test `if responses[i]` faux pour une
+table vide, `APIResponse.__len__` valant alors 0.
+**Correctif** : correspondance par index sécurisée et test de type explicite.
+
+### BUG-15 — 🟡 Paramètre `encoding` accepté puis ignoré
+
+`Api(encoding="latin-1")` n'avait aucun effet : `encode_word()` codait en dur `utf-8`.
+**Correctif** : l'encodage est propagé jusqu'à l'encodage/décodage des mots.
+
+### BUG-16 — 🟡 Octet d'en-tête réservé traité comme une fin de phrase
+
+`decode_word_length()` renvoyait `(0, 1)` pour `0xF1..0xFF`, ce qui simulait un mot vide — donc une
+fin de phrase — et masquait une désynchronisation du flux.
+**Correctif** : `RouterOSProtocolError` explicite.
+
+### BUG-17 — 🟡 `AttributeError` au lieu d'une erreur typée
+
+`_read_response()` et `export()` déréférençaient `self.sock` sans garde : après un `!fatal` ou un
+`close()` concurrent, l'appelant recevait `AttributeError: 'NoneType' object has no attribute
+'read_sentence'` au lieu de `RouterOSConnectionError`.
+
+### BUG-18 — 🟡 Erreur d'authentification masquée en mode AUTO
+
+Sur RouterOS ≥ 6.45 (authentification legacy supprimée), un mot de passe erroné produisait
+« Pas de challenge reçu » — message trompeur, la vraie cause étant perdue.
+**Correctif** : les deux erreurs (plaintext + legacy) sont rapportées et chaînées.
+
+### BUG-19 — 🟡 `RestApi` : authentification non préemptive
+
+Avec le seul `HTTPBasicAuthHandler`, **chaque** requête coûtait deux allers-retours (401 puis rejeu),
+et échouait si le routeur ne renvoyait pas un `WWW-Authenticate` exploitable.
+**Correctif** : en-tête `Authorization: Basic` envoyé d'emblée (`preemptive_auth=True`), 401/403
+remontés en `RouterOSAuthError`, respect de `Retry-After`, `close()` robuste.
+
+### BUG-20 — 🔴 `api-ssl` (8729) inutilisable : handshake TLS systématiquement refusé
+
+*Découvert en conditions réelles.* Sans certificat configuré — la situation par défaut — le service
+`api-ssl` de RouterOS ne propose **que des suites anonymes** (`ADH-AES256-SHA256`). Le contexte SSL par
+défaut de Python les refuse : toute connexion `use_ssl=True` échouait sur
+`SSLV3_ALERT_HANDSHAKE_FAILURE`, y compris avec `ssl_verify=False`. Le transport TLS de la v0.5.0 ne
+pouvait donc pas fonctionner contre une configuration RouterOS standard.
+
+**Correctif** : quand `ssl_verify=False` (l'appelant a déjà renoncé à authentifier le pair), le
+contexte réactive les suites anonymes en essayant `ALL:@SECLEVEL=0`, puis `ADH:@SECLEVEL=0`, puis
+`ALL:aNULL`. Désactivable par `ssl_allow_anonymous=False`.
+Vérifié sur ROS 7.23.3 : négocie `ADH-AES256-SHA256 / TLSv1.2`.
+
+### BUG-21 — 🟠 `RestApi.add()` : mauvais verbe HTTP (régression v0.5.0)
+
+*Découvert en conditions réelles.* Le « BUG-10 FIX » de la v0.5.0 avait remplacé `PUT` par `POST` au
+nom de la sémantique REST habituelle. L'API REST de RouterOS ne suit pas cette convention :
+
+| Verbe | Effet réel côté RouterOS |
+| --- | --- |
+| `PUT /rest/<menu>` | **crée** — HTTP 201 + objet créé |
+| `POST /rest/<menu>` | HTTP 400 `{"detail":"no such command"}` |
+| `POST /rest/<menu>/<commande>` | invoque une commande (`/print`, `/monitor`…) |
+| `PATCH /rest/<menu>/<id>` | modifie |
+| `DELETE /rest/<menu>/<id>` | supprime |
+
+`add()` était donc **cassé** en v0.5.0 : toute création via REST échouait en HTTP 400.
+
+**Correctif** : retour à `PUT`, plus une méthode `command()` pour l'invocation de commandes.
+
+### BUG-22 — 🟠 SSH : options placées avant les paramètres
+
+*Découvert en conditions réelles.* `_CliCommand.render()` émettait les options avant les paramètres,
+produisant `/ping as-value address=127.0.0.1`. Or `/ping` prend l'hôte en **argument positionnel** :
+RouterOS tentait de joindre un hôte nommé « as-value », le mode `as-value` échouait, et `ping_host()`
+retombait silencieusement sur l'analyse du tableau texte — d'où des latences perdues (`avg_ms = 0.0`
+alors que le routeur répondait en 0,077 ms).
+
+**Correctif** : ordre `commande → positionnels → paramètres → options → where`, valide pour les deux
+familles de commandes. *(test `test_bug22_options_come_after_parameters`)*
+
+### BUG-23 — 🟡 SSH/OpenSSH : `timeout` ignoré sur les flux
+
+*Découvert par l'analyse statique finale (`ruff ARG002`).* `_OpenSshBackend.stream()` acceptait un
+paramètre `timeout` puis ne s'en servait jamais : un `print follow` lancé via le client OpenSSH
+tournait indéfiniment même lorsque l'appelant avait fixé une échéance. Même classe de défaut que
+BUG-11.
+
+**Correctif** : le flux s'interrompt une fois l'échéance atteinte, et le processus est terminé dans
+le `finally`.
+
+### Limite RouterOS documentée (et non un bug de la bibliothèque)
+
+Sur RouterOS 7.23.3, **`/export` ne renvoie rien via le protocole API binaire** : ni `!re`, ni `=ret=`,
+ni erreur. `Api.export()` retourne donc une chaîne vide quoi que fasse la bibliothèque — un
+avertissement est désormais journalisé pour éviter le diagnostic à l'aveugle. `SshApi.export()`
+fonctionne pleinement : c'est la voie à utiliser pour sauvegarder une configuration.
+
+### Corrections mineures complémentaires
+
+* `export()` : test `"=message=" in word` remplacé par une analyse correcte ; l'export passe désormais
+  par le chemin de lecture commun (tag, verrou, gestion du `!trap`).
+* `api_session()` : `retry` négatif ne peut plus produire `yield None`.
+* `__del__` : ne relance plus de threads pendant l'arrêt de l'interpréteur.
+* `close()` : idempotent, remet `connected`/`logged_in` à `False` même sans socket.
+* `_send_sentence()` : masque aussi `=response=` (empreinte MD5) dans les logs `verbose`.
+* `cmd()` / `print()` : `cmd_timeout` (et `on_record`) sont devenus des arguments **nommés
+  exclusifs**. Ils partaient auparavant dans `**kwargs` et étaient envoyés au routeur comme des
+  propriétés — `api.print("/x", cmd_timeout=5)` provoquait `unknown parameter cmd_timeout`.
+  `add()`, `set()`, `remove()`, `enable()` et `disable()` en héritent.
+* `auto_connect()` : nouveau `transport_kwargs={"api": {...}, "ssh": {...}}`. Un `port=` global
+  s'appliquait à tous les transports, ce qui rendait la bascule API→SSH impossible dès qu'un port
+  non standard était précisé.
+
+---
+
+## 2. Performances
+
+| # | Optimisation | Gain |
+| --- | --- | --- |
+| P1 | Tampon de réception à curseur + compactage amorti (`del buffer[:n]` était exécuté à **chaque mot**) | O(n²) → O(n) : ~40× plus rapide sur une réponse de 10 000 enregistrements |
+| P2 | `TCP_NODELAY` activé | supprime jusqu'à ~40 ms de latence Nagle/ACK différé **par commande** |
+| P3 | Décodage de l'en-tête sur place (plus de double analyse ni de slice intermédiaire) | ~25 % sur la boucle de lecture |
+| P4 | `partition()` au lieu de `split("=", 1)` + liaisons locales dans les boucles chaudes | ~10 % sur le parsing des enregistrements |
+| P5 | **Pipelining** : `batch(pipeline=True)` envoie N commandes en une trame et lit les réponses par tag | N allers-retours → 1 (200 commandes à 20 ms de latence : ~4 s → ~0,1 s) |
+| P6 | `ApiQueue` créée à la demande (`lazy_queue=True`) | plus de thread inutile par instance `Api` |
+| P7 | `SO_KEEPALIVE` + `set_keepalive` SSH | détection des connexions mortes |
+| P8 | REST : authentification préemptive | 2 requêtes HTTP → 1 |
+| P9 | `paramiko` importé **paresseusement** (à la première connexion SSH) | `import routeros_api` : **982 ms → 475 ms** quand paramiko est installé |
+
+À cela s'ajoutent `iter_print()` (lecture au fil de l'eau, mémoire constante) et le multiplexage
+d'une seule connexion SSH pour toutes les commandes (backend paramiko).
+
+---
+
+## 3. Transport SSH (nouveau)
+
+`SshApi` expose **exactement la même surface** que `Api` — `talk / cmd / print / add / set / remove /
+enable / disable / batch / bulk_* / get_resource / ping_host / export / listen` — si bien que le code
+métier existant fonctionne sans modification :
+
+```python
+from routeros_api import connect, ssh_session
+
+# API binaire (inchangé)
+api = connect("192.168.88.1", "admin", "secret")
+
+# SSH — même code métier ensuite
+ros = connect("192.168.88.1", "admin", transport="ssh",
+              key_filename="~/.ssh/id_ed25519")
+
+with ssh_session("192.168.88.1", "admin", password="secret") as ros:
+    for addr in ros.get_resource("/ip/address").find(disabled=False):
+        print(addr["address"])
+
+# Bascule automatique API → SSH selon ce qui répond
+ros = auto_connect(ip, "admin", pwd, order=("api", "ssh"))
+```
+
+**Fonctionnement.** Les commandes protocolaires (`"/ip/address/print"`, `"=address=…"`,
+`"?disabled=false"`) sont traduites en ligne de commande RouterOS par `RouterOSCli`, exécutées dans un
+canal `exec` (aucune analyse d'invite, code de retour disponible), puis la sortie est re-parsée en
+enregistrements identiques à ceux de l'API. Trois formats sont essayés, du plus fidèle au plus tolérant :
+
+1. `:put [:serialize to=json [<cmd> as-value]]` — RouterOS v7, restitue les mêmes champs que l'API, `.id` compris ;
+2. `:put [<cmd> as-value]` — RouterOS v6 et v7 ;
+3. `<cmd> without-paging terse` — repli universel.
+
+Le mode retenu est mémorisé après la première commande.
+
+**Dépendances.** `paramiko` est **optionnel** : s'il est installé, mot de passe / clé / agent sont
+supportés. Sinon, le module bascule sur le client `ssh` du système (clé ou agent uniquement ; un mot de
+passe lève une erreur explicite indiquant les options).
+
+> **À installer si vous utilisez SSH avec un mot de passe** : `pip install paramiko`.
+> Sans lui, `SshApi(..., password="…")` lève `RouterOSSSHError` avec le message d'aide correspondant.
+> La campagne réelle a été menée avec paramiko 5.0.0.
+
+**Sécurité.** Toute valeur sortant d'un jeu de caractères sûr est quotée et échappée (`\`, `"`, `$`,
+sauts de ligne) et les segments de chemin sont validés — sans quoi une valeur contenant `;` ou un saut
+de ligne permettrait d'injecter une commande dans la console. Vérification de la clé d'hôte activée par
+défaut (`strict_host_key=True`).
+
+**Limites.** Pas de multiplexage par tag : `batch(pipeline=True)` retombe en séquentiel, `cancel()` est
+sans objet, `listen()` est émulé via `print follow`. Compter ~2 à 5 ms de surcoût par commande.
+
+Extras : `run()` / `run_script()` (passe-plat CLI brut, pour ce que l'API ne sait pas faire),
+`sftp_get()` / `sftp_put()` (backend paramiko).
+
+---
+
+## 4. Autres nouveautés
+
+* `ensure(path, match, values)` — création/mise à jour idempotente, retourne `(.id, created)`.
+* `find_id()`, `find_ids()`, `remove_where()`, `is_alive()`.
+* `iter_print()` — générateur à mémoire constante sur les grosses tables.
+* `Api.pipeline()` — gestionnaire de contexte autour du pipelining.
+* `APIResponse` : `.ok`, `.first()`, `.values()`, `.ids()`, `.typed()`, `.raise_for_error()`.
+* `to_python()`, `parse_duration_ms()` — conversion de valeurs RouterOS (opt-in).
+* `_format_value()` : `True` → `yes`, `None` → `""`, `["a","b"]` → `"a,b"` (la v0.5.0 envoyait `True`).
+* `cmd(..., _params={...})` — échappatoire pour les propriétés dont le nom entre en collision avec un
+  paramètre Python (`path`, `proplist`).
+* `auto_connect()`, `ssh_connect()`, `rest_connect()`, `ssh_session()`, enums `Transport` / `SshBackend`.
+* `RestApi.query()` — filtrage côté serveur.
+* Retry avec jitter, `Retry-After` respecté côté REST.
+
+---
+
+## 5. Distribution / PyPI
+
+Le projet est désormais publiable. Point à connaître avant toute installation :
+
+> **Le nom de distribution diffère du nom d'import.**
+> `pip install routeros-client` → `import routeros_api`
+
+`routeros-api` est déjà occupé sur PyPI par un autre projet (v0.21.0, « Python API to RouterBoard
+devices produced by MikroTik »). PyPI normalisant les noms, ses variantes `routeros_api` et
+`RouterOS-api` désignent ce même projet : aucune n'était disponible. Le **nom d'import reste
+`routeros_api`** afin que les applications existantes continuent de fonctionner sans modification.
+
+*Conséquence à surveiller* : ce paquet et le `routeros-api` de PyPI installent tous deux un
+`routeros_api` importable. Ne les installez pas dans le même environnement.
+
+Fichiers ajoutés :
+
+| Fichier | Rôle |
+| --- | --- |
+| `pyproject.toml` | Métadonnées PEP 621, `dependencies = []`, extras `[ssh]` et `[dev]`, config ruff |
+| `LICENSE` | MIT |
+| `MANIFEST.in` | Contenu de l'archive source |
+| `.github/workflows/ci.yml` | Tests sur 6 combinaisons OS × Python (3.9→3.13), **avec et sans paramiko**, ruff, vermin, construction et validation des artefacts |
+| `.github/workflows/publish.yml` | Publication PyPI sur étiquette `v*` via Trusted Publishing (OIDC, aucun token stocké), avec garde-fou de cohérence étiquette ↔ `__version__` |
+
+Dépôt cible : <https://github.com/jackarten/routeros-client> — renseigné dans `[project.urls]` et
+dans le workflow de publication.
+
+### Plancher Python : 3.9
+
+Les métadonnées de licence suivent la **PEP 639** (`license = "MIT"` en expression SPDX +
+`license-files`), qui exige **setuptools ≥ 77**. Or setuptools a abandonné Python 3.8 en v76 : sur
+3.8, la version la plus récente disponible est 75.x, qui ne connaît que l'ancienne forme
+`license = { text = "MIT" }` et rejette la chaîne SPDX avec
+« `project.license` must be valid exactly by one definition ». La construction du paquet y est donc
+impossible.
+
+Python 3.8 étant en fin de vie depuis octobre 2024, `requires-python` est fixé à **`>=3.9`** plutôt
+que de revenir à des métadonnées dépréciées. Le **code**, lui, reste compatible 3.7+ (vérifié par
+vermin) : pour couvrir 3.8, il suffit de repasser `license` sous la forme `{ text = "MIT" }`,
+d'ajouter le classifieur `License :: OSI Approved :: MIT License` et d'abaisser
+`requires = ["setuptools>=61"]`. La marche à suivre est consignée dans `pyproject.toml`.
+
+Reste à faire avant la première publication : créer le dépôt distant et y pousser le code, puis
+déclarer l'éditeur de confiance sur <https://pypi.org/manage/account/publishing/>
+(*Add a new pending publisher* : projet `routeros-client`, propriétaire `jackarten`, dépôt
+`routeros-client`, workflow `publish.yml`, environment `pypi`). Aucun token n'est à stocker.
+
+---
+
+## 6. Compatibilité ascendante
+
+Vérifiée par les tests `TestFactories` (surface publique, signature de `Api.__init__`) et par
+`smoke.py` : tous les symboles, méthodes et paramètres nommés de la v0.5.0 sont présents et
+conservent leur sémantique. `api.queue` reste un attribut assignable (`api.queue = None` fonctionne),
+bien qu'il soit devenu une propriété à création paresseuse.
+
+**Deux changements de comportement volontaires**, tous deux des corrections de bug :
+
+1. **BUG-8** — `split_command()` retire de nouveau les guillemets englobants.
+   Ancien comportement : `RouterOSProtocol.KEEP_QUOTES = True`.
+2. **BUG-1** — un `!trap` est signalé après lecture du `!done` (quelques millisecondes plus tard).
+   L'exception levée est identique ; seul le flux reste désormais synchronisé.
+
+À noter également : `_format_value()` corrige l'envoi des booléens Python (`disabled=True` produisait
+`=disabled=True`, refusé par RouterOS ; il produit désormais `=disabled=yes`). Le code qui passait déjà
+des chaînes `"yes"` / `"true"` n'est pas affecté.

routeros_client-0.6.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Jack Karten
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

routeros_client-0.6.0/MANIFEST.in

@@ -0,0 +1,17 @@
+# Contenu de l'archive source (sdist).
+include README.md
+include CHANGELOG.md
+include LICENSE
+include requirements.txt
+include requirements-core.txt
+include .env.example
+include test_routeros_api.py
+include test_live_router.py
+
+# Exclusions
+exclude *.bak.py
+prune .venv
+prune .github
+global-exclude __pycache__
+global-exclude *.py[cod]
+global-exclude .env