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
lib.fileset does not support filtering of store paths. Rationale for that should be added to the file set library design decisions so I can link to it in the future.
Note that if you need to filter a lib.sources value, that will be supported soon with #261732.
Reasons for lib.fileset not supporting store paths:
lib.fileset guarantees that it prevents files that aren't selected from being added into the store, such that changing them doesn't cause a rebuild. But if you filter a store path, all those files are already in the store and will always cause a rebuild if changed, no matter if you filter them out afterwards, so it couldn't guarantee the same. The use case is different.
Store paths are only known at build time, but lib.fileset (and lib.sources) rely on builtins.path to do the filtering, which runs at evaluation time, so using it on store paths would require IFD, when it wouldn't be necessary
Instead, functions for filtering store paths could be much more powerful by using a build-time derivation to do the filtering. And such an interface wouldn't have to be limited to just filtering, it could also rename, add and move paths. In fact you can do this already today, though it's not very pretty:
lib.fileset is made very convenient and safe because it supports Path expression syntax to specify paths to include/exclude, like unions [ ./foo ./bar ]. There's no equivalent you could use for store paths with the same properties (using strings "./foo", "./bar" would have to delay checking of file existence and computations on trees to build time to avoid IFD).
lib.fileset
does not support filtering of store paths. Rationale for that should be added to the file set library design decisions so I can link to it in the future.Note that if you need to filter a
lib.sources
value, that will be supported soon with #261732.Reasons for
lib.fileset
not supporting store paths:lib.fileset
guarantees that it prevents files that aren't selected from being added into the store, such that changing them doesn't cause a rebuild. But if you filter a store path, all those files are already in the store and will always cause a rebuild if changed, no matter if you filter them out afterwards, so it couldn't guarantee the same. The use case is different.lib.fileset
(andlib.sources
) rely onbuiltins.path
to do the filtering, which runs at evaluation time, so using it on store paths would require IFD, when it wouldn't be necessarypkgs.transformStorePath
to take care of the boilerplate, this is tracked in Function for transforming store path contents #264541lib.fileset
is made very convenient and safe because it supports Path expression syntax to specify paths to include/exclude, likeunions [ ./foo ./bar ]
. There's no equivalent you could use for store paths with the same properties (using strings "./foo", "./bar" would have to delay checking of file existence and computations on trees to build time to avoid IFD).Originally posted by @infinisil in #188301 (comment)
This work is sponsored by Antithesis ✨
The text was updated successfully, but these errors were encountered: