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