The name suggests a parallel with lib.optional : Bool -> a -> List a, but there isn't one.
How about unchecked instead?

OT: I would quite like to have fileset.optional : Bool -> FileSet -> FileSet such that optional false x == fileset.empty. Example:

mkDerivation(finalAttrs: {
  src = fileset.unions [
    ./src
    (fileset.optional finalAttrs.doCheck ./tests)
  ];
})

The name suggests a parallel with lib.optional : Bool -> a -> List a, but there isn't one.
How about unchecked instead?

Hmm good point, not a fan of unchecked though, makes me ask the question what property is not being checked, and whether this is an unsafe operation.

Some other ideas:

• lib.fileset.optionalIfExists ./generated.o -> Meh, it's not optional if it does exist, then it's definitely included
• lib.fileset.ifExists ./generated.o -> If it exists then what? Does this return a bool?
• lib.fileset.try ./generated.o -> Doesn't say what is being tried
• lib.fileset.tryCoerce ./generated.o -> Does make sense, but maybe a bit too odd of a word
• lib.fileset.tryFrom ./generated.o -> Not bad imo, nicer word than coerce
• lib.fileset.maybe ./generated.o -> Not bad imo, though it doesn't match Haskell's maybe
• lib.fileset.maybeMissing ./generated.o -> A bit more explicit, but a bit long

I think I like lib.fileset.tryFrom the most, which could also lead to a lib.fileset.from that does coercion but fails for missing files in case that's ever needed.

OT: I would quite like to have fileset.optional : Bool -> FileSet -> FileSet such that optional false x == fileset.empty.

Oh that sounds nice, should be fairly easy to add too.

OT: I would quite like to have fileset.optional : Bool -> FileSet -> FileSet such that optional false x == fileset.empty

Is this actually required? You can already use lib.optional(s) and have the result coerced to a fileset.

@roberth @alyssais I migrated (and replied to) our discussion on lib.fileset.optional :: Bool -> FileSet -> FileSet to a new issue: #266106

• lib.fileset.maybe ./generated.o -> Not bad imo, though it doesn't match Haskell's maybe

• We don't have Haskell's Maybe in the first place. nullOr might feel similar but is very very different (in the context of a standard library).
• maybe is kinda bad, for reasons that point-free is bad.

So I wouldn't be too concerned about this name in general, but I don't think it's specific enough.

• lib.fileset.tryFrom ./generated.o

Still doesn't say what's tried.

My favorite from your list is maybeMissing.

What about whenExists?

What about whenExists?

Also doesn't indicate what happens when it exists.

I'll just go for maybeMissing (though should it be mayBeMissing instead?), seems like the least evil.

What about whenExists?

Also doesn't indicate what happens when it exists.

I'm used to Haskell's when which "does" nothing when false. It could be read as "only when exists", with the implied alternative of nothing (empty).

mayBeMissing

Correct, but I predict 50% will mistype.

I'm worried the interface is growing faster than adoption of the library warrants. This issue could be stop-gapped with an example in the documentation, because the use case can be implemented with what's already there.

If it turns out to be a heavily used pattern one can still add a convenience layer.

Right now I'd prefer efforts being directed to making good use of existing facilities, evolving some usage patterns, and adding more practical examples to the docs.

This particular use case I also encountered while working on the original WIP, and @alyssais being one of the first users and immediately running into it too gives me the feeling we should support this. The alternative without this function is too verbose:

unions (lib.optional (builtins.pathExists ./generated.o) ./generated.o))

# With this PR:
maybeMissing ./generated.o

Even just the fact that the path needs to be repeated will make anybody needing this want to write a function for it! I think lib.fileset should be a batteries-included library that just lets you do what you need to do, without having to create extra functions or write boilerplate.

FWIW: all I'm trying to do is replace this very simple use of cleanSource(With), and then add some additional filtering on top for individual components. I'd consider this a fairly basic use case.

@infinisil how would you feel about having lib.fileset.difference implicitly handle missing files in its second argument? It's used for filtering out files you don't want, so I'm not sure when you'd ever care that they didn't exist, and otherwise IIUC you need to lib.fileset.difference set (lib.unions (map lib.fileset.maybeMissing [ … ])), which is pretty boilerplate-y. I'd understand if it felt like too much magic to you, though.

Hmm that doesn't always make sense though, because you can also do difference ./. (difference ./foo ./foo/bar), where ./foo/bar would be included in the end and so has to exist.

Maybe the check for files existing could be pushed further down generally though, I'll look into that.

Right! That reminds me of the function type operator, which also have a binary property that flips in one of the operands, and flips back when the operator is nested: covariance/contravariance aka positive/negative.

Seems to reinforce the idea that you can negate a contextual boolean (ie argument to some internal function) whenever you process a difference rhs.

Unfortunately the difference ./. (difference ./foo ./foo/bar) case doesn't work out with the current internal representation, but otherwise it's totally doable, check out #267091!

Since we decided against doing #267091, we should have maybeMissing after all.

I rebased on top of master, this would be ready from my side.

Rebased again, still good from my side :)

Ready to be merged again from my side

I'll soon merge this myself so we can unblock NixOS/nix.dev#802 :)

Successfully created backport PR for release-23.11:

• [Backport release-23.11] lib.fileset.maybeMissing: init #269259