Consider merging /dev so bisbasic can be discontinued about bismuthclient HOT 6 CLOSED

Will merge/tweak part of it, but logs and options part do not belong to the module.
They at to be handled at app level, not at module level.

from bismuthclient.

That would mean that every app that wants to use options.py will need to keep a copy of it. So I will keep it in bisbasic.

from bismuthclient.

Yes.
options.py is far from generic, it's very closely tied to the node.
There is no reason to use node specific code in a module (be it bismuthclient or bisbasic) embedded by an app that itself works out of the node context.

from bismuthclient.

Some old dapps take some variables from node options, maybe they should ask node for them instead, that would be the most efficient way to do it. That way, options.py can stay with the node only.

from bismuthclient.

Yep.
The design goal of BismuthClient is to abstract the node, as well as connection to it (works with wallet servers ideally, not even node) into a simpler and transparent layer to be used by newest dapps running outside of any context.
That's why it does not rely on a specific node or node option, and does not need specific logging by default.
It is indeed an opinionated design decision not to keep compatibility with older existing dapps, that would then require their own config and some upgrade.

options.py and log.py could be suited for something like a "bis-legacy" or "bis-retrocompatibility" module, so old dapps can use them without loading new modules with legacy code (thinking out loud).
The perimeter of each module would then be clear.

from bismuthclient.

Agreed. Thanks for the input, closing the issue.

from bismuthclient.