-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
Is your feature request related to a problem? Please describe.
Say I want to write a script that first enters a devShell with nix print-dev-env before executing its task. There is currently no way to make the *-env drv produced by nix develop and nix print-dev-env referencable in the Nix code so as to make the devshell a proper dependency of the script.
devShells: writeShellScript:
writeShellScript "f.sh" ''
# not properly tracked as a dependency of this script text
eval $(nix print-dev-env .#shell)
# proposal to treat a shell as any other derivation and simply source it
. ${builtins.devEnv devShells.shell}
# rest of the script logic
''This may seem like a non-issue since the act of running nix print-dev-env will simply eval and build the shell deriation at runtime, but what if we want a clean separation between buildtime and runtime for environments like CI that want to track the build step for caching, etc?
You might think that you could just place a comment with a reference to the outpath of the derivation itself, but what if that derivation is a heavy build and you don't actually need the binary, you just need its build env? Also, your script will be that much lighter if it doesn't have to depend on the nix binary to make a single call.
Describe the solution you'd like
A simple primop that basically executes getDerivationEnvironment (modified appropriately) on any derivation passed to it, returning the resulting environment drv seems like it should do the trick.
Describe alternatives you've considered
Perhaps there is already a way to do this that I'm just not aware of? If we carefully craft a function in Nix code that does the same thing as getDerivationEnvironment we could theoretically end up with the exact same result, but that seems more error prone.
Additional context
In divnix/std-action we make a clear separation between eval time, build time, and run time. The build time dependencies are tracked, and that's how we can ensure they are always sent to our binary cache, even in the event that the task runtime fails. We also track packages that are already built and skip builds if possible. If we don't have an accurate representation of the dependency graph, this logic can be less effective, where the goal is to do as little work as possible.
I am finding it tricky to solve this for some of our tasks at work that call nix print-dev-env from a script. For now I have a comment referencing the derivation, but this isn't exactly right since the derivation isn't the same as the one nix print-dev-env actually calls.