libucl: init at 0.8.1

[jpotier]

Motivation for this change

libucl is a dependency for Hikari (#89414)

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[OPNA2608]

The library seems to have afew configure options that are set to off be default, maybe you want to look into enabling and adding derivation options for them?

There are

• optional utilities based on the library
• optional functionalities like regex / signature checks and url support as well as
• a version of the library that can be used with Lua.

See configure.ac.

[jpotier]

The library seems to have afew configure options that are set to off be default, maybe you want to look into enabling and adding derivation options for them?

There are

* optional utilities based on the library

* optional functionalities like regex / signature checks and url support as well as

* a version of the library that can be used with Lua.

See configure.ac.

That's a nice pointer, I'll look into this a bit later.

[jpotier]

Signatures support seems out of reach at least for this version of the package: vstakhov/libucl#203

[doronbehar]

This will make your future diff after vstakhov/libucl#203 will be resolved even cleaner.

BTW for extra credit, assuming you are fluent with Nix, you could use an attribute set in the inputs instead of those multiple enableThis disableThat flags and use https://nixos.org/nixpkgs/manual/#function-library-lib.strings.enableFeature

[jpotier]

you could use an attribute set in the inputs instead of those multiple enableThis disableThat flags

Do you mean:

{ urls = true;
, regex = false;
, ...}

?

[doronbehar]

Do you mean

No. Maybe start like this:

{ stdenv
, ...
, ...
, features ? {
    urls = true;
    regex = true;
  }
}:

And then when setting configureFlags, you could use https://nixos.org/nixpkgs/manual/#function-library-lib.attrsets.mapAttrs .

[doronbehar]

Why disable by default?

[jpotier]

I'm reflecting how this is set when you build from source. I'm not familiar with this lib, so I'm assuming all the non default options are extras.

[doronbehar]

Could it be they are disabled if the necessary deps are not found? It's a common practice to make the build not fail but disable optional features if they are not explicitly enabled.

[jpotier]

Maybe yeah. I'm really unsure on what approach to take here. On the other end of the spectrum, enabling everything, seems a bit overkill too.

[doronbehar]

@jpotier I'm making these suggestion because I think they are cool but you don't have to go with them. I just sometimes wish to encourage contributors not to afraid of writing nontrivial Nix expressions into packages. I suggest this under the hope that a committer won't object to add such a "complicated" Nix code for a simple library - due to a maintenance reasoning. See e.g: #87940 (comment) .

[jpotier]

@jpotier I'm making these suggestion because I think they are cool but you don't have to go with them. I just sometimes wish to encourage contributors not to afraid of writing nontrivial Nix expressions into packages. I suggest this under the hope that a committer won't object to add such a "complicated" Nix code for a simple library - due to a maintenance reasoning. See e.g: #87940 (comment) .

Oh :/ Too bad your changes weren't merged. I think using the language as much as possible is good, and I definitely like you pushing for these changes I made, and I think they make sense. Of course, these sort of changes should be evaluated on a case-by-case basis.

[doronbehar]

Oh :/ Too bad your changes weren't merged.

Don't worry I got what I wanted at #87949 :).

[doronbehar]

.

[doronbehar]

@GrahamcOfBorg build libucl

[jpotier]

Alright, I guess this is ready for merging