Cette section options.entry_points définit deux exécutables installés par le package, pipinfo et pippin, qui pour cet exemple pointent tous deux vers le module main du code source. Ce sont donc des alias, mais ils auraient aussi bien pu pointer vers des modules différents (tes différents fichiers).
Même si tu restais avec des alias, tu as toujours la méthode Unix/C classique qui marche tout aussi bien en Python, qui consiste à faire varier le comportement de ton programme en fonction du nom sous lequel il a été appelé (récupéré avec les arguments de la ligne de commande).
Tu peux aussi isoler le code commun dans une bibliothèque comme je le fais avec mon package libpnu et le référencer par une dépendance de package :
[options]install_requires=pnu-libpnu
Quand tu n'as pas de dépendances croisées, tu peux aussi faire des méta-paquets qui ne font que faire une collection d'autres paquets comme je le fais pour mon projet PNU.
Je pense que tu devrais trouver ton bonheur avec l'une de ces approches.
[^] # Re: Merci, j’espère résoudre mon problème !
Posté par HubTou (site web personnel) . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 3.
Si j'ai bien compris ton problème, tu as 4 ou 5 commandes avec des dépendances croisées résultant du split de ton code source.
C'est tout à fait gérable par un package Python.
Dans l'exemple que j'ai donné plus haut, jette un oeil au fichier setup.cfg. Tu y trouveras la section suivante :
Cette section options.entry_points définit deux exécutables installés par le package, pipinfo et pippin, qui pour cet exemple pointent tous deux vers le module main du code source. Ce sont donc des alias, mais ils auraient aussi bien pu pointer vers des modules différents (tes différents fichiers).
Même si tu restais avec des alias, tu as toujours la méthode Unix/C classique qui marche tout aussi bien en Python, qui consiste à faire varier le comportement de ton programme en fonction du nom sous lequel il a été appelé (récupéré avec les arguments de la ligne de commande).
Tu peux aussi isoler le code commun dans une bibliothèque comme je le fais avec mon package libpnu et le référencer par une dépendance de package :
Quand tu n'as pas de dépendances croisées, tu peux aussi faire des méta-paquets qui ne font que faire une collection d'autres paquets comme je le fais pour mon projet PNU.
Je pense que tu devrais trouver ton bonheur avec l'une de ces approches.