Nixpkgs: Add enableIfSupported helper

[shlevy]

Some packages don't make sense on some platforms, either because of core OS support (e.g. libseccomp on darwin) or because of missing support in the code. Other packages would like to depend on them, but only if they're supported. A helper like enableIfSupported that could be used like buildInputs = [ (enableIfSupported libseccomp) ] would be a nice way to generally express this pattern.

Action item from #35906

[7c6f434c]

Do I understand correctly that in the current Nixpkgs the entire implementation can be

{
  enableIfSupported = x: if (builtins.tryEval outPath).success then x else null;
  enableIfSupportedLight = x: if x.meta.available then x else null;
  enableAllSupported = builtins.map enableIfSupported;
}

or is there a more ambitious plan?

[shlevy]

@7c6f434c Possibly yeah, though I'm not sure if we want to reuse the same flags that nix-env uses or not.

[7c6f434c]

My reading of the src/libexpr/get-drvs.cc file (namely, the static bool getDerivation function) is that it is exactly the same as the tryEval function.

[Ericson2314]

@7c6f434c I don't think we want the "heavy" version. We should be avoiding ad-hoc asserts in package especially after https://github.com/NixOS/nixpkgs/pull/34444/ lands.

[7c6f434c]

Well, platforms is only a part of the problem anyway, there are more interesting asserts. Heavy version is closer to nix-env behaviour.

[Ericson2314]

@7c6f434c one can do arbitrary predicate for meta.broken instead of assert, right?

I view the overall nix-env policy as working around broken nix code in nixpkgs, rather than known-broken packages. We should fail fast except for at the outer level.

[7c6f434c]

One can, but not everyone does. Or do you want to create a tracking issue for assert in packages?

[Ericson2314]

Maybe I should.

[7c6f434c]

Less than 600 files right now.

[Ericson2314]

seems doable :D

[7c6f434c]

Between 507 and 551, still polishing the regex…

[Ericson2314]

Cool, thanks for leading the charge @7c6f434c!

[7c6f434c]

Created the issue. Confitional on general support to #36229 I agree that tryEval should not be used when we can avoid it.

[oxij]

While I'm :+1: on making those things explicit, I'm :-1: on nulls.

I would love to hear any comments about my issue with nulls from https://github.com/NixOS/nixpkgs/issues/35906#issuecomment-369465393

Why not platformBuildInputs? Its even more explicit than this and the impl can be changed at will in stdenv.mkDerivation and not by search and replace in the whole nixpkgs.

[7c6f434c]

I think we have a combinatorial explosion of kind of inputs. Build-host-target combinations, propagation, optionality…

I would prefer to have as much of this madness as possible to be supported inside a single input list, with splitting it being optional.

I agree that

{
  enableAllSupported = builtins.filter (x: x.available);
}

may be a better implementation for multiple-input version, but I do want a single-input marker for optional inputs.

[oxij]

See also https://github.com/NixOS/nixpkgs/issues/36229#issuecomment-370155254 on why you want to have no nulls.

[oxij]

I think we have a combinatorial explosion of kind of inputs. Build-host-target combinations, propagation, optionality…

I would prefer to have as much of this madness as possible to be supported inside a single input list, with splitting it being optional.

I agree that can be a bit of a problem, but

• I'm not sure single list idea can be reasonably implemented. How would you distinguish between using a tool like pkgconfig at build time from linking against a lib it provides to and using it at run time in a single list?

• I fear that you would end up pushing most of that combinatorial explosion into filtering (i.e. onto derivation authors).

[oxij]

I agree that

{
  enableAllSupported = builtins.filter (x: x.available);
}

may be a better implementation for multiple-input version, but I do want a single-input marker for optional inputs.

Hm, why not something like (replace supported with available if so desired, but I still think available is too lax for this)

whenSupported = optional (x: x.supported)
whenSupporteds = builtins.filter (x: x.supported)

with the intended use similar to optional and optionals then?

[7c6f434c]

I want all that to be eventually composable.

We already ask package maintainers to split things in all this range from buildInputs to propagatedBuildNativeInputs etc. I want to be able to write something like buildInputs=[ opencv (propagated (enableIfSupported (alsoNative pkgconfig))) ]; to replace multiplicative combinatorial explosion with an additive one. I do want to have an option to do this without splitting the list of inputs into a lot of lists.

[Ericson2314]

C.F. https://github.com/NixOS/nixpkgs/commit/b0482248fefbf3b6cdd9c92053cfb49778a3a3a8#commitcomment-28303812 interaction with config.allowBroken.

[shlevy]

oh, i guess this is closed now though

[Ericson2314]

It's lib.meta.enableIfSupported at https://github.com/NixOS/nixpkgs/blob/master/lib/meta.nix#L90 for the record.

[oxij]

Hm, so, for the record, what happened to this thing? I see no traces of it in the lib.

[7c6f434c]

It is in lib.meta but not in lib, I think