Closed utdemir closed 2 years ago
Yeah, we discussed that supporting NIX_PATH as an opt-in makes sense.
Thank you @domenkozar .
I just wanted to note that what I was asking for will (probably) also be possible with the recent "recursive nix" feature. After a new Nix version is released and if the agent supports it, I should be able to do something like:
runCommand "build" {} ''
export NIX_PATH=nixpkgs="${sources.nix}"
nix-build ./default.nix
''
We weren't able to prioritize this at the time and it seems that the window for this to be useful is closing, as the ecosystem has been moving away from NIX_PATH, accelerated by the adoption of tools like niv
and the advent of Flakes.
With version 0.9, the agent is in a good position to support this, as it splits the evaluation of project configuration and the actual evaluation for building. Do you still need this?
Hi @roberth. I haven't been using Hercules CI for a while, so I do not need it.
And I also agree that NIX_PATH
is something we should move away from, so I'm happy to close it. Thanks!
Hi,
I am trying to to build my dotfiles repository with Hercules CI.
I have
nixpkgs
pinned, but still some of my dependencies, useNIX_PATH
to lookup some trivial files fromnixpkgs
. So, I currently get these kind of errors error when used with Hercules CI:I was able to get things working by patching things and adding conditionals for CI, but it isn't pretty. Ideally, I would prefer having
NIX_PATH
available on executors, since there's still tooling using it. I know that it makes the builds less deterministic, so maybe having an option with a warning might be a better option.Another alternative would be to have a way to set
NIX_PATH
onci.nix
. Maybe with some special key like: