Entry points are a simple way for distributions to “advertise” Python objects (such as functions or classes) for use by other distributions. Extensible applications and frameworks can search for entry points with a particular name or group, either from a specific distribution or from all active distributions on sys.path, and then inspect or load the advertised objects at will.
Entry points belong to “groups” which are named with a dotted name similar to a Python package or module name. For example, the setuptools package uses an entry point named distutils.commands in order to find commands defined by distutils extensions. setuptools treats the names of entry points defined in that group as the acceptable commands for a setup script.
In a similar way, other packages can define their own entry point groups, either using dynamic names within the group (like distutils.commands), or possibly using predefined names within the group. For example, a blogging framework that offers various pre- or post-publishing hooks might define an entry point group and look for entry points named “pre_process” and“post_process” within that group.
To advertise an entry point, a project needs to use setuptools and provide an entry_points argument to setup() in its setup script, so that the entry points will be included in the distribution’s metadata. For more details, see the setuptools documentation. (XXX link here to setuptools)
Each project distribution can advertise at most one entry point of a given name within the same entry point group. For example, a distutils extension could advertise two different distutils.commands entry points, as long as they had different names. However, there is nothing that prevents differentprojects from advertising entry points of the same name in the same group. In some cases, this is a desirable thing, since the application or framework that uses the entry points may be calling them as hooks, or in some other way combining them. It is up to the application or framework to decide what to do if multiple distributions advertise an entry point; some possibilities include using both entry points, displaying an error message, using the first one found in sys.path order, etc.
例如在script里面经常会看到用pkg_resources.run_script或者pkg_resources.load_entry_point来执行命令行,这就是定义了script的一个框架,当安装新的包的时候,只要setup.py指定好entry_points,指明从哪里开始调用函数或者模块(上面举了distutils.commands例子),然后 load_entry_point或者run_script就可以了。这样做的好处是将调用和具体实现分离开,只需要指明入口entry就可以了。
1 #!D:\develop\Python27\python.exe
2 # EASY-INSTALL-ENTRY-SCRIPT: 'pastescript==1.7.5','console_scripts','paster'
3 __requires__ = 'pastescript==1.7.5'
4 import sys
5 from pkg_resources import load_entry_point
6
7 if __name__ == '__main__':
8 sys.exit(
9 load_entry_point('pastescript==1.7.5', 'console_scripts', 'paster')()
10 )
iter_entry_points(group, name=None)
第一个参数定向到site-packages/pastescript-1.7.5-py2.7.egg ,然后搜索EGG-INFO/entry_points.txt,里面有两行定义了,这个entry_point的名称和位置
[console_scripts]
paster=paste.script.command:run
console_scripts就是group名称
paster就是name参数,实际指向paste.script.command模块的run函数
再举一个这届pycon大会赖永浩的ppt中例子:
#setup.py
entry_points="""
# -*- Entry points: -*-
[qipaionweb.games]
doudizhu = doudizhu.game_impl:GameImpl
"""
定义entry_points的group是qipaionweb.games,也就是qipaionweb.games下面的games包
然后定义一个函数
def get_game_impl_class(game_name):
group = 'qipaionweb.games'
prj = game_name
return pkg_resources.load_entry_point(prj, group, game_name)
prj 就是第三方开发的游戏包以上面setup.py的doudizhu为例
统一的group名是qipaionweb.games,对应setup.py中[qipaionweb.games]
game_name 就是具体游戏名,对应setup.py中doudizhu=
函数返回的是doudizhu.game_impl:GameImpl ,即doudizhu包里面game_impl模块的GameImpl类,GameImpl是游戏的具体实现。
这个设计就是要把game_interface和game_impl分离,game_impl实现game_interface,让第三方开发插件一样开发游戏应用。