pkgs/haskellPackages: add nativeBuildInputs to shell env #28033
Conversation
When in an env, the user normally wants to do a manual (incremental) build, build tools are needed.
|
@Profpatsch, thanks for your PR! By analyzing the history of the files in this pull request, we identified @peti, @cstrahan and @shlevy to be potential reviewers. |
| @@ -349,7 +349,7 @@ stdenv.mkDerivation ({ | |||
|
|
|||
| env = stdenv.mkDerivation { | |||
| name = "interactive-${pname}-${version}-environment"; | |||
| nativeBuildInputs = [ ghcEnv systemBuildInputs ] | |||
| nativeBuildInputs = [ ghcEnv systemBuildInputs nativeBuildInputs ] | |||
There was a problem hiding this comment.
I left them out on purpose because Cabal needs to know the proper search paths for those libraries to bake those into the Cabal files. Without that information, configured builds won't work outside of a nix-shell environment.
There was a problem hiding this comment.
I don’t quite follow. I personally use a generated shell.nix like:
((import <nixpkgs> {}).haskellPackages.override {
overrides = self: super: {
my-pkg = let
buildDepends = with self; [
ansi-wl-pprint
trifecta
];
in super.mkDerivation {
pname = "pkg-env";
src = "/dev/null";
version = "none";
license = "none";
inherit buildDepends;
buildTools = with self; [
ghcid
cabal-install
hpack
(hoogleLocal {
packages = buildDepends;
})
];
};
};
}).my-pkgfor my projects, where buildTools are the tools needed to build the package in the env.
Why wouldn’t a configured package work outside the shell environment as long as the paths are absolute?
There was a problem hiding this comment.
nix-shell configures gcc-wrapper magic to find those libraries without an explicit search path. Therefore, the build setup is broken once you leave that shell environment. When you pass --extra-{include,lib}-dir, however, then the configured build works fine inside and outside of the nix-shell environment.
There was a problem hiding this comment.
pass --extra-{include,lib}-dir, however
What should I pass this to?
There was a problem hiding this comment.
You can't pass it anywhere. The best we can do is to create a convenient macro / alias / shell function that users of the environment can use to refer to those flags when invoking stack or cabal or tinc or whatever it is they are invoking.
There was a problem hiding this comment.
In my opinion these workarounds are required because of the flawed requirement that everything has to work outside of a nix shell after it is configured.
Naturally this breaks most workflows from the get-go.
There was a problem hiding this comment.
The requirement that builds work outside of nix-shell is essential for everyone who uses long-running IDEs, like Emacs, to develop multiple projects with different kinds of environments without qutting and re-starting the IDE every time.
There was a problem hiding this comment.
like Emacs
I managed to configure my Emacs in a way that it uses the shell environment of the current project for Haskell projects, so I don’t experience that problem.
|
Progress on this? |
|
I am using this patch locally, it is up to @peti whether we merge it or find some other solution. $ git apply <(curl https://github.com/NixOS/nixpkgs/pull/28033.patch) |
|
Sorry. |
|
Peter Simons <notifications@github.com> writes:
The requirement that builds work outside of `nix-shell` is essential for everyone who uses long-running IDEs, like Emacs, to develop multiple projects with different kinds of environments without qutting and re-starting the IDE every time.
nix-shell configures gcc-wrapper magic to find those libraries without an explicit search path. Therefore, the build setup is broken once you leave that shell environment. When you pass --extra-{include,lib}-dir, however, then the configured build works fine inside and outside of the nix-shell environment.
Wait. Are you saying that if I `cabal configure` in `nix-shell` I would
get something that is un`cabal build`able outside of `nix-shell`?
Currently? Or with this patch?
I don't really use build environments for my Haskell projects (I just
dump everything into a single `ghcWithPackages`) so I don't really care,
but this sounds crazy to me.
|
peti keeps |
|
@peti |
|
I’m still using the non-merged patched of this PR locally in my projects, which just works for my use case (local projects with custom ghc & hoogle databases and tools like cabal or ghcid). |
I'm solving a related-but-different issue in #32821; I'm trying to get foreign libraries into the environment instead of build tools. I didn't add any new dependencies, I just moved |
you'll find plenty of examples at https://github.com/basvandijk/nix-workshop/blob/master/03-finding-system-libraries/run.sh. Unfortunately, the talk that went with that repo wasn't recorded (as I hoped it would be), so the material is a little terse. Given your background, however, I'm confident that you'll be able to follow the examples just fine. |
When in an env, the user normally wants to do a manual (incremental) build,
build tools are needed.