blob: fd333574b584343c7c98d829c4d8742f2ca12d64 [file] [log] [blame]
Éric Araujo823759e2011-06-04 18:46:25 +02001.. TODO integrate this in commandref and configfile
2
Éric Araujo3a9f58f2011-06-01 20:42:49 +02003=============
4Command hooks
5=============
6
7Packaging provides a way of extending its commands by the use of pre- and
8post- command hooks. The hooks are simple Python functions (or any callable
9objects) and are specified in the config file using their full qualified names.
10The pre-hooks are run after the command is finalized (its options are
11processed), but before it is run. The post-hooks are run after the command
12itself. Both types of hooks receive an instance of the command object.
13
Éric Araujo823759e2011-06-04 18:46:25 +020014See also global setup hooks in :ref:`packaging-setupcfg`.
15
16
Éric Araujo3a9f58f2011-06-01 20:42:49 +020017Sample usage of hooks
18=====================
19
20Firstly, you need to make sure your hook is present in the path. This is usually
21done by dropping them to the same folder where `setup.py` file lives ::
22
23 # file: myhooks.py
24 def my_install_hook(install_cmd):
25 print "Oh la la! Someone is installing my project!"
26
27Then, you need to point to it in your `setup.cfg` file, under the appropriate
28command section ::
29
30 [install_dist]
31 pre-hook.project = myhooks.my_install_hook
32
33The hooks defined in different config files (system-wide, user-wide and
34package-wide) do not override each other as long as they are specified with
35different aliases (additional names after the dot). The alias in the example
36above is ``project``.