lib.strings: deprecate lib.strings.{head,tail}

[FireyFly]

These operate on lists and error if you try to call them on strings... and they're already exposed under lib and lib.lists

Description of changes

• lib.strings.head is no longer an alias for builtins.head, ditto for tail

Things done

I checked (somewhat sloppily) for references with rg lib.strings.head, rg '\(lib.strings\) .*head, rg lib.strings.tail, rg \(lib.strings\) .*tail and didn't notice any. I checked that <nixpkgs> and <nixpkgs/nixos> evaluate (on my system/with my config) as well

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 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.

---

Add a 👍 reaction to pull requests you find important.

[eclairevoyant]

We should probably throw an actual error message (or possibly even simply warn for now) to explain why it would be removed

[FireyFly]

Yep, that's very fair, you're probably right... I think after a period it'd be nice to fully remove them though since they still show up in e.g. tabcompletion in the REPL otherwise..

I figured in this case it might make sense to be a bit more bold than usual for deprecation since well... the existing functions don't even work on strings (so chances are pretty slim anyone depends on importing these from lib.strings and using them on lists, honestly)

[eclairevoyant]

chances are pretty slim anyone depends on importing these from lib.strings and using them on lists, honestly

You'd be surprised what people do, especially accidentally, since nix lacks robust static analysis

[FireyFly]

I updated the PR to warn instead of fully remove the functions, to offer a grace period for people to correct any eventual use of lib.strings.{head,tail}

[infinisil]

Just some relatively minor comments, but otherwise this looks good!

[infinisil]

Imo it's a bit overkill to abstract such an error message, and as implemented this actually slows down lib evaluation a little bit, because of the extra // used. I think it would be fine to just inline the error twice

[FireyFly]

Ah, I pulled it out because the main attrset is rec and already uses head/tail a few times but we can change the couple uses to explicit builtins.{head,tail} in the file

[FireyFly]

I moved it into the main rec {} attrset with exports and changed occurrences of head/tail in the file to use builtins.{head,tail} explicitly

[infinisil]

Just a minor comment, looking good after that!

[infinisil]

Instead of doing this, you can add

  inherit (lib) head tail;

to the top let in

(the preference should be to get symbols from lib, because it's more flexible)

[FireyFly]

The problem with that is the top-level let-in is above the rec { } attrset where we define the deprecated head and tail with warnings... so any unqualified references will refer to those and throw warnings.

(That's why at first I had pulled those deprecated attributes out into a separate attrset that was merged in with // before...)

I can access the functions from lib instead of builtins though if that's preferred

[FireyFly]

Moved to using lib.{head,tail} instead of builtins.{head,tail} as requested. As mentioned I don't see how a let-inherit would help here since the head/tail with warnings in the returned recursive attrset would shadow them. Please let me know if I'm missing something, or if there's a different approach you would prefer...