|
2 | 2 | PluginManager, basic initialization and tracing.
|
3 | 3 |
|
4 | 4 | pluggy is the cristallized core of plugin management as used
|
5 |
| -by some 150 plugins for pytest. The current plan is to integrate |
6 |
| -it into some other projects and take it from there. Pluggy uses semantic |
7 |
| -versioning. Breaking changes are only foreseen for Major releases |
8 |
| -(incremented X in "X.Y.Z"). If you want to use pluggy in your project |
9 |
| -you should thus use a dependency restriction like "pluggy>=0.1.0,<1.0" |
10 |
| -to avoid surprises. |
| 5 | +by some 150 plugins for pytest. |
| 6 | +
|
| 7 | +Pluggy uses semantic versioning. Breaking changes are only foreseen for |
| 8 | +Major releases (incremented X in "X.Y.Z"). If you want to use pluggy in |
| 9 | +your project you should thus use a dependency restriction like |
| 10 | +"pluggy>=0.1.0,<1.0" to avoid surprises. |
11 | 11 |
|
12 | 12 | pluggy is concerned with hook specification, hook implementations and hook
|
13 |
| -calling. For any given hook specification a hook call calls up to N implementations. |
| 13 | +calling. For any given hook specification a hook call invokes up to N implementations. |
14 | 14 | A hook implementation can influence its position and type of execution:
|
15 | 15 | if attributed "tryfirst" or "trylast" it will be tried to execute
|
16 | 16 | first or last. However, if attributed "hookwrapper" an implementation
|
17 | 17 | can wrap all calls to non-hookwrapper implementations. A hookwrapper
|
18 |
| -can execute some code ahead and after the execution of other hooks. |
| 18 | +can thus execute some code ahead and after the execution of other hooks. |
19 | 19 |
|
20 | 20 | Hook specification is done by way of a regular python function where
|
21 | 21 | both the function name and the names of all its arguments are significant.
|
22 | 22 | Each hook implementation function is verified against the original specification
|
23 | 23 | function, including the names of all its arguments. To allow for hook specifications
|
24 |
| -to evolve over the livetime of a project, we allow hook implementations to |
25 |
| -accept less arguments. We can thus add new arguments and semantics to |
| 24 | +to evolve over the livetime of a project, hook implementations can |
| 25 | +accept less arguments. One can thus add new arguments and semantics to |
26 | 26 | a hook specification by adding another argument typically without breaking
|
27 | 27 | existing hook implementations.
|
28 | 28 |
|
|
0 commit comments