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).
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
People running master notice that calling listconfigs fails, because
we don't handle objects called xxx_msat correctly (see
d348554ff4). This makes it painful
to test, until we release a pyln-client version.
Fortunately, the three changes in master are all fully backwards compatible,
so we can simply cut a release now and upload to pipy.org.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is just before the introduction of `get_json_id`, but has the
correct dependency constraints such that all packages can be updated
to >=v0.12 and we don't mix minor versions.
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.
Mostly comments and docs: some places are actually paths, which
I have avoided changing. We may migrate them slowly, particularly
when they're user-visible.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
