lix-project/lix

Fork 61

`--max-jobs 0` should still build drvs with `preferLocalBuild` according to docs #855

New issue

Open

opened 2025-06-10 02:52:11 +00:00 by bacchanalia · 3 comments

bacchanalia commented

2025-06-10 02:52:11 +00:00

Member

Describe the bug

The documentation for max-jobs states:

0 is useful when using remote builders to prevent any local builds (except for preferLocalBuild derivation attribute which executes locally regardless).

but contrary to the docs, derivations with preferLocalBuild set do not get built with --max-jobs 0

Steps To Reproduce

nix build --option substitute false --option builders '' --max-jobs 0 --impure --expr '(import ./. {}).writeText "preferLocalBuildWithMaxJobs0" ""'

Expected behavior

The above command succeeds.

`nix --version` output

nix (Lix, like Nix) 2.92.0

Additional context

I'm not sure if the documented behavior was ever actually the case, and the language is a but unclear, so I might be reading it wrong, but it would be very useful to have a setting to allow only building derivations with preferLocalBuild set. In some cases it may be desirable to disallow even those, so maybe ideally it should be a separate setting?

## Describe the bug The documentation for [max-jobs](https://docs.lix.systems/manual/lix/2.92/command-ref/conf-file.html?highlight=max-jobs#conf-max-jobs) states: > `0` is useful when using remote builders to prevent any local builds (except for `preferLocalBuild` derivation attribute which executes locally regardless). but contrary to the docs, derivations with `preferLocalBuild` set do not get built with `--max-jobs 0` ## Steps To Reproduce `nix build --option substitute false --option builders '' --max-jobs 0 --impure --expr '(import ./. {}).writeText "preferLocalBuildWithMaxJobs0" ""'` ## Expected behavior The above command succeeds. ## `nix --version` output `nix (Lix, like Nix) 2.92.0` ## Additional context I'm not sure if the documented behavior was ever actually the case, and the language is a but unclear, so I might be reading it wrong, but it would be very useful to have a setting to allow only building derivations with `preferLocalBuild` set. In some cases it may be desirable to disallow even those, so maybe ideally it should be a separate setting?

👍 1

bacchanalia added the

bug

label

2025-06-10 02:52:11 +00:00

jade added the

Area/store

label

2025-07-07 00:43:04 +00:00

raito added the

release-blocker

label

2025-11-18 02:36:08 +00:00

pennae added this to the 2.95 milestone

2025-12-01 14:51:31 +00:00

raito commented

2025-12-05 00:34:00 +00:00

Owner

It's a pretty weird feature I must say, fortunately, it doesn't create a situation where preferLocalBuilds just consumes arbitrary amount of tokens EXCEPT if you pass max-jobs = 0 and your graph is ENTIRELY composed of preferLocalBuilds = true…

It's a pretty weird feature I must say, fortunately, it doesn't create a situation where `preferLocalBuilds` just consumes arbitrary amount of tokens EXCEPT if you pass `max-jobs = 0` and your graph is ENTIRELY composed of `preferLocalBuilds = true`…

lix-bot commented

2025-12-05 00:34:42 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/4698 ("libstore/build: allow preferLocalBuild = true to bypass max-jobs = 0")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/4698](https://gerrit.lix.systems/c/lix/+/4698) ("libstore/build: allow `preferLocalBuild = true` to bypass `max-jobs = 0`")

bacchanalia commented

2025-12-05 05:42:12 +00:00

Author

Member

I think a more general solution, would be replace the concept of slots with more fine grained resources. Then you could set the defaults for preferLocalBuild vs not preferLocalBuild derivations separately. There are of course many design considerations for how to make such a system robust.

The main use case for this is, I think, to be able to build configuration files but to fail early if there is a cache miss for an actual package. In that case not having a setting to control slots is probably fine, as long as you actually trust derivations marked with preferLocalBuild are cheap. I think a more general solution, would be replace the concept of slots with more fine grained resources. Then you could set the defaults for preferLocalBuild vs not preferLocalBuild derivations separately. There are of course many design considerations for how to make such a system robust.