[PR] Refactor resources & registries & filters — for type-hinting

[kopf-archiver]

A pull request by nolar at 2019-10-01 20:01:49+00:00
Original URL: zalando-incubator/kopf#195
Merged by nolar at 2019-10-05 08:42:38+00:00

Refactor Resources & Registries & Filters to prepare for the overall type-hinting.

Issue : #194

Description

All the changes are done as a preparation for the throughout type-hinting in the code base. Resolving the cyclic imports becomes important. The whole refactoring is split into few PRs (one per concept) for ease of review.

Resources are used all over the code, e.g. in the @kopf.on handlers, and watchers, etc. They server as an id of the resource. But they are defined in the same module as the registries, so we have to import registries too — even when they are not needed.

The registries, in turn, are complicated enough to import other modules, thus causing the cyclic dependencies. This becomes very visible when the type-hinting is added, as the modules must be imported to have the types for annotations.

Status storage is moved into the reactor for two reasons: (1) it actively uses Handler from registries (a lower-level "struct" module depends on the upper-level "reactor" module); (2) this is actually the "reactor's state", i.e. part of the reacting to the event, and it is not reused as a general structure.

Filters are moved to be together with the registries to solve the cyclic import via the Handler class (filters require Handler, import registries, which in turn imports filters). They are not reused anywhere in the framework, and semantically are part of the registries (or maybe of one of them).

Types of Changes

• Refactor/improvements

There are no behavioural changes. Only the code refactoring. The tests show that all the protocols and interfaces are kept in place — except for the imports of the internal modules (not exposed via kopf/__init__.py).