92f10f2c34
So this was quite a journey: - We want relative depdendencies (using the `path` argument) whenever developing locally. Otherwise we would have to install each dependency every time we change a single character, which undoubtedly would cause us to waste time trying to debug an issue just because we forgot to install. - When publishing however we want to rely on the version number, since the repo context gets lost upon publishing, and path dependencies cause failures. The solution then it seems is to use `dev-dependencies` (not that surprising once you find it) with relative paths, so that `poetry install` uses these over the normal dependencies (no idea how they dedup them) and use `dependencies` when publishing. The paths are still in there when publishing, but `pip install` ignores them. I checked that `poetry install` from an unrelated project doesn't accidentally use the path dependencies, even when adding them as dev-dependencies. This should hopefully also allow installing them as a repo link, though I can't test that right now. |
||
---|---|---|
.. | ||
docs | ||
pyln/client | ||
tests | ||
.gitignore | ||
Makefile | ||
pyproject.toml | ||
README.md |
pyln-client: A python client library for lightningd
This package implements the Unix socket based JSON-RPC protocol that
lightningd
exposes to the rest of the world. It can be used to call
arbitrary functions on the RPC interface, and serves as a basis for plugins
written in python.
Installation
pyln-client
is available on pip
:
pip install pyln-client
Alternatively you can also install the development version to get access to currently unreleased features by checking out the Core Lightning source code and installing into your python3 environment:
git clone https://github.com/ElementsProject/lightning.git
cd lightning/contrib/pyln-client
python3 setup.py develop
This will add links to the library into your environment so changing the checked out source code will also result in the environment picking up these changes. Notice however that unreleased versions may change API without warning, so test thoroughly with the released version.
Examples
Using the JSON-RPC client
"""
Generate invoice on one daemon and pay it on the other
"""
from pyln.client import LightningRpc
import random
# Create two instances of the LightningRpc object using two different Core Lightning daemons on your computer
l1 = LightningRpc("/tmp/lightning1/lightning-rpc")
l5 = LightningRpc("/tmp/lightning5/lightning-rpc")
info5 = l5.getinfo()
print(info5)
# Create invoice for test payment
invoice = l5.invoice(100, "lbl{}".format(random.random()), "testpayment")
print(invoice)
# Get route to l1
route = l1.getroute(info5['id'], 100, 1)
print(route)
# Pay invoice
print(l1.sendpay(route['route'], invoice['payment_hash']))
Writing a plugin
Plugins are programs that lightningd
can be configured to execute alongside
the main daemon. They allow advanced interactions with and customizations to
the daemon.
#!/usr/bin/env python3
from pyln.client import Plugin
plugin = Plugin()
@plugin.method("hello")
def hello(plugin, name="world"):
"""This is the documentation string for the hello-function.
It gets reported as the description when registering the function
as a method with `lightningd`.
If this returns (a dict), that's the JSON "result" returned. If
it raises an exception, that causes a JSON "error" return (raising
pyln.client.RpcException allows finer control over the return).
"""
greeting = plugin.get_option('greeting')
s = '{} {}'.format(greeting, name)
plugin.log(s)
return s
@plugin.init()
def init(options, configuration, plugin):
plugin.log("Plugin helloworld.py initialized")
# This can also return {'disabled': <reason>} to self-disable,
# but normally it returns None.
@plugin.subscribe("connect")
def on_connect(plugin, id, address):
plugin.log("Received connect event for peer {}".format(id))
plugin.add_option('greeting', 'Hello', 'The greeting I should use.')
plugin.run()