Vous aimez pdb parce que c’est cool. Et vous adorez pdbpp parce que c’est trop cool.
Mais parfois vous n’avez pas accès à une console sur votre process : il est derrière un nginx, ou même sur une machine distante.
rpdb vient résoudre ce problème en lançant un serveur telnet qui donne accès à votre debugger.
pip install rpdb |
Puis :
import rpdb; rpdb.set_trace() |
Et après vous prenez votre client telnet favoris, et vous accédez à votre débugger :
telnet 127.0.0.1 4444 |
Bien entendu, si vous êtes à distance, remplacez 127.0.0.1 par l’ip de la machine. Le port est configurable également :
import rpdb debugger = rpdb.Rpdb(port=12345) debugger.set_trace() |
Et derrière, ça lance pdb, donc pdbpp est lancé automatiquement si il est installé. Joie.
Il y a aussi WDB qui est pas mal cool pour le debuging distant via une interface web https://github.com/Kozea/wdb
Hello, quel est l’intêret par rapport à configurer une connection ssh sur le serveur?
Où alors j’ai loupé qqch?
Le fait d’avoir SSH ne veut pas dire que tu as accès au process dans la console. Si ton processus est lancé via supervisor, daemonisé, ou est un sous worker d’un truc, tu n’a pas de console.
En parlant de workers, celery fournit rdb qui fait la même chose. J’ai toujours trouvé dommage qu’ils ne l’aient pas sorti de celery pour en faire un truc standalone, C’est une bonne chose que quelqu’un y ait pensé.
Pdbpp n’est pas installable en python3 (en tout cas par sur pypi) : je l’ai remplacé par pubdb.
pourquoi pas winpdb et rpdb2 ?
voir la liste des debuggers python: https://wiki.python.org/moin/PythonDebuggingTools
Est-ce que le titre de l’article est “ne pas pas utiliser winpdb et rpdb2″ ?
Si je poste un article sur Vi, tu vas me proposer emacs ?