lightning

6992 Commits

55 Branches

107 Tags

38 MiB

Tree: 162cea265c

Commit Graph

Author	SHA1	Message	Date
Christian Decker	81f7978cc8	pyln: Migrate implementation from pylightning to pyln-client This should not affect any consumer of the API since we just shift the actual implementation from one side to the other, and keep aliases in place so scripts don't break. We also bump the version number from 0.0.7.3 to 0.7.4 which allows us to be in sync with c-lightning itself, and remove the superfluous `0` in front.	5 years ago
Christian Decker	3418e59d76	pyln: Split pylightning into multiple pyln modules This is the first step to transition to a better organized python module structure. Sadly we can't reuse the `pylightning` module as a namespace module since having importable things in the top level of the namespace is not allowed in any of the namespace variants [1], hence we just switch over to the `pyln` namespace. The code the was under `lightning` will now be reachable under `pyln.client` and we add the `pyln.proto` module for all the things that are independent of talking to lightningd and can be used for protocol testing. [1] https://packaging.python.org/guides/packaging-namespace-packages/ Signed-off-by: Christian Decker <decker.christian@gmail.com>	6 years ago

Author

SHA1

Message

Date

Christian Decker

81f7978cc8

pyln: Migrate implementation from pylightning to pyln-client

This should not affect any consumer of the API since we just shift the actual
implementation from one side to the other, and keep aliases in place so
scripts don't break.

We also bump the version number from 0.0.7.3 to 0.7.4 which allows us to be in
sync with c-lightning itself, and remove the superfluous `0` in front.

5 years ago

Christian Decker

3418e59d76

pyln: Split pylightning into multiple pyln modules

This is the first step to transition to a better organized python module
structure. Sadly we can't reuse the `pylightning` module as a namespace module
since having importable things in the top level of the namespace is not
allowed in any of the namespace variants [1], hence we just switch over to the
`pyln` namespace. The code the was under `lightning` will now be reachable
under `pyln.client` and we add the `pyln.proto` module for all the things that
are independent of talking to lightningd and can be used for protocol testing.

[1] https://packaging.python.org/guides/packaging-namespace-packages/

Signed-off-by: Christian Decker <decker.christian@gmail.com>

6 years ago

2 Commits (162cea265c1c47c794b0a826d5a8f53033c04c19)