Description
The TUF refactor aims at a more idiomatic use of OOP (see #1112). As such it seems reasonable to implement metadata entity behaviour as instance methods on the corresponding classes.
However, not all users of the metadata model need the same behaviour. For instance, a TUF client is likely to only need Metadata.verify
and read access on all metadata object attributes, but none of the methods to modify attributes, which are needed by a repository library/tool, (e.g. sign
, bump_version
, bump_expiration
, delegate
, add_keys
, add_targets
, etc.).
This question about how to draw the line is especially important if unneeded functionality requires 3rd party dependencies, which we would have to vendor on a client.
Some possible approaches (brain storming):
- Use classes exclusively for attributes (except maybe for methods on sslib's
Metadata
andSigned
classes, such assign
,verify
,canonicalise
) and implement all behaviour on metadata user specific controller classes, e.g.Repository
,Client
(or something likeProject
/Developer
/Workspace
for PEP480. - Use Subclasses, e.g.
RepositoryTargets
,ClientTargets
, etc... - Expose all methods to all users of the model, but handle missing optional dependencies. E.g. raise something like an
UnsupportedLibraryError
if a client callsMetadata.sign
but does not have the underlying optional 3rd-party dependencies (see Revise extra dependency handling secure-systems-lab/securesystemslib#179)
Premise: Find a balance between OOP purism and pragmatism