Skip to content
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

haskellPackages.shellFor with hoogle enabled fails with null dependencies #82245

Open
alexpeits opened this issue Mar 10, 2020 · 12 comments
Open
Labels

Comments

@alexpeits
Copy link

Describe the bug
On the nixpkgs-unstable branch, when there are no haskell dependencies other than base (and other common ones like text) in build-depends in the cabal file, starting a shell with hoogle enabled gives the error:

error: value is null while a set was expected, at /nix/store/<hash>-source/pkgs/development/haskell-modules/hoogle.nix:69:43

To Reproduce
Steps to reproduce the behavior:

  1. Create the following default.nix:
{ pkgs ? import <nixpkgs> {} }:

let

  nixpkgs-src = pkgs.fetchFromGitHub {
    owner = "NixOS";
    repo = "nixpkgs";
    rev = "nixpkgs-unstable";
    sha256 = "06755h2cxrsgrsiclxbk3h5d7yqajvjjq3y4pl1dqbxfbjhq0h67";
  };
  nixpkgs = import nixpkgs-src {};

  haskellPackages = nixpkgs.haskellPackages.override {
    overrides = self: super:
      { testpkg = self.callCabal2nix "testpkg" ./. {}; };
  };

  shell = haskellPackages.shellFor {
    packages = ps: [ ps.testpkg ];
    buildInputs = [ haskellPackages.cabal-install ];
    withHoogle = true;
  };

in

if nixpkgs.lib.inNixShell then shell else haskellPackages.testpkg
  1. The following testpkg.cabal:
cabal-version: 2.2

name:           testpkg
version:        0.1.0.0
description:    testpkg
build-type:     Simple

library
  exposed-modules:
  other-modules:
      Paths_testpkg
  hs-source-dirs:
      src
  build-depends:
      base >=4.7 && <5
      -- uncomment the following to make it work
      -- , lens 
  default-language: Haskell2010
  1. run nix-shell

Expected behavior
The nix shell is initialized, and running hoogle server --local runs a hoogle server. Adding another dependency in build-depends, e.g. lens, results in the expected behaviour.

Additional context
The issue seems similar to this closed issue

Metadata

these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked):
  /nix/store/4cr2bqya0an66mpqpj195z49453qm8f6-nix-info
copying path '/nix/store/4cr2bqya0an66mpqpj195z49453qm8f6-nix-info' from 'https://cache.nixos.org'...
 - system: `"x86_64-linux"`
 - host os: `Linux 4.15.0-88-generic, Ubuntu, 16.04.6 LTS (Xenial Xerus)`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2.1`
 - channels(alex): `"nixpkgs-20.03pre211462.0c960262d15"`
 - nixpkgs: `/<redacted>/.nix-defexpr/channels/nixpkgs`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: 
  - haskellPackages.shellFor
@alexpeits alexpeits added the 0.kind: bug Something is broken label Mar 10, 2020
@cdepillabout
Copy link
Member

cdepillabout commented Mar 11, 2020

Ping @Ericson2314.

It is possible this was introduced in either #80845 or #76349.

Also ping @jmininger and @matthewbauer, who did reviews on these issues.


Also, @alexpeits, if you'd like to look into this, I'm hoping the fix wouldn't be too tricky.

@alexpeits
Copy link
Author

Surprisingly what causes the issue is this warning message

${lib.optionalString (packages != [] -> docPackages == [])
("echo WARNING: localHoogle package list empty, even though"
+ " the following were specified: "
+ lib.concatMapStringsSep ", " (p: p.name) packages)}

(if I remove the concatMapStringsSep call it works). Seems like packages is a list which contains a null for some reason that I can't figure out, but I'll look into it a bit more

@JosephLucas
Copy link
Contributor

I had the same issue, previous suggestion worked.

@Ericson2314
Copy link
Member

https://github.com/NixOS/nixpkgs/pull/42368/files this revert would seem to reintroduce the issue, but the issue was not reopened.

@bolt12
Copy link
Contributor

bolt12 commented Jul 12, 2020

Today I experienced this error with nixos-20.03, which is weird given that by reading this thread I got the idea that this was already fixed.

Edit: I think this is because the package I was using does not have an executable, but the package only depends on base. How can I work around this?
Here's my derivation:

  shell = myHaskellPackages.shellFor {
    packages = p: [
      p."laop"
    ];
    buildInputs = with pkgs.haskellPackages; [
      myHaskellPackages.cabal-install
      pkgs.neo4j
      (import sources.niv {}).niv
      pkgs.nixpkgs-fmt
    ];
    withHoogle = true;
  };

TristanCacqueray added a commit to TristanCacqueray/haskell-nix that referenced this issue Oct 17, 2020
chuahou added a commit to chuahou/aoc that referenced this issue Dec 16, 2020
- We have to use 'useHoogle = false;' due to a bug described at
  NixOS/nixpkgs#82245
@stale
Copy link

stale bot commented Jan 9, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jan 9, 2021
@chuahou
Copy link
Member

chuahou commented Jan 10, 2021

This bug still occurs for me on nixos-20.09.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jan 10, 2021
@jul1u5
Copy link
Contributor

jul1u5 commented Feb 18, 2021

I have also encountered the same issue. Are there any workarounds?

@cdepillabout
Copy link
Member

@jul1u5 I haven't taken a good look at this, but from reading the thread it sounds like these are your options:

  1. Don't enable hoogle. (You arguably don't need hoogle if you only depend on base. You may be able to just use https://hoogle.haskell.org/.)
  2. Explicitly add a dependency so your library has at least one dependency. (Does this actually get rid of the problem?)
  3. Use developPackage instead of shellFor. (Does this actually work?)
  4. Investigate if the problem really is haskellPackages.shellFor with hoogle enabled fails with null dependencies #82245 (comment) and send a PR fixing it to Nixpkgs.

Everyone would probably appreciate if you did 4., but that is probably the most time-consuming solution in this list :-)

@jul1u5
Copy link
Contributor

jul1u5 commented Feb 18, 2021

Thanks for the quick response!

  1. Yes, adding any dependency makes it work. Thanks, I haven't realised this.
  2. I tried developPackage, but enabling withHoogle alone didn't seem to do anything, hoogle was not in the shell environment. I enabled returnShellEnv but the original error still occurs (value is null). Here is what I tried:
haskellPackages.developPackage {
  name = "project-name";
  root = ./.;

  returnShellEnv = true;
  withHoogle = true;
}
  1. I will try to investigate, but I am not that familiar with nixpkgs codebase.

@cdepillabout
Copy link
Member

Also see #108100 which may have some additional information about this bug.

@expipiplus1
Copy link
Contributor

Although this doesn't tackle the root cause of a null package sneaking in (via executableHaskellDepends), it does effectively treat the symptom by just ignoring any null packages.

diff --git a/pkgs/development/haskell-modules/hoogle.nix b/pkgs/development/haskell-modules/hoogle.nix
index cfa06b045de..fb2f893943c 100644
--- a/pkgs/development/haskell-modules/hoogle.nix
+++ b/pkgs/development/haskell-modules/hoogle.nix
@@ -63,10 +63,11 @@ buildPackages.stdenv.mkDerivation {
   passAsFile = ["buildCommand"];

   buildCommand = ''
-    ${lib.optionalString (packages != [] -> docPackages == [])
+    ${let packages' = lib.filter (p: p != null) packages;
+      in lib.optionalString (packages' != [] -> docPackages == [])
        ("echo WARNING: localHoogle package list empty, even though"
        + " the following were specified: "
-       + lib.concatMapStringsSep ", " (p: p.name) packages)}
+       + lib.concatMapStringsSep ", " (p: p.name) packages')}
     mkdir -p $out/share/doc/hoogle

     echo importing builtin packages

expipiplus1 added a commit to expipiplus1/nixpkgs that referenced this issue Jun 16, 2021
Workaround for NixOS#82245

Although this doesn't tackle the root cause of a null package sneaking
in (via executableHaskellDepends), it does effectively treat the symptom
by just ignoring any null packages.

Seeing as that issue has been open for more than a year I think this
band-aid is necessary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants