Switch from poetry to nixpkgs #515
Conversation
flake.nix
Outdated
| name = "nix-dev"; | ||
| src = self; | ||
| buildInputs = with pkgs.python310Packages; [ | ||
| livereload |
There was a problem hiding this comment.
livereload is only used for local development as it is a tool which invokes a build command every time a change is detected.
There was a problem hiding this comment.
Are you suggesting I do something differently?
There was a problem hiding this comment.
@zmitchell Yeah, I'm just saying it's not necessary to be inside buildInputs since it is not a dependency required for building the website.
There was a problem hiding this comment.
Ok, that part I get. What I don't get is where black and livereload are supposed to go instead. The live script relies on livereload being available for the call to nix-shell --run, and since I'm new to Nix I'm not sure the best way to achieve the same thing if those Python modules aren't in buildInputs.
There was a problem hiding this comment.
A good approach is to have the main derivation describing only the tools and libraries it needs to build, and then have a separate derivation corresponding to a development shell where you add additional tools.
flake.nix
Outdated
| sphinx-book-theme | ||
| sphinx-copybutton | ||
| sphinx-design | ||
| black |
There was a problem hiding this comment.
black is also a development only tool as it is a Python linter.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-04-13-learning-journey-working-group-meeting-notes-4/27255/1 |
|
Discussed in the Nix documentation team meeting:
|
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-04-27-documentation-team-meeting-notes-44/27694/1 |
flake.nix
Outdated
| defaultPackage = pkgs.stdenv.mkDerivation { | ||
| name = "nix-dev"; | ||
| src = self; | ||
| buildInputs = with pkgs.python310Packages; [ |
There was a problem hiding this comment.
| buildInputs = with pkgs.python310Packages; [ | |
| nativeBuildInputs = with pkgs.python310Packages; [ |
There was a problem hiding this comment.
Can you explain the motivation here? I gather that (native|propagated)BuildInputs and buildInputs are rooted in cross compilation, but this distinction is lost on me in the context of Python.
There was a problem hiding this comment.
Simply correctness; native build inputs are your tools. Yes, outside cross-compilation it is less valuable however for Python it for sure still matters. Remember, there is a lot of native code used by Python modules.
Note buildPython* makes the distinction (it sets strictDeps = true;).
There was a problem hiding this comment.
Let me rephrase the question to hone in on the part that confuses me: in general and in the Python specific case, when should I put packages in buildInputs, nativeBuildInputs, or propagatedBuildInputs?
There was a problem hiding this comment.
nativeBuildInputs: these are build-time tools, that is, programs that run during the build (hence they need to be native)buildInputs: these are headers/libraries which one needs during build time, e.g. to link against, but it is not executed. These are thus your run-time dependencies.propagatedBuildInputs: these arebuildInputsbut that are propagated, that is, whoever adds your derivation in abuildInputs, will automatically get all thesepropagatedBuildInputsas well. And this is done recursively.
The Nixpkgs manual describes this in more detail.
In buildPython* we use propagatedBuildInputs for our run-time dependencies, which in a way is in line with what I wrote above, but it has its issues. It's a historic artifact and unfortunately a complete pain to fix.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-10-05-documentation-team-meeting-notes-84/33877/1 |
alejandrosame
force-pushed
the
poetry-to-nixpkgs
branch
from
7115adc to
c8667ac
Compare
Deploy Preview
|
alejandrosame
force-pushed
the
poetry-to-nixpkgs
branch
from
c8667ac to
4da4d18
Compare
Deploy Preview
|
alejandrosame
force-pushed
the
poetry-to-nixpkgs
branch
from
4da4d18 to
32b0aa0
Compare
| overlays = [ | ||
| # Add sphinx-sitemap from an overlay until | ||
| # it becomes available from nixpkgs-unstable | ||
| (import ./overlay.nix) | ||
| ]; |
There was a problem hiding this comment.
sphinx-sitemap PR: NixOS/nixpkgs#260274
Deploy Preview
|
|
PR to add |
This PR removes the
poetrybased workflow in favor of a nixpkgs based workflow. In doing so the Python version will be updated from 3.7 to 3.10. This also necessitates upgradingsphinxto v5.1.1. The version ofsphinx-book-themein nixpkgs is v0.3.3, which is not compatible withsphinxv5.x. The latest version ofsphinx-book-themeis v1.0.1, which is compatible withsphinxv5.x, but it's not in nixpkgs.