Releases: gsmecher/tuberd
Releases · gsmecher/tuberd
v0.17
v0.16
What's Changed
- Build helper get_include() function by @arahlin in #32
- Refactor server code into a compiled module with a python entry point by @arahlin in #33
- Migrate request handling to python by @arahlin in #34
- Create asyncio Future within running event loop by @arahlin in #36
- Bring serial API in line with async using requests-futures by @arahlin in #37
- Schema check crashland by @gsmecher in #39
- Correct python extension paths for pip install by @arahlin in #38
- Common API for tests of SimpleTuberObject and TuberObject by @arahlin in #40
- Add a --validate option to tuberd server by @arahlin in #41
- Expose tuber.server.main() for user API by @arahlin in #43
- Remove dependency on fmt by @cnweaver in #42
- Dynamic object attributes by @arahlin in #35
- Some minor fixes for TuberContainer objects by @arahlin in #45
- Drop --verbose option from server by @arahlin in #46
- Workflow for creating a client-only package by @arahlin in #44
- Disable file server endpoint by default by @arahlin in #47
- Fix client package publish step by @arahlin in #48
Full Changelog: v0.15...v0.16
v0.15
v0.14
v0.13
-
A "simple" (non-asyncio) client now lives alongside the asyncio client. The
points of entry for these are "resolve" and "resolve_simple". They are
approximately API-compatible, but the non-asyncio version entirely avoids
async code style (async def / await / ...). -
Multiple calls (using a Context or SimpleContext) can now optionally continue
after errors, using the continue_on_error flag. When this is True, all calls
in a Context/SimpleContext run to completion even if some of them fail.
The default behaviour remains the same - when continue_on_error is False,
server-side execution proceeds in sequence and halts at the first call that
encounters an error.