lib.strings: Prevent paths as inputs in some functions#221204
lib.strings: Prevent paths as inputs in some functions#221204infinisil merged 3 commits intoNixOS:masterfrom
Conversation
lib/strings.nix
Outdated
There was a problem hiding this comment.
| if isPath pref then throw '' | |
| lib.strings.hasPrefix: The first argument (${toString pref}) is a path, which is not supported'' | |
| # Before 23.05, strings would be added to the store before comparing. This was too unexpected. | |
| if isPath pref then throw '' | |
| lib.strings.hasPrefix: The first argument (${toString pref}) is a path value, but only strings are supported.'' |
Leave a clue in case users encounter this in their code base, so they know something has changed here. It appears in the code block of the stack trace iirc. The exception message does not include the whole history, because I don't expect that to be productive. It could stick around for years being unnecessarily noisy.
There was a problem hiding this comment.
Sounds good, but "only strings are supported" isn't entirely correct, all stringLike values (including outPath, __toString) are supported, except paths. Maybe that's good enough though
There was a problem hiding this comment.
Right. Probably best to keep it simple and avoid unnecessary dissonance?
This can only be cured with poetry. Cue ChatGPT:
Here is a revised limerick about type coercions in programming:
Type coercion can be quite slick,
To convert data types that don't mix.
But if you're not careful,
Your code can be awful,
And bugs will give your code a big kick.
There was a problem hiding this comment.
Haha nicely done 😆
I agree, let's keep it simple, I applied this suggestion to all the error messages (also the normalizePath one).
f2d6bd4 to
d9cbdc5
Compare
There was a problem hiding this comment.
This is a breaking change and at the very least needs release notes. Almost certainly this will error out on someone in production. We may even want to phase this in with a warning or setting. Who else should we ask to make that decision? @roberth opinions?
d9cbdc5 to
7101e4b
Compare
|
Hmm yeah I guess it's a breaking change, even if the code we break is certainly a bug (in case of I changed the errors to a warning instead and added some more explanatory text to them. |
addf8c4 to
c518535
Compare
|
Have to take the space bar heaters into account... been there myself. |
lib.{hasPrefix,hasInfix,hasSuffix} would otherwise return an
always-false result, which can be very unexpected:
nix-repl> lib.strings.hasPrefix ./lib ./lib/meta.nix
false
There's no need to call this function on path data types, and it's confusing with the new lib.path library functions
c518535 to
5e8b9de
Compare
|
I also noticed that |
…rguments See also parent commits
15a8230 to
61012f6
Compare
|
I think this looks good and would like to merge it soon |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Description of changes
Some functions in
lib.stringscould lead to unexpected results when path data types are passed. This is confusing withlib.pathnow existing and being extended.This work is sponsored by Antithesis ✨