其他语言/应用程序中python/setuptools入口点(扩展)的替代实现 [英] Alternative implementations of python/setuptools entry points (extensions) in other languages/applications

问题描述

尽管此问题具有python后端，但不与python本身相关，而是与扩展机制以及如何注册/查找插件有关.

While this question has a python backend, the question is not tied to python itself, but rather about extension mechanisms and how to register/lookup for plugins.

在python中，入口点的概念由setuptools引入，并与已安装的python发行版的元数据(在其他打包系统中称为包)相关联.

In python, the concept of entrypoints was introduced by setuptools, and is tied to the metadata of installed python distributions (called packages in other packaging systems).

据我了解，入口点提供的功能之一是允许应用程序定义其他人可以放东西的地方，因此任何希望使用入口点的应用程序都可以在那里获取已注册的类/函数的列表.让我们举个例子:

As of my understanding, one of the features provided by entrypoints is to allows an application to define a place where others can put things in, so any application wanting to use an entrypoint can get a list of registered classes/functions there. Let's take an example:

• Foo定义入口点"entrypoint1"，并查找以此名称注册的插件.
• 在"entrypoint1"入口点上注册可调用(Bar.callable).
• 然后，任何python脚本都可以将Bar.callable列为"entrypoint1"的已注册可调用项之一.

• Foo defines the entrypoint "entrypoint1" and look for plugins registered under this name.
• Bar register a callable (Bar.callable) on the "entrypoint1" entrypoint.
• Any python script is then able to list Bar.callable as one of the registered callables for "entrypoint1".

使用setuptools，应用程序在安装时注册入口点，并将信息存储在与打包相关的元数据中，称为.egginfo(通常包含有关分发名称，其依赖项的信息以及有关打包的其他元数据).

With setuptools, applications registers entrypoints at install time and the information is stored in metadata related to packaging, called .egginfo (which usually contain information about the distribution name, its dependencies, and some more metadata about packaging).

我觉得打包元数据不是存储此类信息的正确位置，因为我不知道为什么这些信息与打包相关.

I have the feeling that packaging metadata is not the right place to store this kind of information, as I don't get why this information is tied to packaging.

我很想知道其他语言的此类入口点/扩展/插件功能，尤其是如果该概念是否与元数据和打包相关的话.所以问题是……

I'm curious to hear about such entrypoints/extensions/plugins features in other languages, and especially if the concept is tied to metadata and packaging or not. And so the question is…

您有我应该看的例子吗?您能解释一下为什么这样做出设计选择吗?

您能看到其他解决此问题的方法吗?您知道用不同的工具已经解决了这个问题吗?当前python实现相对于其他实现的不利之处和优势是什么?

Can you see different ways to handle this problem? Do you know how this problem has already been solved in different tools? What are the downsides and the advantages of the current python implementation over others?

到目前为止我发现的内容

What I've found so far

我在不同的项目中找到了一种创建和分发插件"的方法，尤其要注意我们如何制作插件".

I've found in different projects, a way to create and to distribute "plugins", which are especially taking care about the "how do we make plugins".

例如， libpeas (gobject插件框架)定义了一组扩展默认值的方法通过指定插件的行为.尽管这很有趣，但我只是对其中的注册和查找"(并最终加载)部分感兴趣.

For instance, libpeas (the gobject plugin framework) defines a set of ways to extend a default behavior by specifying plugins. While this is interesting, I am just interested by the "registering and finding" (and eventually loading) part of it.

到目前为止，这是我的一些发现:

Here are some of my findings so far:

Libpeas定义其自己的元数据文件(* .plugin)，用于存储有关可调用类型的信息(可能有不同语言的不同插件).这里的主要信息是要加载的模块的名称.

Libpeas defines its own metadata file (*.plugin), which stores information about the type of the callable (it is possible to have different plugins in different languages). The main information here is the name of the module to load.

Maven具有设计文档包含有关在那里如何管理物料的信息. Maven通过其依赖项和元数据来管理插件，因此看起来似乎是一个有趣的地方，可以查找

Maven have a design document containing information on how stuff is managed there. Maven manages plugins with their dependencies and metadata so it seems like an interesting place to look for how they implemented things.

根据其文档中的说明， maven插件正在使用注释(@goal)，然后用于查找在特定@goal中注册的所有插件.尽管这种方法在静态语言中是可行的，但在解释语言中却不是，因为我们只知道在给定的时间点上所有可能的类/可调用对象是什么，并且可能会发生变化.

As specified in their documentation, maven plugins are using annotations (@goal) on the classes, which is then used to find all the plugins registered with a particular @goal. While this approach is possible in static languages, it is not in interpreted languages as we only know what are all the possible classes / callables at one given point of the time, which may change.

Mercurial使用包含映射的中央配置文件(~/.hgrc)插件名称到可以找到它的路径.

Mercurial uses a central configuration file (~/.hgrc), containing a mapping of the name of the plugin to the path it can be found.

更多想法

虽然这不能解决这个问题，但有趣的是要注意setuptools入口点是如何实现的，以及它们在性能方面与普通工具的比较.

While that's not an answer to this question, it is also interesting to note how setuptools entrypoints are implemented, and how they compare in term of performance, with the mercurial ones.

当您使用setuptools询问特定的入口点时，在运行时读取所有元数据，并以此方式构建列表.这意味着，如果您的路径上有很多python发行版，则此阅读可能要花一些时间.另一方面，Mercurial将这些信息 hardcode 整合到一个文件中，这意味着您必须在此处指定可调用对象的完整路径，然后才可以从配置中发现"已注册的可调用对象，而不必直接读取"已注册的可调用对象文件.这样就可以对应该提供的内容和不应该提供的内容进行更精细的配置，而且看起来更快.

When you ask for a particular entry point with setuptools, all the metadata are read at run time and a list is built that way. This means this reading can take some time if you have a lot of python distributions on your path. Mercurial on the other side hardcode this information into a single file, which means you have to specify the complete path to your callable there, then registered callables are not "discovered" but "read" directly from the configuration file. This allows finer grained configuration on what's should be available and what should not be and seems faster.

另一方面，由于可以在运行时更改python路径，因此这意味着必须对照该路径检查以这种方式提供的可调用对象，以便知道在所有情况下是否应返回它们.

On the other side, as the python path can be changed at runtime, this means that callables provided on such a way would have to be checked against the path in order to know if they should be returned or not in all situations.

为什么当前入口点与包装相关

理解入口点为何与setuptools中的包装相关联也很有趣.主要原因是python发行版可以在安装时注册自己的一部分作为扩展入口点，这似乎很有用:然后安装意味着也注册了入口点:不需要额外的注册步骤.

It is also interesting to understand why entrypoints are tied to packaging in setuptools. The main reason is that it seems useful that python distributions can register part of themselves as extending an entrypoint at installation time: then installing means also registering the entrypoints: no need for an extra registration step.

虽然在大多数情况下(当实际安装python发行版时)效果很好，但在未安装或未打包时却没有.换句话说，据我了解，没有.egg-info文件，就无法在运行时注册入口点.

While this works fairly well in a large majority of cases (when python distributions are actually being installed) it doesn't when they are not installed or simply not packaged. In other words, from what I understand, you can't register an entrypoint at runtime, without having an .egg-info file.

推荐答案

作为一种可能的想法，您可以查看 Eclipse 的插件系统管理.对于您的具体情况，这可能是过大的决定，但绝对是灵感的来源.

as one of possible ideas, you can look at OSGi concept, that is used for plugin system management of Eclipse. It could be overkill for your specific case, but definitely the source of inspiration.

这篇关于其他语言/应用程序中python/setuptools入口点(扩展)的替代实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！