update and fix build with latest Lix #14

Merged
jade merged 3 commits from fixes/build-settings-opeq into main 2024-11-09 20:50:47 +00:00
2 changed files with 25 additions and 33 deletions

View file

@ -23,11 +23,11 @@
]
},
"locked": {
"lastModified": 1722555600,
"narHash": "sha256-XOQkdLafnb/p9ij77byFQjDf5m5QYl9b2REiVClC+x4=",
"lastModified": 1727826117,
"narHash": "sha256-K5ZLCyfO/Zj9mPFldf3iwS6oZStJcU4tSpiXTMYaaL0=",
"owner": "hercules-ci",
"repo": "flake-parts",
"rev": "8471fe90ad337a8074e957b69ca4d0089218391d",
"rev": "3d04084d54bedc3d6b8b736c70ef449225c361b1",
"type": "github"
},
"original": {
@ -47,11 +47,11 @@
"pre-commit-hooks": "pre-commit-hooks"
},
"locked": {
"lastModified": 1723577950,
"narHash": "sha256-kOpGI9WPmte1L4QWHviuXsr8jxmGn27zwi82jtzYObM=",
"rev": "b016eb0895bb6714a4f6530d9a2bb6577ac6c3cf",
"lastModified": 1729696851,
"narHash": "sha256-XME7TzBvjK6GEmZqPLK+2+Wk0qnwc7DCwYH434hMcOM=",
"rev": "2734a9cf94debc6baef4e7d4d9fa28cc28f5b31d",
"type": "tarball",
"url": "https://git.lix.systems/api/v1/repos/lix-project/lix/archive/b016eb0895bb6714a4f6530d9a2bb6577ac6c3cf.tar.gz?rev=b016eb0895bb6714a4f6530d9a2bb6577ac6c3cf"
"url": "https://git.lix.systems/api/v1/repos/lix-project/lix/archive/2734a9cf94debc6baef4e7d4d9fa28cc28f5b31d.tar.gz?rev=2734a9cf94debc6baef4e7d4d9fa28cc28f5b31d"
},
"original": {
"type": "tarball",
@ -65,11 +65,11 @@
]
},
"locked": {
"lastModified": 1720066371,
"narHash": "sha256-uPlLYH2S0ACj0IcgaK9Lsf4spmJoGejR9DotXiXSBZQ=",
"lastModified": 1729742964,
"narHash": "sha256-B4mzTcQ0FZHdpeWcpDYPERtyjJd/NIuaQ9+BV1h+MpA=",
"owner": "nix-community",
"repo": "nix-github-actions",
"rev": "622f829f5fe69310a866c8a6cd07e747c44ef820",
"rev": "e04df33f62cdcf93d73e9a04142464753a16db67",
"type": "github"
},
"original": {
@ -81,11 +81,11 @@
"nix2container": {
"flake": false,
"locked": {
"lastModified": 1720642556,
"narHash": "sha256-qsnqk13UmREKmRT7c8hEnz26X3GFFyIQrqx4EaRc1Is=",
"lastModified": 1724996935,
"narHash": "sha256-njRK9vvZ1JJsP8oV2OgkBrpJhgQezI03S7gzskCcHos=",
"owner": "nlewo",
"repo": "nix2container",
"rev": "3853e5caf9ad24103b13aa6e0e8bcebb47649fe4",
"rev": "fa6bb0a1159f55d071ba99331355955ae30b3401",
"type": "github"
},
"original": {
@ -96,11 +96,11 @@
},
"nixpkgs": {
"locked": {
"lastModified": 1723540975,
"narHash": "sha256-rxpxOz2VSqgmwI7g7FGVAoye5bxwO1MSpnELY5bsITw=",
"lastModified": 1729851744,
"narHash": "sha256-c3ZSmkQdcdmNAzHud2b0fANXNa8TcySH0ZAqND5zEi0=",
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "fb81cec9eda2a6b5365ad723995f0329d9e356fd",
"rev": "45e5197248e59e92e88956c5aa12553a7f62337f",
"type": "github"
},
"original": {
@ -129,11 +129,11 @@
"pre-commit-hooks": {
"flake": false,
"locked": {
"lastModified": 1721042469,
"narHash": "sha256-6FPUl7HVtvRHCCBQne7Ylp4p+dpP3P/OYuzjztZ4s70=",
"lastModified": 1726745158,
"narHash": "sha256-D5AegvGoEjt4rkKedmxlSEmC+nNLMBPWFxvmYnVLhjk=",
"owner": "cachix",
"repo": "git-hooks.nix",
"rev": "f451c19376071a90d8c58ab1a953c6e9840527fd",
"rev": "4e743a6920eab45e8ba0fbe49dc459f1423a4b74",
"type": "github"
},
"original": {
@ -158,11 +158,11 @@
]
},
"locked": {
"lastModified": 1723454642,
"narHash": "sha256-S0Gvsenh0II7EAaoc9158ZB4vYyuycvMGKGxIbERNAM=",
"lastModified": 1729613947,
"narHash": "sha256-XGOvuIPW1XRfPgHtGYXd5MAmJzZtOuwlfKDgxX5KT3s=",
"owner": "numtide",
"repo": "treefmt-nix",
"rev": "349de7bc435bdff37785c2466f054ed1766173be",
"rev": "aac86347fb5063960eccb19493e0cadcdb4205ca",
"type": "github"
},
"original": {

View file

@ -348,20 +348,12 @@ int main(int argc, char **argv) {
myArgs.parseArgs(argv, argc);
/* FIXME: The build hook in conjunction with import-from-derivation is
* causing "unexpected EOF" during eval */
settings.builders = "";
/* Prevent access to paths outside of the Nix search path and
to the environment. */
evalSettings.restrictEval = false;
/* When building a flake, use pure evaluation (no access to
'getEnv', 'currentSystem' etc. */
if (myArgs.impure) {
jade marked this conversation as resolved Outdated

Not sure if this makes sense, if it breaks stuff it should be overridden, and if it doesn't why do it at all?

Not sure if this makes sense, if it breaks stuff it should be overridden, and if it doesn't why do it at all?
Outdated
Review

it appears to be nonsense. we removed it and observed that IFD induced remote builds work, so idk, probably some old nix bug that we fixed??

it appears to be nonsense. we removed it and observed that IFD induced remote builds work, so idk, probably some old nix bug that we fixed??
evalSettings.pureEval = false;
evalSettings.pureEval.override(false);
} else if (myArgs.flake) {
evalSettings.pureEval = true;
evalSettings.pureEval.override(true);
}
jade marked this conversation as resolved Outdated

This does not make sense at all, as the default is false already. You either want to override it or delete this entirely. Or judging by the comment, false is a typo to begin with and this should set the default to true (but still allowing the user to override it)?

This does not make sense at all, as the default is `false` already. You either want to override it or delete this entirely. Or judging by the comment, `false` is a typo to begin with and this should set the default to `true` (but still allowing the user to override it)?

Oh that comment makes this very confusing then. The CLI doesn't seem to have any way to specify this in the first place? Should we just leave it as false since that's what it's been, and add a FIXME?

Oh that comment makes this very confusing then. The CLI doesn't seem to have any way to specify this in the first place? Should we just leave it as `false` since that's what it's been, and add a FIXME?

Looking at the blame of this code, it seems that the comment was added along with explicitly setting this to true, and when it was later set to false some time later (presumably because breakage in some situations was noticed), the comment was left. I'm not really qualified to comment on this because I'm not familiar with this codebase, but my gut feeling is that this code should be deleted entirely and the user can pass --option restrict-eval true if they really want to enable restricted eval mode.

Looking at the blame of this code, it seems that the comment was added along with explicitly setting this to `true`, and when it was later set to `false` some time later (presumably because breakage in some situations was noticed), the comment was left. I'm not really qualified to comment on this because I'm not familiar with this codebase, but my gut feeling is that this code should be deleted entirely and the user can pass `--option restrict-eval true` if they really want to enable restricted eval mode.
if (myArgs.releaseExpr == "")
@ -374,7 +366,7 @@ int main(int argc, char **argv) {
}
if (myArgs.showTrace) {
loggerSettings.showTrace.assign(true);
loggerSettings.showTrace.override(true);
}
Sync<State> state_;