There are *many* benefits of adding entry points into Distutils. In fact, adding a plugin system in there, will help make the commands more extendable and therefore will help us in the long term to remove things out of Distutils.
So any strong opinion against them ?
If not, I'll add a section in PEP 376 - and the first use case I can see is having a pluggable way to extend the list of files contained in .egg-info.
The work to be done would be to extract entry points from pkg_resources (the discovery work that consists of looking for entry_points.txt files will be covered by the APIs already described in that PEP) This is not hard.
Yes, I'd like to see entry_points added to Distutils! I'll also mention my most common use-case for using entry_points is installing console_scripts using zc.recipe.egg. This use-case only needs discovery of entry_points. Once a distribution's entry_points are made available, it's entirely up to the application installer (eg. zc.recipe.egg) as to what is done with the entry_point information. For example, let's say that I have a Python project which I want to use zest.releaser for. The entry_points for this package is: entry_points={ 'console_scripts': [ 'release = zest.releaser.release:main', 'prerelease = zest.releaser.prerelease:main', 'postrelease = zest.releaser.postrelease:main', 'fullrelease = zest.releaser.fullrelease:main', 'longtest = zest.releaser.longtest:main', 'lasttagdiff = zest.releaser.lasttagdiff:main'], } Then I can use buildout to install this package into a project's deployment with: [buildout] parts = releaser [releaser] recipe = zc.recipe.egg eggs = zest.releaser Where the zc.recipe.egg recipe will turn all 'console_scripts' entry_points into scripts in the ./bin directory. Which I find pretty nice :) Anyways, I'm mentioning this use-case just to re-iterate that there is a difference between asking a distribution what entry_points it provides (discovery) and deciding what configuration or actions to take based on that information (activation or script generation). Also, as for discovery, this use-case only requires discovery on a per-distribution basis, it doesn't need a 'iterate over all distribution's entry_points installed in some location' feature. Also, using console_scripts for entry_points means that there is a second way of specifying scripts, since Distutils already has the 'scripts' metadata field. I would say that the 'scripts' field should then be deprecated, but perhaps there are reason's beyond breaking backwards compatability for keeping that field around?