Tandis que cette question a un python en arrière-plan, la question n'est pas lié à python lui-même, mais plutôt sur les mécanismes d'extension et comment s'inscrire/recherche pour les plugins.
En python, le concept de entrypoints a été introduit par setuptools, et est liée aux métadonnées de python installé distributions (appelés packages dans d'autres systèmes d'emballage).
De ma compréhension, l'une des fonctionnalités fournies par entrypoints est-à-permet à une application de définir un lieu où d'autres peuvent mettre les choses, de sorte que toute application qui souhaitent utiliser un point d'entrée possible d'obtenir la liste des inscrits classes/fonctions. Prenons un exemple:
- Foo définit le point d'entrée "entrypoint1" et de regarder pour les plugins enregistrés sous ce nom.
- Barre d'enregistrer un callable (
Bar.callable) sur la "entrypoint1" point d'entrée. - Aucun script python est capable de liste
Bar.callablecomme l'un des inscrits callables pour "entrypoint1".
Avec setuptools, les applications registres entrypoints au moment de l'installation et de l'information est stockée dans les métadonnées concernant l'emballage, l'appelé .egginfo (qui contiennent généralement des informations sur le nom de la distribution, de ses dépendances, et un peu plus de métadonnées sur l'emballage).
J'ai le sentiment que l'emballage des métadonnées n'est pas le bon endroit pour stocker des informations de ce type, que je ne comprends pas pourquoi cette information est liée à l'emballage.
Je suis curieux d'entendre parler de ces entrypoints/extensions/plugins caractéristiques dans d'autres langues, et en particulier si le concept est lié à des métadonnées et de l'emballage ou pas. Et donc la question est...
Avez-vous des exemples que je devrais regarder? Pourriez-vous expliquer pourquoi les choix de conception ont été fait de cette façon?
Pouvez-vous voir les différentes façons de traiter ce problème? Savez-vous comment ce problème a déjà été résolu dans les différents outils? Quels sont les inconvénients et les avantages de l'actuel python mise en œuvre au détriment des autres?
Ce que j'ai trouvé jusqu'à présent
J'ai trouvé dans les différents projets, un moyen de créer et de distribuer des "plugins", qui sont surtout en prenant soin sur le "comment faire en sorte plugins".
Par exemple, libpeas (le gobject plugin cadre) définit un ensemble de moyens de prolonger un comportement par défaut en spécifiant les plugins. Tout cela est intéressant, je suis juste intéressé par la section "enregistrement et de trouver" (et éventuellement de chargement) en font partie.
Voici quelques-unes de mes découvertes à ce jour:
Libpeas définit ses propres métadonnées de fichier (*.plug-in), qui stocke des informations sur le type de la callable (il est possible d'avoir différents plugins dans différentes langues). L'information principale ici est le nom du module à charger.
Maven ont un design document contenant des informations sur comment les choses est géré là. Maven gère les plugins avec leurs dépendances et les métadonnées de sorte qu'il semble être un endroit intéressant à regarder pour la façon dont ils ont mis les choses.
Comme spécifié dans la documentation, les plugins maven sont à l'aide d'annotations (@goal) sur les classes, qui est ensuite utilisé pour trouver les tous les plugins inscrit avec un @goal. Bien que cette approche est possible dans les langages statiques, il n'est pas dans des langages interprétés, car nous ne savons ce que sont toutes les classes possibles / callables à un moment donné du temps, ce qui peut changer.
Mercurial utilise un fichier de configuration central (~/.hgrc), contenant une cartographie du nom du plugin pour le chemin d'accès il peut être trouvé.
Quelques réflexions plus
Alors que ce n'est pas une réponse à cette question, il est également intéressant de noter comment setuptools entrypoints sont mis en œuvre, et de les comparer en terme de performance, avec la mercurial.
Lorsque vous demandez un particulier point d'entrée avec setuptools, toutes les métadonnées sont lus au moment de l'exécution et la liste est construit de cette façon. Cela veut dire que cette lecture peut prendre un certain temps si vous avez beaucoup de distributions python sur votre chemin. Mercurial sur l'autre côté coder en dur ces informations dans un seul fichier, ce qui signifie que vous devez spécifier le chemin d'accès complet à votre appelable là, puis enregistré callables ne sont pas "découvert", mais "lire" directement à partir du fichier de configuration. Cela permet plus fine de la configuration sur ce que doit être disponible et de ce qui ne devrait pas être et semble plus rapide.
De l'autre côté, comme le python path peut être modifiée lors de l'exécution, cela signifie que callables fournie sur ce chemin devra être vérifié par rapport au chemin d'accès afin de savoir si elles doivent être renvoyées ou pas dans toutes les situations.
Pourquoi entrypoints sont actuellement liées à l'emballage
Il est également intéressant de comprendre pourquoi entrypoints sont liés à l'emballage dans setuptools. La raison principale est qu'il me semble utile que python distributions pouvez enregistrer une partie d'eux-mêmes que l'extension d'un point d'entrée au moment de l'installation: l'installation de moyens aussi de l'inscription de l'entrypoints: pas de besoin d'un supplément d'une étape d'enregistrement.
Bien que cela fonctionne assez bien dans la grande majorité des cas (quand python distributions sont installés) il n'est pas lorsqu'ils ne sont pas installés ou tout simplement pas emballé. En d'autres termes, ce que je comprends, vous ne pouvez pas enregistrer un point d'entrée au moment de l'exécution, sans avoir une .egg-info fichier.
