Fix incorrect signatures in .pyi stubs

[piotr-roslaniec]

Type of PR:

• Bugfix

Required reviews:

• 1

What this does:

• Updates the definition of ValidatorMessage in Python bindings
• Replaces former usage in .pyi file, examples, etc.

Issues fixed/closed:

• Fixes AggregatedTranscript() signature incorrect in .pyi #129

Why it's needed:

• To provide correct type hints and concrete types in Python bindings

Notes for reviewers:

• Based on Fix incompatible DkgPublicKey byte serialization #128
• Downstream changes addressed in Fix missing ValidatorMessage stub in Python bindings nucypher-core#65

[codecov-commenter]

Codecov Report

Merging #131 (4aeda15) into fix-dkg-pk-deser-wasm (e516562) will decrease coverage by 0.12%.
The diff coverage is 56.00%.

@@                    Coverage Diff                    @@
##           fix-dkg-pk-deser-wasm     #131      +/-   ##
=========================================================
- Coverage                  78.78%   78.66%   -0.12%     
=========================================================
  Files                         24       24              
  Lines                       4869     4880      +11     
=========================================================
+ Hits                        3836     3839       +3     
- Misses                      1033     1041       +8     

Impacted Files	Coverage Δ
ferveo/src/bindings_python.rs	54.28% <56.00%> (-0.49%)	⬇️

[derekpierre]

If this is will affect nucypher/nucypher-core downstream, we should have a parallel nucypher-core/nucypher open PR before this is merged. Presumably, you can install the updated ferveo module locally for downstream development...?

No use in merging/releasing this code etc. to then catch problems in nucypher-core/nucypher for which a ferveo fix is needed.

[derekpierre]

Although I guess it looks like this goes into a feature branch fix-dkg-pk-deser-wasm before merging into main/development...if that's the case then I stand corrected. Presumably, the downstream changes will be done using this feature branch before the feature branch is merged into main/development.

[piotr-roslaniec]

@derekpierre My plan was to create a PR from development to main with collective changes and then test that PR against nucypher-core. On nucypher-core I would create a similar PR that will get tested against nucypher. I would keep those PRs open to implement feedback from each downstream dependency and only merge them (in reverse order) when the lowermost dependency (nucypher) gets reviewed positively.

Illustrating the idea:
ferveo: main <= development
nucypher-core: main <= ferveo-dev (contains ferveo:development changes)
nucypher: main <= nucypher-core-dev (contains nucypher-core:ferveo-dev changes)

Order of feedback: nucypher => nucypher-core => ferveo
Order of merging: Same

[derekpierre]

Perfect 👌 !

Order of feedback: nucypher => nucypher-core => ferveo
Order of merging: Same

Order of merging the PRs once reviewed and working would be:

1. merge ferveo changes
2. update ferveo dependency, and merge nucypher-core changes, then release
3. update nucypher-core release dependency and merge nucypher

[KPrasch]

👨🏻‍🚀

[derekpierre]

🎸