Conversation
This code exposes runtime storage items, constants and APIs as if they
are mirrored in Python. It is intended to simplify and reduce code, and
to close the current gap between subtensor code and bittensor code. As
it is based on metadata, it exposes past, current and future runtime
items.
E.g. the subnet owner map can be queried using only:
import bittensor as bt
bt.runtime.SubtensorModule.SubnetOwner[1]
test_runtime_browser.py contains various examples that demonstrate the
proposed concept.
The impact on bittensor is negligible, as it is implemented as a fully
separate module.
|
Hey @mvds00, do you still work on it or we can close this PR? |
|
We should build on top of this. I think it's a good idea to include in bittensor v10. |
Could you check within the developer group if this has a realistic chance of making it to v10? If so, I would be more than happy to put in the effort to make this up to date. |
This is the branch SDKv10 in which I am currently cooking SDKv10. You can put in the effort and add your RuntimeBrowser logic as a separate layer. Look at how I implemented SubtensorApi. |
|
Move task to #3051 |
|
I really like the way JS does it where they use api.at(blockNumber), as the pallets/calls/etc. are all going to change depending on the particular runtime at that block. May be worth considering adding these to the Runtime object in async-substrate-interface: https://github.com/opentensor/async-substrate-interface/blob/d731dd55435f7588fc677458e428b7170caf97dc/async_substrate_interface/types.py#L103 |
3 participants
RFC: runtime_browser
This code exposes runtime storage items, constants and APIs as if they are mirrored in Python. It is intended to simplify and reduce code, and to close the current gap between subtensor code and bittensor code. As it is based on metadata, it exposes past, current and future runtime items.
E.g. the subnet owner map can be queried using only:
test_runtime_browser.pycontains various examples that demonstrate the proposed concept.The impact on bittensor is negligible, as it is implemented as a fully separate module.
TODO: write proper PR, format code, etc. - this is just to share the WIP, and have a discussion about the concept and direction to (not) take it.