| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This tweaks the APIs to return a dict in cases where we know
that we are getting a result, and to return an ArtiRpcResponse
in cases where we don't know what kind of response we're getting.
It also expands our Error objects to support decoding.
Rationale: everybody who is using this libaray will want to
decode the json objects that they receive. By doing it in the
library, we can save them some annoyance.
|
| |
|
|
|
| |
Previously, they only took strings, which sometimes required the caller
to use json.
|
| |
|
|
|
|
|
|
|
|
| |
Our spec says that when the RPC client has said "I require you to have
feature X" and we don't have it, we need to include the feature(s)
we don't have in an `rpc:unsupported_features` field of our error.
Also, add an integration test for this behavior.
Closes #1662
|
| |
|
|
| |
(Found while writing a test.)
|
| | |
|
| | |
|
| |
|
|
|
| |
(This is all on the theory that any formatting standard is better
than none.)
|
| |
|
|
|
|
| |
Right now, we only support two things in the CLI:
overriding ARTI_RPC_TEST_DIR, and passing additional arguments to
arti_rpc_tests.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We use the `tomli_w` package to generate reasonable toml output,
instead of trying to use `str.format`.
Without this, there's not an easy way to tell string.Formatter
to convert Path('/abc/"def"') to `"abc/\"def\""`.
Something like this would be necessary even if we weren't using
Path, since the toml rules for sring encoding aren't the same as
produced by Python's repr(), which we were using before.
|
| | |
|
| |
|
|
|
|
|
|
| |
These tests are loosely modeled after stem's test suite for Tor and
the Tor control port. They're meant to exercise Arti, Arti RPC, and
the Arti RPC client library.
(For now, they exercise very little.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
@opara says that we'll want to have our API functions be
`extern "C"` everywhere, and so `ctypes.CDLL` should work fine for
them on Windows. This sounds good to me.
|
| |
|
|
| |
This, incidentally, turned up a repeated mistake in the code.
|
| |
|
|
|
| |
Since params can be "anything encodeable to json", there isn't a lot
of point in restricting its type.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has required a few code changes and turned up a few bugs.
The type annotations pass with `mypy`.
Notable code changes:
With type annotations, variable assignment may no longer change
the type of a variable. (I disagree with these semantics, but
here we are.)
Note that some TODOs remain: I have no clear sense how to annotate
the library type from `ctypes`, and better wrappers are needed in
some cases.
|
| | |
|
| |
|
|
| |
(The windows case is untested; the osx case worked fine.)
|
| |
|
|
|
| |
I've tried "python -m build" to make sure it works;
haven't tested anything else.
|
| |
|
|
|
| |
This will make it easier to add other Python packages in the future
as needed.
|
| | |
|
| |
|
| |
Thanks: Anonym
|
| | |
|
| | |
|
| |
|
|
|
| |
This module tries to provide a set of APIs more closely resembling
those you'd expect to use in a real python program.
|
|
|
This wrapper uses Python's `ctypes` module to wrap the APIs
from `arti-rpc-client-core`. It needs more work on Windows
(and likely MacOS too), but that will come later.
This is not a suitable API for direct use in Python.
|
