Jussi Kukkonen

I guess I was assuming 0 is clearly "not a real version number", but you are probably correct that's not obvious.

> I can see how your proposal is convenient for your particular use case I notice I didn't respond to this. I might be to blame for the design but...

Current error is something completely different ``` Traceback (most recent call last): File "C:\hostedtoolcache\windows\Python\3.10.9\x64\lib\runpy.py", line 196, in _run_module_as_main return _run_code(code, main_globals, None, File "C:\hostedtoolcache\windows\Python\3.10.9\x64\lib\runpy.py", line 86, in _run_code exec(code, run_globals)...

That looks like a good explanation... I'm unsure what to suggest as a fix though: * coveralls-python has issues filed that look like the same thing already, but it's not...

The tests expect tuf to be installed, and will test that installed version. I'm not sure if that makes sense... but that's how it currently works. The second error implies...

I'm hesitating just closing this. It was likely a "user error" but... The failure mode is so weird if someone does not install the source dir as editable that I'm...

This should include the uploader as well. The basic end-to-end test for all examples would be: 1. run `repository/repo` in one process 1. wait until http server is up 1....

> Based on the latest TUF spec, TUF uses RSA PSS instead of PKCS#1 Note that these are just examples essentially, definitely not an exhaustive list of the only schemes...

Just as an idea... I would love a keytype support test in tuf-conformance: https://github.com/theupdateframework/tuf-conformance/issues/159 -- implementing that would give you keytype test coverage "for free" in go-tuf and should not...

Issues seem to be from this, looks good: > [flake8-blind-expect] Allow raise from in BLE001