Lix config doesn't support SI units for sizes in config #894
Labels
No labels
Affects/CppNix
Affects/Nightly
Affects/Only nightly
Affects/Stable
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/lix ci
Area/nix-eval-jobs
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/repl/debugger
Area/store
bug
Context
contributors
Context
drive-by
Context
maintainers
Context
RFD
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Language/Bash
Language/C++
Language/NixLang
Language/Python
Language/Rust
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
Topic/Large Scale Installations
ux
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#894
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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: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:
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
outputAdditional context
An obvious workaround would of course be to do the math and putting an integer without any suffix there.
This got introduced into CppNix in 79c7d6205c2f06cb2f0c00ea5cdfbdad5b7befa4.
https://gerrit.lix.systems/c/lix/+/3554
This issue was mentioned on Gerrit on the following CLs:
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 make1
and1k
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).
Lix config doesn't support SI units in configto Lix config doesn't support SI units for sizes in configYeah, 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?
tracking it here is good. we also created a new project for the config issues, we already have (at least) three now and
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.)
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.
Ah, I’m sorry for missing that!