-
Notifications
You must be signed in to change notification settings - Fork 843
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
Support reproducible builds via Nix #1285
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
Just filePath -> "from file: " ++ filePath | ||
Nothing -> "with nix packages: " ++ (intercalate ", " pkgsInConfig)) | ||
e <- try (callProcess' | ||
(if isTerm then id else \cp -> cp { delegate_ctlc = False }) |
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. |
Just filePath -> "from file: " <> (T.pack filePath) | ||
Nothing -> "with nix packages: " <> (T.intercalate ", " pkgsInConfig)) | ||
e <- try (exec | ||
(EnvSettings {esIncludeLocals = False |
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 theglpk
dependency, and then launch the build. Of course, this requiresnix
to be installed on your system, and it requires yourstack.yaml
to 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.nix
files).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
packages
andshell-file
at 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.