nccgroup/call_mapDéveloppement actuel de Call Map se déroule sur https://github.com/ajylee/call_map. Call Map est un outil pour naviguer dans les graphes d'appels Python.
.. default-role:: code
Call Map est un outil pour naviguer dans les graphes d'appels en Python, avec l'intention de prendre en charge d'autres langages. Vous trouverez ci-dessous une capture d'écran après avoir exécuté call_map -m toolz, puis cliqué sur certaines fonctions.
.. figure:: docs/UI-clicked-on-function.png
Bien que Call Map soit destiné à aider à acquérir une compréhension générale d'une base de code, il est également tout indiqué pour le traçage des chemins de code, ce qui constitue un enjeu de sécurité important. De nombreux problèmes de sécurité sont révélés en trouvant un chemin de code qui relie les entrées utilisateur à des schémas de codage dangereux.
Voir le billet de blog__ pour plus d'informations.
Call Map est distribué comme un paquet Python pour Python 3.5. Pour installer avec pip3, exécutez::
pip3 install -e .
Notez que certaines distributions Python 3 appellent le gestionnaire de paquets pip, et d'autres l'appellent pip3. Vous devrez donc peut-être remplacer pip3 par pip.
Les commandes ci-dessus devraient installer l'exécutable call_map dans le même chemin que celui où se trouve l'interpréteur Python.
Pour plus de détails et d'autres méthodes, voir INSTALL.rst.
Ouvrez des fichiers pour commencer à explorer::
call_map -f example.py
call_map -f *.py
Vous pouvez également ajouter au chemin de recherche des modules (sys.path)::
call_map -f *.py -p .
Call Map essaiera de résoudre les fichiers en tant que modules chaque fois qu'ils peuvent être trouvés dans le chemin de recherche des modules. Pour plus de documentation sur les arguments de la ligne de commande, call_map -h.
Pour configurer Call Map, définissez la variable d'environnement CALL_MAP_RC_DIRECTORY. Le chemin du fichier de configuration de Call Map sera::
$CALL_MAP_RC_DIRECTORY/call_map_rc.py
Les options de configuration actuelles sont :
open_in_editor(path: pathlib.Path, line: int): si vous définissez cette fonction, elle sera appelée à chaque fois que vous ouvrez un fichier. Par exemple, ce qui suit peut être utilisé pour ouvrir des fichiers dans un serveur Emacs si vous avez appelé server-mode dans une session Emacs en cours::
def open_in_editor(path, line): import subprocess as sbp sbp.call(['emacsclient', '+{}'.format(line), str(path)])
Ce qui suit peut être utilisé pour ouvrir des fichiers dans le serveur GVim si vous avez démarré un serveur GVim avec gvim --servername my_vim_server::
def open_in_editor(path, line): import subprocess as sbp sbp.call(['gvim', '--servername', 'my_vim_server', '--remote', '+{}'.format(line), str(path)])
MULTITHREADING: indique s'il faut utiliser un thread séparé pour l'interface graphique et la recherche dans le graphe d'appels. La valeur par défaut est True. La désactiver est à des fins de débogage.
Il y a quelques particularités dans la conception de l'interface, dues au fait que je ne suis pas arrivé à une meilleure solution ou que le compromis avec une complexité supplémentaire est défavorable.
Les utilisations peuvent sembler apparaître plus d'une fois, mais il s'agit en réalité d'utilisations différentes dans la même portée.
Vous remarquerez peut-être que certaines fonctions intégrées telles que help, id et filter sont ignorées. Voir call_map/config.py dans le code source pour la liste complète des fonctions ignorées.
Si la position à mettre en surbrillance se trouve au début d'un fichier, elle ne sera pas mise en surbrillance. Cela est dû au fait que généralement seuls les modules et les scripts sont positionnés au début de leurs fichiers respectifs.
Certaines particularités sont héritées du backend d'analyse Python jedi.
La portée de recherche des utilisations est l'ensemble des modules qui ont été chargés par le backend jedi. Cela signifie que la portée changera à mesure que vous explorerez de nouveaux modules. Si vous souhaitez inclure explicitement un module dans la portée de recherche, ajoutez-le à la liste initiale des modules à inspecter.
jedi recherche toujours dans sys.path de l'interpréteur, même lorsqu'il n'est pas explicitement inclus. Cependant, il donnera la priorité au sys_path défini par l'utilisateur.
Toutes les mises en garde qui existent pour les backends d'analyse statique s'appliquent également à Call Map. (Pour le moment, seul le backend jedi est intégré à Call Map.)
Le backend jedi pour l'analyse Python ne trouve pas toujours toutes les utilisations. La nature dynamique de Python rend impossible de déterminer toujours la définition d'une fonction par analyse statique. Parfois, jedi résout un appel vers plusieurs fonctions possibles. Par exemple, os.path.abspath dépend de la plateforme. Dans ce cas, call_map répertorie les deux possibilités sous abspath et abspath (2). jedi ne résout pas non plus tous les appels et toutes les utilisations. La documentation de Jedi comporte également une liste de mises en garde__.
__ https://jedi.readthedocs.io/en/latest/docs/features.html#caveats
Parfois, lorsque Jedi lève une erreur en analysant un élément, l'erreur affecte d'autres éléments. Par exemple, lors de la recherche d'utilisations, si Jedi lève une erreur sur une utilisation, les autres utilisations qu'il a trouvées peuvent être irrécupérables (dans Jedi v0.10.0).
