-
Notifications
You must be signed in to change notification settings - Fork 847
Support reproducible builds via Nix #1285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Don't dispatch on the ExecEnv type. Using Docker and nix is no longer mutually exclusive. We run commands in a docker container if configured, and then fork a nix-shell inside if configured.
and reports the use of nix-provided GHC
Using PackageNames forbid to use '.' in names, which is required when you use attributes
src/Stack/Nix.hs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt the extra logic to prevent delegating Ctrl-C is necessary in this case. For Docker, it's there because of some specific weird stuff that docker run and docker start do with container terminals, but this nix-shell looks like a regular process that uses the existing std* file handles and TTY normally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed along with previous
|
When I tried this with a resolver that hadn't been mirrored to nix yet, I got the following error: After reading the docs I understood what this meant, but is it possible to make this more user-friendly? It would be nice if the error at least indicates why this would happen and perhaps suggests running |
|
Thanks for all the work on this, it looks really close to being ready to merge! Don't forget to add a changelog entry. It should go in the major changes section; this deserves lots of attention! |
|
@borsboom I pushed a new commit addressing your comments. Although, regarding this Nix error about the missing attribute, to provide a more informative error message I would need to ask nix about which attributes are available, which is not easy to automate as I pointed out in the manual. The real fix would be to stop to depend on a GHC provided by Nix and use a GHC downloaded by Stack, but for now on Linux this results in failure to find libs in the nix store. |
|
Fair enough, I don't think the error message should hold up merging this, although it would be nice to improve at some point. I'm not surprised that trying to use a non-Nix GHC causes problems, so leaving that as-is is reasonable. Do you think this may end up with similar problems as Docker in #911 and #1367? I'm beginning work on a fix for those two now, and most likely the same approach can be used for Nix as well. |
src/Stack/Nix.hs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use Stack.Config.Types.minimalEnvSettings instead.
|
@borsboom I corrected the escaping of the command line and re-merged the master. |
Support reproducible builds via Nix
|
LGTM, thanks for this awesome new feature! |
|
Awesome :D I think this warrants a |
|
I will publish a blog post about this feature shortly. |
|
@YPares looking forward to it, will you post it back here? |
This pull request implements the capability for stack to launch the build inside a nix-shell, in order to specify dependencies to libraries out of Hackage that exist in Nixpkgs.
Simply modify your stack.yaml so it contains for instance:
Build this project with
stack --nix build. It will open a Nix-shell that will first download theglpkdependency, and then launch the build. Of course, this requiresnixto be installed on your system, and it requires yourstack.yamlto depend on an LTS resolver that has been mirrored in the nix packages (see for instance in https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/haskell-modules theconfiguration-lts-X.Y.nixfiles).If you know nix, you can also specify a shell.nix that creates a derivation that will be used to set the build environment. You cannot specify
packagesandshell-fileat the same time!For now, this works much like the docker backend, by relauching the same stack executable inside a new environment. It requires GHC to be installed by Nix.
It's not possible to use
stack ghci, because GHCi fails to find the extra libraries, but this is not specific to stack, as the command:nix-shell --pure -p ghc extra-libs --command "stack ghci"without enabling nix support in stack already fails.
Theoretically, activating both Nix and Docker could be possible (resulting in a nix-shell running inside a container), but that requires a Docker image providing Nix, of course.