> 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?
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
