Home • Explore • Blog • Models • CI
☰



nixpkgs
5th chunk of `lib/fileset/README.md`
0a9cd3cc2463fa8fbf2c463b82a33f44cfad3b435bbc9389000000010000084b
    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`
Title: Nixpkgs File Set Design Rationale: Store Paths, Single Files, and `fileFilter` API
Summary
This document elaborates on specific design choices and limitations of the Nixpkgs file set abstraction. It argues against using file sets for manipulating Nix store paths (strings) because the abstraction is primarily intended for specifying files to be *imported into* the store, not for transforming files already present. For existing store paths, a separate, more powerful abstraction like `pkgs.drvLayout` is suggested, which could support operations like renaming or adding files that are not possible at evaluation time. The document also explains that file sets cannot handle single files directly, as there's no meaningful filtering use case, and an 'empty' result for a single file is ill-defined. Finally, it points out that the `fileFilter` function's design, which accepts a path rather than a file set as its second argument, hinders function composition.