Ale*_*eau 49 python plugins packaging
虽然这个问题有一个python后端,但问题并不是与python本身有关,而是与扩展机制以及如何注册/查找插件有关.
在python中,入口点的概念是由setuptools引入的,并且与已安装的python发行版的元数据相关联(在其他包装系统中称为包).
根据我的理解,入口点提供的功能之一是允许应用程序定义其他人可以放置内容的位置,因此任何想要使用入口点的应用程序都可以获得已注册的类/函数列表.我们来举个例子:
Bar.callable在"entrypoint1"入口点上注册callable().Bar.callable列为"entrypoint1"的已注册callables之一.使用setuptools,应用程序在安装时注册入口点,信息存储在与打包相关的元数据中,称为.egginfo(通常包含有关分发名称,其依赖关系以及一些有关打包的元数据的信息).
我觉得包装元数据不是存储此类信息的正确位置,因为我不明白为什么这些信息与包装有关.
我很想知道其他语言中的入口点/扩展/插件功能,特别是如果这个概念与元数据和包装有关.所以问题是......
你有我应该看的例子吗？你能解释为什么设计选择是这样做的吗？
你能看到解决这个问题的不同方法吗？你知道这个问题在不同的工具中是如何解决的吗？当前python实现的缺点和优势是什么？
到目前为止我发现了什么
我在不同的项目中发现了一种创建和分发"插件"的方法,它们特别关注"我们如何制作插件".
例如,libpeas(gobject插件框架)定义了一组通过指定插件来扩展默认行为的方法.虽然这很有趣,但我只对"注册和查找"(并最终加载)部分感兴趣.
以下是我目前的一些调查结果:
Libpeas定义了自己的元数据文件(*.plugin),它存储有关可调用类型的信息(可以使用不同语言的不同插件).这里的主要信息是要加载的模块的名称.
Maven有一个设计文档,其中包含有关如何管理内容的信息.Maven管理具有依赖项和元数据的插件,因此它似乎是一个有趣的地方,可以查找它们如何实现的东西.
正如他们的文档中所指出的那样,maven插件正在@goal对类使用annotations(),然后用于查找使用特定注册的所有插件@goal.虽然这种方法在静态语言中是可行的,但它不是在解释语言中,因为我们只知道在给定时间点所有可能的类/可调用内容,这可能会改变.
Mercurial使用中央配置文件(~/.hgrc),其中包含插件名称到可以找到的路径的映射.
更多的想法
虽然这不是这个问题的答案,但有趣的是要注意如何实现setuptools入口点,以及它们如何在性能方面与多变的那些进行比较.
当您使用setuptools请求特定入口点时,将在运行时读取所有元数据,并以此方式构建列表.这意味着如果你的路径上有很多python发行版,这个读取可能需要一些时间.另一方面,Mercurial 将此信息硬编码到单个文件中,这意味着您必须指定可调用的完整路径,然后注册的callables不会被"发现",而是直接从配置文件中"读取".这允许对应该可用的内容进行更细粒度的配置,哪些内容不应该更好并且看起来更快.
另一方面,由于python路径可以在运行时更改,这意味着必须根据路径检查以这种方式提供的callable,以便知道是否应该在所有情况下返回它们.
为什么入口点目前与包装有关
了解为什么入口点与setuptools中的包装相关联也很有趣.主要原因是python发行版在安装时扩展入口点可能会注册其中一部分似乎很有用:然后安装意味着还要注册入口点:不需要额外的注册步骤.
虽然这在大多数情况下(当实际安装python发行版时)工作得相当好,但是当它们没有安装或者根本没有打包时就不会这样.换句话说,根据我的理解,如果没有.egg-info文件,则无法在运行时注册入口点.