File Set Library: API Design Decisions - Single Files and `fileFilter` Argument

Verbose and dangerous because if `root` was a path, the entire path would get imported into the store. - `toSource { root = "/nix/store/...-source"; fileset = union "./foo" "./bar"; }` Does not allow debug printing intermediate file set contents, since we don't know the paths contents before having a `root`. - `let fs = lib.fileset.withRoot "/nix/store/...-source"; in fs.union "./foo" "./bar"` Makes library functions impure since they depend on the contextual root path, questionable composability. - (+) The point of the file set abstraction is to specify which files should get imported into the store. This use case makes little sense for files that are already in the store. This should be a separate abstraction as e.g. `pkgs.drvLayout` instead, which could have a similar interface but be specific to derivations. Additional capabilities could be supported that can't be done at evaluation time, such as renaming files, creating new directories, setting executable bits, etc. - (+) An API for filtering/transforming Nix store paths could be much more powerful, because it's not limited to just what is possible at evaluation time with `builtins.path`. Operations such as moving and adding files would be supported. ### Single files File sets cannot add single files to the store, they can only import files under directories. Arguments: - (+) There's no point in using this library for a single file, since you can't do anything other than add it to the store or not. And it would be unclear how the library should behave if the one file wouldn't be added to the store: `toSource { root = ./file.nix; fileset = <empty>; }` has no reasonable result because returning an empty store path wouldn't match the file type, and there's no way to have an empty file store path, whatever that would mean. ### `fileFilter` takes a path The `fileFilter` function takes a path, and not a file set, as its second argument. - (-) Makes it harder to compose functions, since the file set type, the return value, can't be passed to the function itself like `fileFilter predicate fileset`

This section outlines API design decisions for the file set library regarding single files and the `fileFilter` function. It argues against allowing the addition of single files, citing redundancy and unclear behavior with empty file sets. The discussion then covers the choice of having `fileFilter` take a path as an argument instead of a file set, acknowledging a potential reduction in composability but suggesting alternative solutions for composing file set operations.