Shouldn't we just propagate packageOverrides?

packageOverrides doesn't seem to have the expectation that every defined packageOverrides key will be propagated to the developer environment. (E.g. couldn't someone create one set of packageOverrides and use it for all their hooks?)

I'm also not quite sure how that would work with e.g. treefmt -- I suppose treefmt could just implicitly use all the packageOverrides values as formatters, but it seems a little clumsy. What do you think?

E.g. couldn't someone create one set of packageOverrides and use it for all their hooks

We should remove packageOverrides from the base hook module. It was a mistake on my part to add it there. It doesn't do anything by default and the only 3 hooks that use it overload the option anyway.

It's sole purpose is to provide an access point to override specific dependencies for hooks that have them. And the reason it's an attrset and not a list of packages (like extraPackages) is so that the package names show up in the docs. I initially wanted to expose the wrapper packages for these hooks and let people use overrides, but I wasn't sure how to document this. So we compromised.

I'm also not quite sure how that would work with e.g. treefmt -- I suppose treefmt could just implicitly use all the packageOverrides values as formatters, but it seems a little clumsy. What do you think?

Yeah, treefmt is not like the other hooks. That's why treefmt.settings.formatters exists.

@domenkozar, I quite like this actually. packageOverrides doesn't fit the bill because we have hooks like treefmt and dune-fmt.

internal?

I've argued for a category of "advanced" options, a middle ground, but that's controversial, in the context of NixOS at least.

• Advanced options NixOS/nixpkgs#257300

We could also replace packageOverrides with individual package options.

We could also replace packageOverrides with individual package options.

That's what we're doing now, no? Or do you have something else in mind?

That's what we're doing now, no? Or do you have something else in mind?

Oh, I see. I thought it was an arbitrary attrset of packages for some reason.

Maybe we should remove the packageOverrides level then, so that overriding packages can be done with package for the main package and (e.g.) cargo and clippy for the others (rather than packageOverrides.cargo`).

Maybe we should remove the packageOverrides level then, so that overriding packages can be done with package for the main package and (e.g.) cargo and clippy for the others (rather than packageOverrides.cargo`).

Maybe 🤷 The extra level excludes the (admittedly unlikely) possibility of naming conflicts with other pre-commit options.