#!/usr/bin/env python
import sys
from os.path import dirname, join, realpath
from os import chdir
try:
from pyromaths import pyromaths
except ImportError:
basedir = dirname(realpath(__file__))
workdir = join(basedir,'src')
sys.path.insert(0, basedir)
from src import pyromaths
chdir(workdir)
pyromaths.main()
Ce code me pose plusieurs problèmes:
- j'ai du mal à comprendre pourquoi le lanceur est si complexe, alors qu'un:
#!/usr/bin/env python from pyromaths import pyromaths pyromaths.main()
suffit en théorie, ainsi qu'en pratique -- à condition que le package pyromaths se trouve dans un dossier nommé "pyromaths" (et non "src" comme aujourd'hui) - Comme le package pyromaths se trouve dans un dossier nommé "src", la déclaration:
from pyromaths import pyromaths
est garantie d'échouer (sauf erreur de ma part). Une exception est donc levée et c'est le bloc "except" qui est systématiquement exécuté. Autrement dit, la norme est l'exécution du "code exception", ce qui semble étrange… - En l'occurence, il y a bien un cas ou la déclaration ci-dessus n'échoue pas: lorsque pyromaths est également installé sur le système (et présent dans le PYTHONPATH). Cela est, si ce n'est problématique, a minima une source d'ambiguïté pour les développeurs: en effet, c'est le package pyromaths installé sur le système qui sera utilisé par défaut, et pas le package pyromaths local (en cours de développement). Le lanceur simplifié ci-dessus a un comportement inverse (et semble-t-il plus désirable): il utilisera le package local, s'il existe, et se rabattra sur le package système dans le cas contraire.
- Cette dernière remarque pourrait expliquer pourquoi src/pyromaths.py contient du code "if __name__==__main__" (voir ce fil): pour un développeur qui aurait également pyromaths installé au niveau système, la seule façon d'exécuter le pyromaths de développement est de lancer src/pyromaths.py, le lanceur normal ayant le comportement "déviant" décrit ci-dessus.