[Distutils] Adding entry points into Distutils ?
wheatix at gmail.com
Thu May 7 03:38:47 CEST 2009
> 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
console_scripts using zc.recipe.egg. This use-case only needs
entry_points. Once a distribution's entry_points are made available,
entirely up to the application installer (eg. zc.recipe.egg) as to
done with the entry_point information.
For example, let's say that I have a Python project which I want to
zest.releaser for. The entry_points for this package is:
'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
parts = releaser
recipe = zc.recipe.egg
eggs = zest.releaser
Where the zc.recipe.egg recipe will turn all 'console_scripts'
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
difference between asking a distribution what entry_points it provides
(discovery) and deciding what configuration or actions to take based
information (activation or script generation). Also, as for discovery,
use-case only requires discovery on a per-distribution basis, it
need a 'iterate over all distribution's entry_points installed in some
Also, using console_scripts for entry_points means that there is a
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?
More information about the Distutils-SIG