[CI test] Integrate secp256k1lab as subtree

[theStack]

This PR moves the secp256k1lab (formerly called secp256k1proto) folder to an external package (living at https://github.com/theStack/secp256k1lab currently, created with the uv package manager), integrating it as git-subtree here [1]:

$ git subtree add --prefix=python/secp256k1lab --squash https://github.com/theStack/secp256k1lab secp256k1lab-draft02

Supersedes #81, using the suggested syspath extension approach [1] [2] [3] to avoid the ugly import hack that was used before.

[1] #81 (comment)
[2] #81 (comment)
[3] https://github.com/BlockstreamResearch/bip-frost-dkg/tree/syspath

[jonasnick]

This is looking good. Added some comments.

[theStack]

Rebased on master and addressed the review comments above (#83 (comment), #83 (comment), #83 (comment)). I btw thought it might be nice to squash the first three commits into one, but somehow always the rename of the vendored package (src/secp256k1lab => python/secp256k1lab/src/secp256k1lab, apparently happening in the merge commit) gets lost 🤔

[real-or-random]

This is a bit more modern Python and also a bit more readable IMO:

Suggested change

	# Prefer the vendored copy of secp256k1lab.
	sys.path.insert(0, os.path.join(os.path.dirname(__file__), "../secp256k1lab/src"))
	# Prefer the vendored copy of secp256k1lab.
	sys.path.insert(0, Path(__file__).parent / "../secp256k1lab/src")

(needs from pathlib import Path)

[theStack]

Done. Note that I had to convert the resulting Path object (PosixPath on my machine) to a string though (str(...)), as otherwise it wouldn't work.

[real-or-random]

Oh, indeed... Well, fine, I guess it's still a tiny bit more readable than the os.path variants.

[real-or-random]

I think it will be fair to list @sipa as an author:

Suggested change

	authors = [
	{ name = "Tim Ruffing", email = "[email protected]" },
	{ name = "Jonas Nick", email = "[email protected]" },
	{ name = "Sebastian Falbesoner", email = "[email protected]" }
	]
	authors = [
	{ name = "Pieter Wuille", email = "[email protected]" },
	{ name = "Tim Ruffing", email = "[email protected]" },
	{ name = "Jonas Nick", email = "[email protected]" },
	{ name = "Sebastian Falbesoner", email = "[email protected]" }
	]
	maintainers = [
	{ name = "Tim Ruffing", email = "[email protected]" },
	{ name = "Jonas Nick", email = "[email protected]" },
	{ name = "Sebastian Falbesoner", email = "[email protected]" }
	]

based on:
https://github.com/bitcoin/bitcoin/commits/e486597f9a57903600656fb5106858941885852f/test/functional/test_framework/crypto/secp256k1.py

[real-or-random]

You've added authors but not maintainers. Was this intentional? (I also don't like the duplication too much, but well, it's correct...)

[real-or-random]

I think we can safely make this "production", otherwise it'll be in 0.x.x land forever.

Perhaps a date-based versioning scheme like YYYY.M.D is better? I'd be hesitant to use MAJOR.MINOR.REVISON as people then think "semantic versioning" and I don't think we want to make any guarantees. This a primarily a playground. If someone wants to use it, they can vendor/pin the commit?

@jonasnick @theStack What do you think?

[jonasnick]

I think semantic versioning is a good choice in our case. I don't really see the problem with trying to make guarantees. We can just be very liberal about increasing the major version. Even if users vendor or pin the commit, it's very helpful to see very quickly what has changed in the library.

I agree that starting with 1.0.0 makes sense here.

[real-or-random]

Fine with me. Related question: Do we want a changelog?

[jonasnick]

I think that'd be helpful (at least once we have actual changes).

Are there any changes we already know we want to do before 1.0.0?

[real-or-random]

I'd keep it minimal:

• add CI (ruff and mypy?)
• fix secp256k1proto: Split APrime.from_int into a wrapping and a checked variant #77
• add a Changelog

anything else?

[theStack]

Any opinion about the "[build-system]" section? "hatchling" is what "uv init" created by default, but I don't have any knowledge about what makes sense to use (or if it even matters that much, considering we have no dependencies).

[real-or-random]

I won't really matter for us, but hatchling is totally fine and the uv devs choose it for a reason. astral-sh/uv#7132. Fwiw, uv will soon have its own build backend. I'd just keep this as is.

[real-or-random]

I btw thought it might be nice to squash the first three commits into one, but somehow always the rename of the vendored package (src/secp256k1lab => python/secp256k1lab/src/secp256k1lab, apparently happening in the merge commit) gets lost 🤔

I think I've seen this before. Just a shot in the dark but perhaps this helps: https://stackoverflow.com/questions/30136558/how-to-squash-commits-which-have-merge-commit-in-between

[theStack]

Added the secp256k1lab suggestions in branch https://github.com/theStack/secp256k1lab/tree/secp256k1lab-draft02 and updated the subtree integration in this PR accordingly. Still a bunch of TODOs (#83 (comment), plus determining a reasonable required Python version), I hope to tackle them this week. I guess with the ruff and mypy integration I can pretty much reuse the CI config here with minor adaptions, or is there anything special to be considered if it's a (uv) package?

[real-or-random]

I guess with the ruff and mypy integration I can pretty much reuse the CI config here with minor adaptions, or is there anything special to be considered if it's a (uv) package?

This is not strictly necessary, but since we use uv anyway: we won't need pip install foo, and we can just use uvx foo (see uv help tool).

plus determining a reasonable required Python version)

Something like uv run --python 3.9 should do it. But you'll need to execute the BIP code: uv run --python 3.9 python/tests.sh (or something like this, I haven't tested.) The thing is that we can't really run the library, and there are no tests, so the best test we have is running the BIP code...