Skip to content
This repository has been archived by the owner on Oct 15, 2022. It is now read-only.

lorri shell failure: package.yaml: Yaml file not found: /build/package.yaml #415

Open
codygman opened this issue Jun 4, 2020 · 11 comments
Open

lorri shell failure: package.yaml: Yaml file not found: /build/package.yaml #415

codygman opened this issue Jun 4, 2020 · 11 comments

Comments

@codygman
Copy link

codygman commented Jun 4, 2020 •
edited
Loading

Describe the bug

It's worth noting a few things first:

if [[ ! -f "smurf.cabal" ]]
then
  echo "generating cabal file from package.yaml..."
  nix-shell --pure --run "hpack" # so meta
fi
eval "$(lorri direnv)"
  • We have a shellHook that calls hpack conditionally as well in case someone uses nix-shell --pure directly:
# full default.nix and shell.nix at bottom
...
        shellHook = ''
if [[ ! -f "smurf.cabal" ]]
then
  echo "generating cabal file from package.yaml..."
  hpack
fi
'';
...

A teammate is getting:

$ nix-shell --pure
$ lorri shell
lorri shell                                                                                                                                                                                                                    [16:29:27]
lorri: building environment......... done
Jun 04 16:29:39.574 ERRO Build failed. No cached environment available.
Build error: Nix process returned exit code 100.
$ "nix-build" "--out-link" "/tmp/.tmptvAWEC/result" "--" "/tmp/.tmp7kSNVh/result"
these derivations will be built:
  /nix/store/8xp0ram46bm570863q6g17rm3bby89a3-lorri-keep-env-hack-ghc-shell-for-smurf-23.drv
building '/nix/store/8xp0ram46bm570863q6g17rm3bby89a3-lorri-keep-env-hack-ghc-shell-for-smurf-23.drv'...
generating cabal file from package.yaml...
package.yaml: Yaml file not found: /build/package.yaml
builder for '/nix/store/8xp0ram46bm570863q6g17rm3bby89a3-lorri-keep-env-hack-ghc-shell-for-smurf-23.drv' failed with exit code 1
error: build of '/nix/store/8xp0ram46bm570863q6g17rm3bby89a3-lorri-keep-env-hack-ghc-shell-for-smurf-23.drv' failed

While lorri-shell works fine for me:

cody@cody-VirtualBox:~/smurf$ lorri shell
lorri: building environment......... done

We should have the exact same os, exact same nix version, and exact same lorri version. Their nix-info is only different by mine in order of output (so probably nix-info is a different version):

Their (lorri shell fails) nix-info

  • system: "x86_64-linux"
  • host os: Linux 5.4.0-33-generic, Ubuntu, 20.04 LTS (Focal Fossa)
  • multi-user?: no
  • sandbox: yes
  • version: nix-env (Nix) 2.3.6
  • channels(cameron): "home-manager, nixpkgs-20.09pre228333.1ae28ebfdb7"
  • nixpkgs: /home/cameron/.nix-defexpr/channels/nixpkgs

My ((lorri shell works) nix-info

cody@cody-VirtualBox:~/smurf$ nix-shell -p nix-info --run "nix-info -m"

  • system: "x86_64-linux"
  • host os: Linux 5.4.0-33-generic, Ubuntu, 20.04 LTS (Focal Fossa)
  • multi-user?: no
  • sandbox: yes
  • version: nix-env (Nix) 2.3.6
  • channels(cody): "nixpkgs-20.09pre228333.1ae28ebfdb7, home-manager"
  • nixpkgs: /home/cody/.nix-defexpr/channels/nixpkgs

There is an interesting piece of our default.nix which generates the cabal file using hpack that is likely causing an issue here:

To Reproduce
Steps to reproduce the behavior:

  1. Be on ubuntu with nix 2.3.6 installed
  3. ...

Expected behavior

Metadata

$ lorri info
<please paste output here>
$ uname -a
<please paste output here>

Additional context

default.nix (using developPackage)

{ compiler ? "ghc883" ,
  pkgs ? import ./nix/nixpkgs.nix {},
}:
let
  inherit (import (builtins.fetchTarball "https://github.com/hercules-ci/gitignore/archive/7415c4f.tar.gz") { }) gitignoreSource;
  hpkgs = pkgs.haskell.packages."${compiler}";
  smurf = hpkgs.developPackage {
    root = pkgs.lib.cleanSourceWith { filter = (path: type:
      ! (builtins.any
        (r: (builtins.match r (builtins.baseNameOf path)) != null)
        [
          "README.md"
          "notes"
          "ops"
          "tf"
          ".ghcid"
          ".dir-locals.el"
          ".semaphore"
        ])
    ); src = gitignoreSource ./.; };
    name = "smurf";
    modifier = drv:
      with pkgs.haskellPackages;
      pkgs.haskell.lib.disableOptimization (pkgs.haskell.lib.overrideCabal drv (attrs: {
        doCoverage = false;
        doCheck = true; # whether to run tests
        enableLibraryProfiling = false;
        enableExecutableProfiling = false;
        doHaddock = false;
        shellHook = ''
if [[ ! -f "smurf.cabal" ]]
then
  echo "generating cabal file from package.yaml..."
  hpack
fi
'';
        buildTools = [ brittany
                       cabal-install
                       ghcid
                       ghcide
                       hlint
                       hpack
                     ];
      }));
  };
in if pkgs.lib.inNixShell
   then smurf
   else
     pkgs.haskell.lib.dontCoverage (
       pkgs.haskell.lib.dontCheck
         (pkgs.haskell.lib.disableLibraryProfiling
           (pkgs.haskell.lib.disableExecutableProfiling
             (pkgs.haskell.lib.disableOptimization smurf))))

shell.nix (just uses developPackage from default.nix):

let
  smurf = import ./default.nix {};
in
  smurf
@Profpatsch
Copy link
Collaborator

lorri direnv does run the shellHook, however inside of the nix build, which is probably why you are seeing the build error.

@Profpatsch
Copy link
Collaborator

This is another datapoint that we should probably not be running any shellHooks in lorri (cc @grahamc)

@codygman
Copy link
Author

codygman commented Jun 6, 2020 •
edited
Loading

This is another datapoint that we should probably not be running any shellHooks in lorri (cc @grahamc)

From a user perspective this doesn't justify not running shellHooks in lorri. I have a shellHook there so that the cabal file is reliably in sync with the package.yaml and this does actually work with nix-shell --pure.

I don't see how I can use lorri with an hpack powered Haskell project if shellHooks aren't run. Perhaps you know of another simpler way to make that work without shellHooks?

If lorri is going the direction of not supporting as much as nix-shell I'd recommend at least a simple list of things not supported by approximate(intuitive guessing mostly) popularity of that feature.

@codygman
Copy link
Author

codygman commented Jun 6, 2020

Also, I'm still confused how things just work on NixOS and not on ubuntu+nix. Maybe I had the cabal file, it got copied over, and this path was never exercised on NixOS. I'll try to see if I can reproduce that difference.

@Profpatsch
Copy link
Collaborator

Profpatsch commented Jun 8, 2020 via email

@codygman
Copy link
Author

codygman commented Jun 9, 2020

Is your “run hpack when entering the shell” a good solution anyway? This means you need leave/reenter the project whenever you change your hpack file, which seems like something that should be orthogonal. How about adding a Makefile which always runs hpack before building your project (if the package,yaml changed).

First, thanks for the quick answer and help. I'm trying to figure out how to implement this with my current nix knowledge.

To answer though, I'm not sure. That does sound better in a way, but then from the nix perspective it changes my project from a Haskell project to a make based or shell based project I think.

Right now I use pkgs.haskell.packages.ghc883.developPackage and then ghci within that. Development in the presence of package.yaml across my team as well as I believe others using package.yaml basically accepts "changing package.yaml" means restarting stack repl or hpack && cabal repl.

I'm open personally to using a makefile based project or shell based project which is hpack && cabal build essentially, but that makes the burden of using nix for Haskell projects at least a little higher.

I get the desire for it to be orthogonal, but I don't like that it complicates things from the user perspective when nix is already hard enough to get adoption for.

@Profpatsch
Copy link
Collaborator

Profpatsch commented Jun 9, 2020 via email

@codygman
Copy link
Author

codygman commented Jun 9, 2020 •
edited
Loading

I'm confused at how to make this work. Right now I use direnv and direnv-emacs to give me an environment where ghcide is built with the same haskell dependencies as my project.

How do I ensure that when I enter nix-shell, call nix-build, or call ghcide from my nix-shell environment it first calls this makefile?

But essentially, make backend would make sure your cabal file is up to
date (running hpack if not) and then run stack build or similar.

I'm not interested in running any of these commands and in the end I'd like to open a file buffer in my haskell project and ghcide (running in my nix-shell) work. My understanding of direnv was it makes "just run make foo after cd'ing into directory" unnecessary and that's the end I've been using it toward.

I don't see how to get to the end goal of "open buffer, correct ghcide in haskell environment used to build your project gets run, you develop" with your suggestions.

Is there an example I could look at to try and make sense of this? Or if I'm not adequately describing this workflow I have with direnv/emacs-direnv that I'm trying to use lorri for I can make a screencast and sample project to clarify.

@codygman
Copy link
Author

codygman commented Jun 9, 2020 •
edited
Loading

Disregard the above... I think you mean just to call that make command in your .envrc

Edit: No nevermind, I'm just plain confused.

@Profpatsch
Copy link
Collaborator

Profpatsch commented Jun 11, 2020 via email

blaggacao pushed a commit to blaggacao/pre-commit-hooks.nix that referenced this issue Jul 2, 2020
lorriHook
aec533c 
As per unmerge target/lorri#265:
erroring shellHooks make lorri fail.

At the very least the foolowing hook calles on external tool (git)
```
let
  nix-pre-commit-hooks = import (builtins.fetchTarball "https://github.com/cachix/pre-commit-hooks.nix/tarball/master");
  pkgs = import <nixpkgs> {};
in {
  pre-commit-check = nix-pre-commit-hooks.run {
    src = ./.;
    hooks = {
      shellcheck.enable = true;
      shfmt = {
        enable = true;
        name = "shfmt";
        description = "Format Shell files";
        entry = "${pkgs.shfmt}/bin/shfmt -w -l";
        types = ["shell"];
      };
      prettier = {
        enable = true;
        name = "prettier";
        description = "Format JS, HTML, CSS, GraphQL, Markdown & YAML files";
        entry = "${pkgs.nodePackages.prettier}/bin/prettier --write --list-different";
        types = [
            "css"
            "graphql"
            "html"
            "javascript"
            "json"
            "jsx"
            "less"
            "markdown"
            # "mdx"
            "scss"
            "ts"
            "tsx"
            "vue"
            "yaml"
        ];
      };
    };
  };
}
```
It looks like lorriHook might eventually get executed by lorri direnv. (target/lorri#415 (comment))

But unteil then, $shellHook + prec-ommit-nix breakes lorri under certain circumstances
@blaggacao blaggacao mentioned this issue Jul 2, 2020
Closed
@blaggacao
Copy link

blaggacao commented Jul 2, 2020 •
edited
Loading

@Profpatsch
I'd very much appreciate this #415 (comment)
It would allow me to reopen cachix/git-hooks.nix#48

Looks like I'm deadlocked by #264 purposefully not being address in #265 during #444 .

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@codygman @Profpatsch @blaggacao