A zest.releaser entrypoint gets passed a data dictionary and that’s about it. You can do tasks like generating documentation. Or downloading external files you don’t want to store in your repository but that you do want to have included in your egg.
Every release step (prerelease, release and postrelease) has three points where you can hook in an entry point:
For the release step it made sense to create one extra entry point:
Note that an entry point can be specific for one package (usually the package that you are now releasing) or generic for all packages. An example of a generic one is gocept.zestreleaser.customupload, which offers to upload the generated distribution to a chosen destination (like a server for internal company use). If your entry point is specific for the current package only, you should add an extra check to make sure it is not run while releasing other packages; something like this should do the trick:
def my_entry_point(data):
if data['name'] != 'my.package':
return
...
An entry point is configured like this in your setup.py:
entry_points={
#'console_scripts': [
# 'myscript = my.package.scripts:main'],
'zest.releaser.prereleaser.middle': [
'dosomething = my.package.some:some_entrypoint',
]},
Replace prereleaser and middle in zest.releaser.prereleaser.middle with prerelease/release/postrelease and before/middle/after where needed.
See the setup.py of zest.releaser itself for some real world examples.
You’ll have to make sure that the zest.releaser scripts know about your entry points, for instance by placing your egg (with entry point) in the same zc.recipe.egg section in your buildout as where you placed zest.releaser. Or, if you installed zest.releaser globally, your egg-with-entrypoint has to be globally installed, too.
Your entry point gets a data dictionary: the items you get in that dictionary are documented below. Some comments about them: