This would lead to errors about missing dependencies when attempting
to install using `pyhon setup.py install`. This is because the
`setup.py` file effectively is the manifest file used to discover
which dependencies are needed, so when using it to detect dependencies
we obviously don't have them yet.
See https://packaging.python.org/guides/single-sourcing-package-version/
We weren't writing out the length of a nested subtype's
dynamicarraylenght, now we do. The trick is to iterate through the
fields on a subtype (since the length field is added separately)
and to also iterate down through the otherfield values as we 'descend'
We were getting a number of incompatibility warning due to the
dependencies being expressed too rigidly. This losens the requirement
definitions to being compatible with a known good version, and while
we're at it we also bump all outdated requirements.
- Adds bitarray filling so mesages of any length can be encoded, instead of forcing the encoding to be of messages with length multiple of 5.
- Adds checks for encoding / decoding and raises expections if the inputs are not as expected.
- Flags functions that are supposed to be internal as "private".
Currently ``LightningConnection.remote_pubkey`` is set to ``None`` if the node is not the handshake initiator. This sets it to ``rs`` in act three from the receiver side
Since pyln-bolt* specify the 0.8.4 version which we didn't upload, and the
requirements.txt specify ==0.8.4, we need to backfill that version, even if we
could just bump it directly to 0.9.1.
1. version was 0.0.2 in setup.py, which means we didn't get the dist/ files we expected.
2. We need 'bdist_wheel' to make the .whl file.
3. --no-site-packaged was apparently removed in 0.20.0, and was default long before that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This includes some real bugfixes, since it noticed some places we were
being loose with different types!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They're almost entirely autogenerated, and we use symlinks into the
top directory to reduce replication.
They can't be under pyln.spec.message, because a package can't also
be a namespace.
We also add fulltext and desc fields, and exclude our "gen" files from
flake8, since the spec quotes contain weird whitespace.
Changelog-Added: Python: pyln.spec.bolt{1,2,4,7} packages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Remove non-existant pyln.proto.bolts. bolts will have separate setup.py, so we
can rev the versions individually.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This delivers the message contents in a much friendlier form for
manipulation: in particular, it makes it easy to compare two
messages without having to know all the message type internals.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If they don't exist, that's OK. These will eventually be going away
from the spec, but there are still some in gossip messages for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Exposing the array types is required for our dummyrunner in the lnprototest suite, since
it wants to be able to generate fake fields.
The set_field is similarly useful.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Other changes along the way:
1. In a couple of places we passed None as a dummy for for
`otherfields` where {} is just as good.
2. Turned bytes into hex for errors.
3. Remove nonsensical (unused) get_tlv_by_number() function from MessageNamespace
4. Renamed unrelated-but-overlapping `field_from_csv` and
`type_from_csv` static methods, since mypy thought they should have
the same type.
5. Unknown tlv fields are placed in dict as strings, not ints, for
type simplicity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These are autogenerated, but now they export their own
MessageNamespace, as well as the raw csv.
They also expose their SubtypeTypes, MessageTypes and TlvStreamTypes,
though in theory these could clash (they don't for now, and it'd be
kinda awkward if they did).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This contains the CSVs for the current bolts (autogenerated). It's a
separate module because I expect it to be updated alongside the spec.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: pyln: new module pyln.proto.message.bolts
This will be useful for the next patch, which introduces per-bolt
modules. This makes it easier for them generate variables for each
field type they parse (they don't want to export u16, for example)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Instead of val_to_bin/val_from_bin which deal with bytes, we implement
read and write which use streams. This simplifies the API.
Suggested-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This supports infrasructure for creating messages. In particular, it
can be fed CSV from the spec's `tools/extract-formats.py` and then convert
them all to and from strings and binary formats.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: pyln: new module pyln.proto.message
contrib/pyln-proto/pyln/proto/bech32.py:120
/home/rusty/devel/cvs/lightning/contrib/pyln-proto/pyln/proto/bech32.py:120: SyntaxWarning: "is not" with a literal. Did you mean "!="?
assert decode(hrp, ret) is not (None, None)
I think this warning is correct (though I don't see the warning once I installed coincurve:
are we suppressing warnings?)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
secp256k1 Python library is not maintained anymore and coincurve was
already used in the `wire` module.
Changelog-None
Signed-off-by: Michal Rostecki <mrostecki@mailfence.com>
Update to v13 as v12 started to raise undefined symbol exceptions agains latest
libsecp256k1.
Note: any version of `pip install coincurve` fails if no libsecp256k1 headers
are installed, should we point this out somewhere/somehow?
Changelog-None
We are about to disect a couple of invoices for features, so let's add a class
that can encode and decode invoices from bolt11 strings. This is pretty much
the lnaddr.py file created by @rustyrussell with some minor changes. I'm
planning to clean this up further which is why I'm only exporting the
`Invoice` class for now.
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>
