Skip to content

Fix type annotations #944

Open
Open
@jku

Description

securesystemslib users can't use type checkers on the code that calls securesystemslib because we don't mark the library as typed (by adding py.typed file). We should do that:

  • Almost all of the new API is well type annotated already
  • Some older modules are not and I'm not too concerned if e.g. _gpg is not properly annotated even when we claim that the library is annotated
  • At least hash is a core module though and should be annotated. It's tricky to do though and we might want to do simplify hashing #943 first

For reference, this is the list python-tuf would see currently:

tuf/api/_payload.py:671: error: Call to untyped function "digest" in typed context  [no-untyped-call]
tuf/api/_payload.py:675: error: Call to untyped function "digest_fileobject" in typed context  [no-untyped-call]
tuf/api/_payload.py:739: error: Call to untyped function "digest" in typed context  [no-untyped-call]
tuf/api/_payload.py:742: error: Call to untyped function "digest_fileobject" in typed context  [no-untyped-call]
tuf/api/_payload.py:1153: error: Call to untyped function "digest" in typed context  [no-untyped-call]
tuf/api/_payload.py:1272: error: Call to untyped function "digest" in typed context  [no-untyped-call]
tuf/api/metadata.py:236: error: Call to untyped function "FilesystemBackend" in typed context  [no-untyped-call]
tuf/api/metadata.py:337: error: Call to untyped function "FilesystemBackend" in typed context  [no-untyped-call]

So essentially two issues:

  • looks like FilesystemBackend constructor just needs a return type
  • the hash.digest*() issues are more annoying and might be a lot easier to fix if we simplify hashing #943

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions