Add python devShell to nix flake

[thebrandonlucas]

Adds a top-level python devShell to the nix flake which creates a shell with a python virtual environment with all necessary dependencies installed.

Now, assuming Docker is running and nix is installed on the system, a developer can simply run nix develop .#python and have a shell with all the requirements to run python -m unittest --verbose setup, or import the payjoin package (locally built) to their project.

Addresses this issue referenced in the nix flake tracking issue.

Also updates the README accordingly, de-duplicates some instructions, and removes some crufty language

[coveralls]

Pull Request Test Coverage Report for Build 17097642875

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 86.514%

---

Totals
Change from base Build 17086213464:	0.0%
Covered Lines:	7852
Relevant Lines:	9076

---

💛 - Coveralls

[arminsabouri]

@thebrandonlucas are you waiting on review for this? Is something else blocking?

[thebrandonlucas]

@thebrandonlucas are you waiting on review for this? Is something else blocking?

@arminsabouri I was away from this for awhile but am now actively working on it addressing @nothingmuch's feedback (trying to add the flake check, refactor the ${system} change, and particularly add in uv as the more robust alternative to pip which I am not familiar with and am learning about how to incorporate now).

That said, I don't think we lose anything by adding this as-is considering this just incorporates the current build instructions for python ffi into a nix flake. So this would probably prove immediately useful and was working last I checked, despite @nothingmuch's improvement suggestions which definitely should be addressed at some point IMO.

[arminsabouri]

@thebrandonlucas thanks for the quick response. Makes sense. paging @nothingmuch.

[DanGould]

Because this needs a rebase, I don't think a little delay to get this to be actually reproducible is the worst thing in the world. Makes sense to figure out how to do it nixpilled.

[DanGould]

From @nothingmuch

tl;dr requirements.txt is like cargo toml

poetry and now uv make something like cargo lock possible

poetry has kinda fallen out of favor

given a proper lock file with strong hashes, it's ~trivial to compute an equivalent nix package for a python project

that's what uv2nix does

so then nix would build the package and add the built packages to the shell

the current approach adds the tooling for building into the shell, but then hackily builds that in a shell hook, using the non sandboxed current working directory

[nothingmuch]

see #997 for some WIP to do this, we (@thebrandonlucas and I) haven't done the uv2nix part of it yet, just uv instead of pip, i think the most logical thing would be for that PR to only be the uv instead of pip change and this PR can get rebased on top of that

[nothingmuch]

at Dan's request, the reproduceability rationale for uv and uv2nix over pip:

1. requirements.txt is like Cargo.toml, it only specifies semver constraints. even with fully specified versions, there are no hashes etc... uv moves those specifications to pyproject.toml, and more importantly introduces a uv.lock file that analogous to Cargo.lock

2. given a uv.lock with fully specified dependencies, uv2nix is able to create a nix package for the python package programmatically, allowing us to build this package in the nix sandbox

3. similarly all the tooling (uv, python itself) can also be added to the nix devshell, with flake.lock specifying precise versions, and given a nix package for the python package, that can be also added to the devshell and/or have flake checks added to ensure it builds and tests properly

[arminsabouri]

just uv instead of pip, i think the most logical thing would be for that PR to only be the uv instead of pip change and this PR can get rebased on top of that

uv was merged. I think this PR needs a rebase and another review. Not an urgent priority.