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

[nothingmuch]

any chance we can use uv and uv2nix instead of pip?

requirements.txt is not reproducible, and poetry2nix is kinda dead these days

doing this in a shell hook also means we can't really use this in a flake check in a clean way, so while this is convenient it seems like it would be pretty brittle in the long term and if people run into problems we would have a hard time debugging without a lot of manual intervention

especially because venv is likely to survive long term and accumulate cruft unless the user deliberately cleans and reruns the shell hook (ideally the built artifacts should end up in the nix store)

[nothingmuch]

wouldn't using ${system} potentially be more future proof? they can still be a single file using symlinks but if there are any platform specific quirks down the line i suspect the net result would be adding another layer on top of this, instead of going the more direct route

[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.

[spacebear21]

cACK - I agree @nothingmuch's comments can be addressed in follow-ups, and also fyi the generate scripts are getting overhauled in #980

[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.