Add 'poison' context

[9999years]

This can be added to strings to prevent them from being used in derivations. This lets us implement "unstable" functions without fear!

Motivated by #10206.

• Closes Poison pill string context #8388

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[roberth]

I like the idea, and I've linked my description/proposal issue in the PR description.

Besides the review comments, I have two points of attention

• builtins.unsafeDiscardStringContext: does it throw when it encounters the poison? I think it should (despite the unsafe qualifier)

• This adds a new cross-cutting responsibility to the evaluator and its callers. What can we do to make the Value and string context API safer? Perhaps the raw string value could be encapsulated behind getters that make the intent of the caller clear.

  • No context allowed
  • Normal dependencies (store paths, outputs) allowed
  • Diagnostics and dependencies allowed

[L-as]

You can still use them in derivations with some processing, albeit it's going to be much harder.
Why not just build the functionality directly into builtins.trace, if you're only going to pass it to builtins.trace?

[lf-]

* `builtins.unsafeDiscardStringContext`: does it throw when it encounters the poison? I think it should (despite the unsafe qualifier)

Personally I think you should be allowed to deliberately shoot yourself in the foot, lest we accidentally create a need for alternative string context discarding functions. The point of this to me is to stop mistakes, rather than limit possible expression.

[9999years]

Why not just build the functionality directly into builtins.trace, if you're only going to pass it to builtins.trace?

Assuming "the functionality" is "pretty-printing values for debugging":

builtins.trace already prints values in debug-form when you pass it a single value, but often (especially in the case of warning messages) you want to pass it a string containing an interpolated value:

https://github.com/NixOS/nixpkgs/blob/4907e7a50c83b6214239d30a833f59493754eb48/nixos/modules/misc/documentation.nix#L54
https://github.com/NixOS/nixpkgs/blob/4907e7a50c83b6214239d30a833f59493754eb48/lib/meta.nix#L143
https://github.com/NixOS/nixpkgs/blob/4907e7a50c83b6214239d30a833f59493754eb48/pkgs/top-level/release-attrpaths-superset.nix#L160

In that case, you're stuck with the default toString function (which errors when passed many sorts of values). To work around this, nixpkgs has implemented a kind of crappy pretty-printer themselves:

https://github.com/NixOS/nixpkgs/blob/4907e7a50c83b6214239d30a833f59493754eb48/lib/generators.nix#L355-L368

builtins.toStringDebug will also be useful in assert messages/errors (builtins.throw, lib.assertMsg).

[L-as]

You could make string interpolation lazy, and then depending on how you use the resulting string, you could get the behavior you want. So builtins.trace "${x}" y could show a different string rather than builtins.derivation { src = "${x}"; }. In fact, for a string interpolation, you could carry around the expanded version with version-dependent debug information along with the original one, using the original one for all operations except the ones that print it to the user.

I'm not sure this complexity is worth it, but I don't think it would be very complex to implement.

[roberth]

Why not just build the functionality directly into builtins.trace, if you're only going to pass it to builtins.trace?

We could make it accept a "data-only" DSL. Maybe not go overboard with tons of functionality like #7795, but maybe implement what this issue calls MVP.

• Structured markup for throw and trace messages that make Nix more robust #7795

Not sure if we want to force such a representation on library authors, so maybe there's a case for both solutions to exist eventually.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-03-11-nix-team-meeting-132/42960/1