Lix config doesn't support SI units for sizes in config #894

Open
opened 2025-06-30 22:01:34 +00:00 by flokli · 9 comments

Describe the bug

I got a report from someone currently using CppNix giving Lix a test-run.

Apparently Nix started supporting SI suffixes for config options at some point.

Their nix.conf lists has the following lines:

max-free = 50G
gc-reserved-space = 512M
min-free = 1G

Running such a config with CppNix (or passing it to the CLI via --option max-free 50G --option gc-reserved-space 512M --option min-free 1G) works without any problems.

However, when switching to Lix, it throws a warning and fails to parse the option, ignoring them being set:

nix-collect-garbage --option max-free 50G --option gc-reserved-space 512M --option min-free 1G
warning: error: setting 'max-free' has invalid value '50G'
warning: error: setting 'gc-reserved-space' has invalid value '512M'
warning: error: setting 'min-free' has invalid value '1G'

Expected behavior

I'd expect Lix to also support these values, if there's no strong reason not to, to reduce friction when moving impls.

nix --version output

nix (Lix, like Nix) 2.91.3

Additional context

An obvious workaround would of course be to do the math and putting an integer without any suffix there.

## Describe the bug I got a report from someone currently using CppNix giving Lix a test-run. Apparently Nix started supporting [SI suffixes](https://github.com/NixOS/nix/issues/2469) for config options at some point. Their `nix.conf` lists has the following lines: ``` max-free = 50G gc-reserved-space = 512M min-free = 1G ``` Running such a config with CppNix (or passing it to the CLI via `--option max-free 50G --option gc-reserved-space 512M --option min-free 1G`) works without any problems. However, when switching to Lix, it throws a warning and fails to parse the option, ignoring them being set: ``` nix-collect-garbage --option max-free 50G --option gc-reserved-space 512M --option min-free 1G warning: error: setting 'max-free' has invalid value '50G' warning: error: setting 'gc-reserved-space' has invalid value '512M' warning: error: setting 'min-free' has invalid value '1G' ``` ## Expected behavior I'd expect Lix to also support these values, if there's no strong reason not to, to reduce friction when moving impls. ## `nix --version` output > nix (Lix, like Nix) 2.91.3 ## Additional context An obvious workaround would of course be to do the math and putting an integer without any suffix there.
Author

This got introduced into CppNix in 79c7d6205c2f06cb2f0c00ea5cdfbdad5b7befa4.

This got introduced into CppNix in [79c7d6205c2f06cb2f0c00ea5cdfbdad5b7befa4](https://github.com/NixOS/nix/commit/79c7d6205c2f06cb2f0c00ea5cdfbdad5b7befa4).
Author
https://gerrit.lix.systems/c/lix/+/3554
Member

This issue was mentioned on Gerrit on the following CLs:

  • commit message in cl/3554 ("Support unit prefixes in configuration settings")
<!-- GERRIT_LINKBOT: {"cls": [{"backlink": "https://gerrit.lix.systems/c/lix/+/3554", "number": 3554, "kind": "commit message"}], "cl_meta": {"3554": {"change_title": "Support unit prefixes in configuration settings"}}} --> This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/3554](https://gerrit.lix.systems/c/lix/+/3554) ("Support unit prefixes in configuration settings")
Owner

in theory this is great. in practice we'd want a lot more than just "case-insensitive multiplier suffix". while that is okay when the unit is implicit and the casing is unambiguous because eg a millibyte makes no sense, it really just doesn't do in general. the current setting system also doesn't have any way to attach units to things at all. for some settings this would be detrimental, eg downlad-speed: with no unit applied it's kilobytes, and taking the simple approach would make 1 and 1k mean completely different things.

having units on settings would be great, but we really need a more principled approach to this that doesn't lock us into supporting broken bullshit behavior forever. in light of this we're half convinced that we shouldn't do this at all for the current config, only for a new config format (eg toml).

in theory this is great. in practice we'd want a lot more than just "case-insensitive multiplier suffix". while that is okay when the unit is implicit and the casing is unambiguous because eg a millibyte makes no sense, it really just doesn't do in general. the current setting system also doesn't have any way to attach units to things at all. for some settings this would be *detrimental*, eg `downlad-speed`: with no unit applied it's kilobytes, and taking the simple approach would make `1` and `1k` mean completely different things. having units on settings would be great, but we really need a more principled approach to this that doesn't lock us into supporting broken bullshit behavior forever. in light of this we're half convinced that we shouldn't do this *at all* for the current config, only for a new config format (eg toml).
flokli changed title from Lix config doesn't support SI units in config to Lix config doesn't support SI units for sizes in config 2025-07-01 08:45:37 +00:00
Author

Yeah, the current implementation is unfortunate, being able to use these modifiers for timeout values, or the start uid for dynamic user allocation is garbage.

I'm happy to defer this request to the new config format you're planning, and getting the semantics right there.

Do you want to track the idea in here, or is there another tracking issue for everything regarding the new config format?

Yeah, the current implementation is unfortunate, being able to use these modifiers for timeout values, or the start uid for dynamic user allocation is garbage. I'm happy to defer this request to the new config format you're planning, and getting the semantics right there. Do you want to track the idea in here, or is there another tracking issue for everything regarding the new config format?
Owner

tracking it here is good. we also created a new project for the config issues, we already have (at least) three now and

tracking it here is good. we also created a new project for the config issues, we already have (at least) three now and
Member

Note that in Nix these are not the corresponding SI prefixes, but instead power‐of‐two units misusing the symbols of SI prefixes. Many desktop operating systems report storage with correct use of decimal SI prefixes these days, and of course data throughput is often expressed using (decimal) megabits/gigabits, so this is not just a nitpick. If whatever Lix does here is not going to be compatible with Nix’s format anyway, then I strongly suggest that if “1 MB” is supported it means 1000000 bytes, and if “1 MiB” is supported it means 1048576 bytes. (It would be okay to choose to only support one of those, but not to mix up the prefixes.)

Note that in Nix these are *not* the corresponding SI prefixes, but instead [power‐of‐two units](https://en.wikipedia.org/wiki/Byte#Units_based_on_powers_of_2) misusing the symbols of SI prefixes. Many desktop operating systems report storage with correct use of decimal SI prefixes these days, and of course data throughput is often expressed using (decimal) megabits/gigabits, so this is not just a nitpick. If whatever Lix does here is not going to be compatible with Nix’s format anyway, then I strongly suggest that if “1 MB” is supported it means 1000000 bytes, and if “1 MiB” is supported it means 1048576 bytes. (It would be okay to choose to only support one of those, but not to mix up the prefixes.)
Owner

We did notice that in the CL that @flokli backported and the reason for why we discussed the various options here.

@pennae rightly prefer to have proper SI suffixes.

We did notice that in the CL that @flokli backported and the reason for why we discussed the various options here. @pennae rightly prefer to have proper SI suffixes.
Member

Ah, I’m sorry for missing that!

Ah, I’m sorry for missing that!
Sign in to join this conversation.
No milestone
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#894
No description provided.