📦️(nix) init nix packaging for docs

[soyouzpanda]

Add nix package and module to be able to run docs on NixOS

[mweinelt]

FYI: NixOS/nixpkgs#400561

[chrnin]

Thit would benefit from a little documentation on how to add this package to a working nixos system, for instance:

  imports = [ (import /foo/docs/module.nix) ];
  nixpkgs.overlays = [ (import /foo/docs/overlay.nix) ];
  
  security.acme.acceptTerms = true;
  security.acme.defaults.email = "[email protected]";
  services.docs.enable = true;
  services.docs.domain = "docs.example.com";
  services.docs.s3.url = "https://s3.example.com";
  services.docs.database.createLocally = true; 
  services.docs.redis.createLocally = true;

[chrnin]

This doesn't work with nixos 25.05 (aka nixos-unstable).

error: builder for '/nix/store/0gaygaq54lz82jczj5xmhgsii4xapivv-python3.12-django-extensions-4.0.drv' failed with exit code 1;
       last 22 log lines:
       > Sourcing python-remove-tests-dir-hook
       > Sourcing python-catch-conflicts-hook.sh
       > Sourcing python-remove-bin-bytecode-hook.sh
       > Sourcing pypa-build-hook
       > Using pypaBuildPhase
       > Sourcing python-runtime-deps-check-hook
       > Using pythonRuntimeDepsCheckHook
       > Sourcing pypa-install-hook
       > Using pypaInstallPhase
       > Sourcing python-imports-check-hook.sh
       > Using pythonImportsCheckPhase
       > Sourcing python-namespaces-hook
       > Sourcing python-catch-conflicts-hook.sh
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/7zmdyg7jhdg0bg24r79l3n3z66kglpdr-source
       > source root is source
       > setting SOURCE_DATE_EPOCH to timestamp 315619200 of file "source/tox.ini"
       > Running phase: patchPhase
       > applying patch /nix/store/1xgnp0xyn0j2627b10dcc4vlgc39g51f-2.patch
       > patching file tests/testapp/models.py
       > Hunk #2 FAILED at 476.
       > 1 out of 2 hunks FAILED -- saving rejects to file tests/testapp/models.py.rej

btw, it works with 24.11.

[soyouzpanda]

Yeah, i think that browniebroke/django-extensions#2 is now on nixpkgs since NixOS/nixpkgs#397831 has been mergeed

[soyouzpanda]

I think I resolved the issue, could you retry?

[chrnin]

indeed ! it looks like it works !

[chrnin]

I got another issue with nixos-unstable and the collaboration server who dies horribly…
crash.log attached

I'd suggest to not bother too much with 25.05 before it's out for release.

[soyouzpanda]

I got another issue with nixos-unstable and the collaboration server who dies horribly… crash.log attached

I'd suggest to not bother too much with 25.05 before it's out for release.

ahahah a friend of mine just reported me this. I need to be more subtle when copying files into nix store i guess...

[soyouzpanda]

I got another issue with nixos-unstable and the collaboration server who dies horribly… crash.log attached

I'd suggest to not bother too much with 25.05 before it's out for release.

I think the issue is resolved.

[lunika]

Does that means we have to maintain this list of dependencies in addition to the already existing one (pyproject.toml file) ?

[soyouzpanda]

Yes, but you are required to do so in Nix, so python packages are in the path.
Look at: https://github.com/NixOS/nixpkgs/blob/6aaa3618ae99d72a2bfa8de218669ad5a42ed182/pkgs/by-name/gl/glitchtip/package.nix or https://github.com/NixOS/nixpkgs/blob/6aaa3618ae99d72a2bfa8de218669ad5a42ed182/pkgs/by-name/pr/pretix/package.nix

[RaitoBezarius]

If it's too much of a maintenance churn, the Nix packaging could be relegated to a "best effort" support level and Nix maintainers could be pinged to help on every PR that adds / removes a new package (hopefully, this doesn't happen too regularly?!).

[lunika]

And it's not possible to parse or use already existing python tools to maintain this list ? It's not error prone to try to maintain the same list in different places ?
I feel we have to do the same job twice between this file and the pyproject.toml one.

[RaitoBezarius]

There's projects to do so in https://pyproject-nix.github.io/ but the Nix list and the pyproject.toml list does not do the same thing.

pyproject.toml only care about direct Python dependencies, wheras, the Nix list cares about the exhaustive list.

Furthermore, the Nix list relies on the security maintenance of nixpkgs whereas pyproject.toml relies on the correctness of the version markers.

I think moving to pyproject.nix can be done later on slowly as Docs is upstreamed in nixpkgs and then the Docs repo can be advertised to provide packaging for the bleeding edge of Docs while advertising that the package provenance is Docs' responsibility, whereas Nixpkgs would offer the Docs with package provenance from Nixpkgs. It's a classical pattern but it takes a bit of time to get right.

[lunika]

Thanks for the explanation.
If the package will be in nixpkgs, why this PR is needed in docs repo ? Maybe I'm wrong but are you not doing the same job twice ?

[soyouzpanda]

At first, the package was not intended to be in nixpkgs. A decision was made a few days ago to push it into nixpkgs.
The new idea is to have a package in nixpkgs which is a stable version and follows releases tags, and a package here which is an unstable version and follows main.
It requires extra maintenance, and I do not know if it is ok. I think you can decide whether or not to close this PR if you don't want extra maintenance (which, I think, will not be that great)

[lunika]

So the idea here is more to have a dev stack manage with Nix ?

[lunika]

If it's the idea then to have less work I think we should test in the CI that the Nix stack is always working as expected. We can assert that it is "building" and then the project running. WDYT ?

[soyouzpanda]

If it's the idea then to have less work I think we should test in the CI that the Nix stack is always working as expected. We can assert that it is "building" and then the project running. WDYT ?

Yeah, I think it's a great idea. I'll add this in this PR.
Also, I switch this PR to draft, because the PR will change alot.