nixos/paperless: json-encoded variables viable in unit and manage script

[ctheune]

Some paperless settings (like PAPERLESS_CONSUMER_IGNORES) are taken as JSON-encoded strings. Using regular double-quotes and then using -quoted double quotes within the JSON string works for the systemd unit but not for systemd.

With this combination we can actually use toJSON to write those values without quoting hassle as a regular nix expression.

Includes a test that verifies we're getting this right for both ends.

Thanks: erikarvsted for even better quoting.

Description of changes

Improve quoting and add a test.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[ctheune]

This is a spin-off from #242084

[erikarvstedt]

Thanks, this is a duplicate of #242275, so I guess we can close this.

[ctheune]

Ouch. Interesting. I'll have to figure out how to do contributions properly. I usually have limited time frames to work on personal stuff and obviously I don't want to waste time duplicating effort. I decided to work on the issues in the original PR from top down instead of filling the whole slot I had with reading it and then not doing anything and having to come back again days later. Seems like that can quickly become a waste of time (not just for me).

Maybe extending the tests in the other PR is a valuable addition?

[erikarvstedt]

Maybe extending the tests in the other PR is a valuable addition?

toShellVars is already tested here, I don't think we should add this to the paperless test.
Feel free to reopen.

[ctheune]

Hmm. I'm not sure I understand. There was a regression in the paperless module that didn't depend on whether toShellVars is broken but the actual integration in paperless was. Shouldn't that be tested now that we caught it in a broken state?

[erikarvstedt]

Not a regression, this was once the intended behavior that got broken for the service env when the module was updated to paperless-ngx.
The code now makes it clear that var contents should be exported verbatim. A regression from this is unlikely.
Yes, in principle we could test this, but I think it's too trivial. (Weak preference.)

[ctheune]

Thanks for clarifying. Coming from a "100% test coverage" and "every regression gets a test" background I'm more on the cautious side. Something I can sympathize with is the amount of tests we run in total and reducing test coverage to a "sane minimum" ...