davide/palladum-lightning
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity
Files
main
palladum-lightning/contrib/msggen/pyproject.toml

29 lines
652 B
TOML
Raw Permalink Normal View History

refactor: pyproject.toml poetry to uv + hatch make use of standard keys for project and dependeny specification - provide sources to run uv build so that it can refer local packages - using hatchling for build as is stock build option - use optional-dependencies.dev for dev-dependencies - add hatch targets for packages and includes where unclear Changelog-Update: use uv with hatchling instead of poetry
2025-08-03 08:01:06 +05:30
[project]
msggen: Parse JSON-RPC schemas and build the in-memory model We build an in-memory model of what the API should look like, which will later be used to generate a variety of bindings. In this PR we will use the model to build structs corresponding to the requests and responses for the various methods. The JSON-RPC schemas serve as ground-truth, however they are missing a bit of context: methods, and the request-response matching (as well as a higher level grouping we'll call a Service). I'm tempted to create a new document that describes this behavior and we could even generate the rather repetitive JSON schemas from that document. Furthermore it'd allow us to add some required metadata such as grpc field numbering once we generate those bindings. Changelog-Added: JSON-RPC: A new `msggen` library allows easy generation of language bindings for the JSON-RPC from the JSON schemas
2022-01-14 13:49:56 +01:00
name = "msggen"
version = "0.1.0"
description = "A utility to transform wire messages and JSON-RPC messages to arbitrary target languages."
refactor: pyproject.toml poetry to uv + hatch make use of standard keys for project and dependeny specification - provide sources to run uv build so that it can refer local packages - using hatchling for build as is stock build option - use optional-dependencies.dev for dev-dependencies - add hatch targets for packages and includes where unclear Changelog-Update: use uv with hatchling instead of poetry
2025-08-03 08:01:06 +05:30
authors = [{ name = "Christian Decker", email = "decker@blockstream.com" }]
license = { text = "BSD-MIT" }
chore: Update python dependencies I got a bit annoyed by all the "your protobuf gencode is too old" warnings in downstream packages, so I spent a bit of time updating any stale dependency and now we're back allowing packages up to the latest release. That should maximize the compatibility, and allow downstream packages to chose their own versions, as long as they are compatible (semantic versioning).
2025-09-29 16:54:25 +02:00
requires-python = ">=3.9,<4.0"
refactor: pyproject.toml poetry to uv + hatch make use of standard keys for project and dependeny specification - provide sources to run uv build so that it can refer local packages - using hatchling for build as is stock build option - use optional-dependencies.dev for dev-dependencies - add hatch targets for packages and includes where unclear Changelog-Update: use uv with hatchling instead of poetry
2025-08-03 08:01:06 +05:30
dependencies = []
msggen: Parse JSON-RPC schemas and build the in-memory model We build an in-memory model of what the API should look like, which will later be used to generate a variety of bindings. In this PR we will use the model to build structs corresponding to the requests and responses for the various methods. The JSON-RPC schemas serve as ground-truth, however they are missing a bit of context: methods, and the request-response matching (as well as a higher level grouping we'll call a Service). I'm tempted to create a new document that describes this behavior and we could even generate the rather repetitive JSON schemas from that document. Furthermore it'd allow us to add some required metadata such as grpc field numbering once we generate those bindings. Changelog-Added: JSON-RPC: A new `msggen` library allows easy generation of language bindings for the JSON-RPC from the JSON schemas
2022-01-14 13:49:56 +01:00
refactor: pyproject.toml poetry to uv + hatch make use of standard keys for project and dependeny specification - provide sources to run uv build so that it can refer local packages - using hatchling for build as is stock build option - use optional-dependencies.dev for dev-dependencies - add hatch targets for packages and includes where unclear Changelog-Update: use uv with hatchling instead of poetry
2025-08-03 08:01:06 +05:30
[dependency-groups]
chore: Update python dependencies I got a bit annoyed by all the "your protobuf gencode is too old" warnings in downstream packages, so I spent a bit of time updating any stale dependency and now we're back allowing packages up to the latest release. That should maximize the compatibility, and allow downstream packages to chose their own versions, as long as they are compatible (semantic versioning).
2025-09-29 16:54:25 +02:00
dev = ["pytest>=8.0.0"]
refactor: pyproject.toml poetry to uv + hatch make use of standard keys for project and dependeny specification - provide sources to run uv build so that it can refer local packages - using hatchling for build as is stock build option - use optional-dependencies.dev for dev-dependencies - add hatch targets for packages and includes where unclear Changelog-Update: use uv with hatchling instead of poetry
2025-08-03 08:01:06 +05:30
[project.scripts]
msggen = "msggen.__main__:main"
[tool.hatch.build.targets.wheel]
msggen: Start making the `msggen` library a standalone tool There are quite some things we want to generate from the schema definitions, both inside and outside of CLN itself. By bundling the schemas into the library we can make use of the tooling without running in the CLN source tree. This is in part used to generate some of the interfaces in Greenlight. Changelog-None
2023-12-05 14:03:36 +01:00
include = ["msggen/schema.json"]
msggen: Parse JSON-RPC schemas and build the in-memory model We build an in-memory model of what the API should look like, which will later be used to generate a variety of bindings. In this PR we will use the model to build structs corresponding to the requests and responses for the various methods. The JSON-RPC schemas serve as ground-truth, however they are missing a bit of context: methods, and the request-response matching (as well as a higher level grouping we'll call a Service). I'm tempted to create a new document that describes this behavior and we could even generate the rather repetitive JSON schemas from that document. Furthermore it'd allow us to add some required metadata such as grpc field numbering once we generate those bindings. Changelog-Added: JSON-RPC: A new `msggen` library allows easy generation of language bindings for the JSON-RPC from the JSON schemas
2022-01-14 13:49:56 +01:00
[tool.poetry.dependencies]
chore: Update python dependencies I got a bit annoyed by all the "your protobuf gencode is too old" warnings in downstream packages, so I spent a bit of time updating any stale dependency and now we're back allowing packages up to the latest release. That should maximize the compatibility, and allow downstream packages to chose their own versions, as long as they are compatible (semantic versioning).
2025-09-29 16:54:25 +02:00
python = "^3.9"
msggen: Parse JSON-RPC schemas and build the in-memory model We build an in-memory model of what the API should look like, which will later be used to generate a variety of bindings. In this PR we will use the model to build structs corresponding to the requests and responses for the various methods. The JSON-RPC schemas serve as ground-truth, however they are missing a bit of context: methods, and the request-response matching (as well as a higher level grouping we'll call a Service). I'm tempted to create a new document that describes this behavior and we could even generate the rather repetitive JSON schemas from that document. Furthermore it'd allow us to add some required metadata such as grpc field numbering once we generate those bindings. Changelog-Added: JSON-RPC: A new `msggen` library allows easy generation of language bindings for the JSON-RPC from the JSON schemas
2022-01-14 13:49:56 +01:00
poetry: update all pyproject.toml files for poetry 2.0.1 and run poetry lock Changelog-None
2025-05-01 13:17:51 -05:00
[tool.poetry.group.dev.dependencies]
msggen: Parse JSON-RPC schemas and build the in-memory model We build an in-memory model of what the API should look like, which will later be used to generate a variety of bindings. In this PR we will use the model to build structs corresponding to the requests and responses for the various methods. The JSON-RPC schemas serve as ground-truth, however they are missing a bit of context: methods, and the request-response matching (as well as a higher level grouping we'll call a Service). I'm tempted to create a new document that describes this behavior and we could even generate the rather repetitive JSON schemas from that document. Furthermore it'd allow us to add some required metadata such as grpc field numbering once we generate those bindings. Changelog-Added: JSON-RPC: A new `msggen` library allows easy generation of language bindings for the JSON-RPC from the JSON schemas
2022-01-14 13:49:56 +01:00
pytest = "^6.2.5"
[build-system]
refactor: pyproject.toml poetry to uv + hatch make use of standard keys for project and dependeny specification - provide sources to run uv build so that it can refer local packages - using hatchling for build as is stock build option - use optional-dependencies.dev for dev-dependencies - add hatch targets for packages and includes where unclear Changelog-Update: use uv with hatchling instead of poetry
2025-08-03 08:01:06 +05:30
requires = ["hatchling>=1.0.0"]
build-backend = "hatchling.build"
Reference in New Issue Copy Permalink