feat(completion): un nom qui dit ce qu'il fait, et un premier Tab qui répond (0.1.62)

[stephrobert]

Deux issues, un seul geste : installer la complétion.

#134 — le premier Tab ne proposait rien

Reproduit avant de corriger, dans un zsh réel sous pseudo-terminal, avec un
dsoxlab réellement installé et un catalogue à compléter :

$ python3 pty_completion.py <script amont de typer>
  tabulation 1 : MUET
  tabulation 2 : propose

zsh charge le fichier #compdef à la première tabulation et attend qu'il
produise les propositions de cette invocation-là. Le script que typer génère
se contente de définir la fonction, puis de l'enregistrer pour la suite : la
première tabulation ne rend donc rien.

Une ligne suffit, placée après l'enregistrement pour que les deux chemins
marchent :

$ python3 pty_completion.py <script que dsoxlab installe>
  tabulation 1 : propose
  tabulation 2 : propose

C'est une divergence avec l'amont, donc la raison part dans le fichier posé :

compdef _dsoxlab_completion dsoxlab
# ── ajouté par dsoxlab, et pas par typer ──────────────────────────────────────
# zsh autoload ce fichier au PREMIER Tab, et attend qu'il produise les
# propositions de cette invocation-là. Le script amont se contente de définir la
# fonction puis de l'enregistrer pour la suite : la première tabulation ne rend
# donc rien, et la seconde fonctionne. Un Tab muet se lit comme « la complétion
# ne marche pas », et personne ne rappuie pour vérifier.
# Ne pas retirer cette ligne sans rejouer le cas dans un zsh réel.
_dsoxlab_completion "$@"

La divergence ne vaut que pour zsh, et un test le tient : bash source son
script au démarrage, fish le charge par fichier de complétion, ni l'un ni l'autre
ne passe par l'autoload en cause. Leurs scripts restent identiques à ceux de
typer.

#90 — dsoxlab install promettait d'installer l'outil déjà installé

completion install et completion show apparaissent. install reste, prévient
et fait le même travail :

$ DSOXLAB_LANG=fr dsoxlab install
⚠ « dsoxlab install » est déprécié depuis 0.1.62 et sera retiré en 0.3.0.
Utilise « dsoxlab completion install », qui fait la même chose sous un nom qui
le dit. Le wrapper de ~/.local/bin n'est plus écrit : uv tool install et pipx y
posent déjà le leur.
✔ Script de complétion : …/.zfunc/_dsoxlab

$ DSOXLAB_LANG=en dsoxlab install
⚠ `dsoxlab install` is deprecated since 0.1.62 and will be removed in 0.3.0. Use
`dsoxlab completion install`, which does the same thing under a name that says
it. The wrapper in ~/.local/bin is no longer written: `uv tool install` and
`pipx` already put theirs there.

Le wrapper n'est plus écrit du tout. Deux défauts vécus tenaient à ce
fichier, et le retirer les clôt tous les deux :

• un chemin contenant une espace cassait le exec, faute de quoting ;
• surtout, write_text() sur un lien symbolique écrit dans la cible :
  on ne remplaçait pas le lien de uv, on remplaçait son binaire réel par un
  script pointant sur lui-même. Il avait fallu une mutation pour le voir ([P0] Le wrapper écrit par dsoxlab install casse dès que le chemin contient une espace #68).

uv tool install et pipx posent leur lanceur exactement là : le remplacer ne
faisait que défaire ce que leur prochaine mise à jour remettrait.

Les deux tests du wrapper, remplacés et non supprimés

Ils éprouvaient un fichier qui n'existe plus : les garder les rendrait verts sans
rien mesurer. Un test tient désormais la décision (~/.local/bin reste vide,
et la complétion est bien posée), et son docstring garde ce que les deux
précédents avaient appris, piège du lien symbolique compris.

Type of change

• Bug fix ([P3] Le premier Tab d'une session ne propose rien, et se lit comme « la complétion ne marche pas » #134)
• New feature ([P2] Déprécier dsoxlab install au profit de dsoxlab completion install #90)
• Deprecation ([P2] Déprécier dsoxlab install au profit de dsoxlab completion install #90)

Checklist

Always

• uv run ruff check src/dsoxlab tests tests_e2e fuzz scripts — All checks passed!
• uv run mypy src/dsoxlab — no issues in 60 source files
• uv run pytest — 597 passed ; tests_e2e — 16 passed
• Domain-agnostic ; aucun chemin personnel
• Vérifié à l'écran dans les deux langues, et sous pseudo-terminal

When behavior changes

• CHANGELOG EN + FR ; version 0.1.62 ; uv.lock régénéré
• Le cycle de suppression est annoncé : avertissement en 0.1.62, retrait
  en 0.3.0, dans le CHANGELOG, dans le message et dans le fullhelp

When a command or option is added, removed or changed

• Aide CLI + i18n EN et FR + fullhelp EN et FR, simultanément
• Le fullhelp ne décrit plus install comme la façon d'installer l'outil
• Table des commandes des README régénérée par scripts/generer-doc.py

When .github/workflows/ is touched — N/A

When the declarative contract changes — N/A

Ce que le test unitaire ne prouve pas, et pourquoi il existe quand même

L'issue est explicite : un appel direct au mécanisme de complétion ne traverse
pas la couche en cause. La preuve est donc la vérification sous
pseudo-terminal, ci-dessus. Le test unitaire a un autre rôle, complémentaire :
empêcher que la ligne disparaisse d'un coup d'éditeur, ce qu'aucun test de
complétion ne verrait. Il vérifie aussi qu'elle reste après l'enregistrement,
et que la raison part bien dans le fichier livré.

Un bruit relevé en chemin

tests/test_services.py::test_deux_services_se_joignent_par_leur_nom et
test_post_start_execute_vraiment_dans_le_conteneur sont instables sous
charge : ils ont échoué pendant que d'autres conteneurs tournaient, et repassent
seuls comme en suite complète. Ils dépendent de vrais conteneurs Docker et rien
ici n'y touche. J'ouvre une issue séparée plutôt que de le laisser sous le tapis.

Related issues

Closes #90
Closes #134
Clôt le cycle ouvert par #67 et #68, dont cette PR retire la cause commune.

🤖 Generated with Claude Code