nix: use uv2nix for managing the documentation's dependencies #6480
Conversation
|
This is a draft for now while I try to figure out a good way to remove the https://github.com/pyproject-nix/build-system-pkgs dependency (we may need it but probably will be able to remove it at some point -- details to come) and an issue involving If we decide to not go this route due to the added complexity, that's fine. :) |
| @@ -161,6 +175,15 @@ | |||
| }); | |||
|
|
|||
| devShells.default = let | |||
| uvWorkspace = uv2nix.lib.workspace.loadWorkspace { workspaceRoot = pkgs.lib.fileset.toSource { root = ./.; fileset = pkgs.lib.fileset.unions [ ./pyproject.toml ./uv.lock ]; }; }; | |||
There was a problem hiding this comment.
Let’s avoid filesets until they have non‐broken semantics.
There was a problem hiding this comment.
Fair enough -- to clarify, you don't mean the chroot bug?
There was a problem hiding this comment.
I do. It’s not really a bug so much as an infelicity in the semantics, anyway. linkFarm … { "pyproject.toml" = ./pyproject.toml; "uv.lock" = ./uv.lock; } should be adequate here.
|
Works for me on both NixOS and Debian. |
No: |
Since 8e15a26, we now depend on NumPy to build the docs, which is a departure from our previous happy path of not needing C extensions/platform-specific wheels, which unfortunately break on NixOS. uv2nix luckily does the hard work for us and makes everything (including patching wheels and falling back to source compilation) pretty easy to do. This is arguably preferrable to solutions like [0], as now we don't have to deal with breakages like [1], and will be able to extend our Python dependency footprint in the future without much fuss. [0]: jj-vcs#6472 [1]: jj-vcs#6472 (comment)
winterqt
force-pushed
the
push-krpxqvnlkqox
branch
from
bb2ed8a to
b2ced09
Compare
Since 8e15a26, we now depend on NumPy to build the docs, which is a departure from our previous happy path of not needing C extensions/platform-specific wheels, which unfortunately break on NixOS.
uv2nix luckily does the hard work for us and makes everything (including patching wheels and falling back to source compilation) pretty easy to do. This is arguably preferrable to solutions like 0, as now we don't have to deal with breakages like 1, and will be able to extend our Python dependency footprint in the future without much fuss.
Checklist
If applicable:
CHANGELOG.md