lib: add mapDir and mapDirFiles #63871
Conversation
|
Funnily enough, a much older implementation of what is basically the same thing can be found at http://chriswarbo.net/projects/nixos/useful_hacks.html under "Importing Directories". |
lib/filesystem.nix
Outdated
| @@ -42,4 +44,13 @@ | |||
| type = (builtins.readDir parent).${base} or null; | |||
| in file == /. || type == "directory"; | |||
| in go (if isDir then file else parent); | |||
|
|
|||
| mapDir = filter: f: path: | |||
There was a problem hiding this comment.
Should be called something like filterMapDir
There was a problem hiding this comment.
I think I saw something rather involved for recursing and filtering a directory tree (probably doing something else too) somewhere, I should probably look at that, if anyone remembers what it was.
There was a problem hiding this comment.
Maybe it was just locateDominatingFile from this same file. I suppose it would make sense to factor out the mapDir equivalent component. I didn't even notice the similarities when I was making the PR.
Edit: I would probably want to make a separate PR for that.
There was a problem hiding this comment.
Ok I added some documentation. Is it good?
|
Yeah thanks for making that explicit. I was sort of thinking about it, but I wasn't sure how to write the documentation without ending up overexplaining and saying the same exact thing as what reading the code would tell you. |
|
I share the opinion of @infinisil regarding having these functions. |
| # It doesn't recurse over subdirectories. | ||
| filterMapDir = filter: f: path: | ||
| #Sets are lexically sorted by key | ||
| let files = builtins.readDir path; |
There was a problem hiding this comment.
Why hard-code the readDir?
If you change the signature to take the resulting data structure of readDir instead of a Path, the user can chain multiple invocations (and do other transformations), and the function becomes more composable.
There was a problem hiding this comment.
My intention is to have a convenience function that lets you apply a function to a directory without having to do anything else, but sure, I don't see why I couldn't make another utility function that does what you said - and then use that to implement the convenience function.
There was a problem hiding this comment.
I’d argue it’s still convenient, as long as the usage is in the example. We already have waaaay too many non-composing functions in lib
|
I didn't think about this much, mostly note to self: but maybe |
|
Thank you for your contributions.
|
stale
bot
added
the
2.status: stale
stale
bot
removed
the
2.status: stale
|
I marked this as stale due to inactivity. → More info |
stale
bot
added
the
2.status: stale
|
Closing as abandoned |
Adds a function and a convenience function to
lib/filesystems.nixfor mapping a function over a directory.