You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently filtering a string with context is not possible as both builtins.filterSource1 and builtins.path2 throws an error in the form of string '<string>' cannot refer to other paths unless the context is empty.
This is a problem in general; filtering a path that is already filtered is not possible, as described in here. But it has a bigger implication with flakes and that is flake inputs cannot be filtered. This is important because flakes are not always inside the source repository they belong3, and source filtering has to be omitted in that case.
Describe the solution you'd like
I think this
... check if the context's paths are in state.allowedPaths rather than just checking if it is empty ...
as proposed by @tomberekin here would solve the problem. But I don't have enough knowledge with the codebase to say this wouldn't break anything.
Describe alternatives you've considered
While not a solution, one could use builtins.unsafeDiscardStringContext avoid the problem. But obviously, such things shouldn't be necessary.
Additional context
I wasn't sure whether to open this as a bug or as a feature request. Even if this isn't a bug, I think this deserves a high priority. Only other discussion I could find about this is this issue, which is unfortunate because it got sidetracked by another avoidable problem. @maisiliym was the main person that was talking about this problem456.
Is your feature request related to a problem? Please describe.
Currently filtering a string with context is not possible as both
builtins.filterSource
1 andbuiltins.path
2 throws an error in the form ofstring '<string>' cannot refer to other paths
unless the context is empty.This is a problem in general; filtering a path that is already filtered is not possible, as described in here. But it has a bigger implication with flakes and that is flake inputs cannot be filtered. This is important because flakes are not always inside the source repository they belong3, and source filtering has to be omitted in that case.
Describe the solution you'd like
I think this
as proposed by @tomberek in here would solve the problem. But I don't have enough knowledge with the codebase to say this wouldn't break anything.
Describe alternatives you've considered
While not a solution, one could use
builtins.unsafeDiscardStringContext
avoid the problem. But obviously, such things shouldn't be necessary.Additional context
I wasn't sure whether to open this as a bug or as a feature request. Even if this isn't a bug, I think this deserves a high priority. Only other discussion I could find about this is this issue, which is unfortunate because it got sidetracked by another avoidable problem. @maisiliym was the main person that was talking about this problem456.
Footnotes
https://github.com/NixOS/nix/blob/53e479428958b39a126ce15de85d7397fdcfe2e1/src/libexpr/primops.cc#L1904-L1908 ↩
https://github.com/NixOS/nix/blob/53e479428958b39a126ce15de85d7397fdcfe2e1/src/libexpr/primops.cc#L1991-L1995 ↩
See this as an example of a flake residing outside the source repository because the PR to add it to the upstream is not accepted. ↩
https://github.com/NixOS/nix/issues/3732#issuecomment-721478348 ↩
https://github.com/NixOS/nix/issues/3732#issuecomment-728683410 ↩
https://github.com/NixOS/nix/issues/3732#issuecomment-732028019 ↩
The text was updated successfully, but these errors were encountered: