search

mlabs-haskell / mlabs-tooling.nix

A flake that provides everything necessary to set up a project within our sopes. This includes the necessary maintenance as well as CI.
MIT License
7 stars 7 forks source link

Some usage struggles #36

Open zmrocze opened 1 year ago

zmrocze commented 1 year ago

Hey, let me write some feedback I have after having tried this flake.

  1. A short overview of flake-parts would be helpful for integrating the template into existing flakes

  2. Adding an input to extraHackage feels like saying "Use this version", but really cabal is free to prefer different version from CHaP/hackage. This is unintuitive and forces the user to specify additionally to the extraHackage input also the matching version bound inside package.cabal. So in the end one could just specify the dep as source-repository-package and the update doesn't need to happen in two places.

  3. Generally a quick overview of the cooperation of mlabs-tooling+haskell.nix+cabal solver would be very helpful (from my experience the abstraction leaks every time):

    • is a dependency picked from CHaP or extraHackage first?
    • are version bounds from dependencies cabal.project's taken into consideration?

  4. Where can I find available attributes of project field for mkHaskellFlakeModule1?

  5. The biggest problem is outside of the scope of this flake I'm afraid. Where I am losing most of my time is not on the nix workings, but simply finding a working dependency set. Before CHaP every cardano dep was pinned to a single commit, so there either existed a unique dependency set or there was a dependency conflict - sadly you had to find it out doing the solvers job manually. Right now the situation with CHaP is that the packages there specify their dependencies version bounds too loosely. Nix fails at compilation of the dependencies with some absurd error messages and you are forced to blindly influence the cabal solver by adding version bounds in your own cabal.project. Here is an example of this from this flake. Also, is it the case that the haskell.nix tooling provides cabal packages, ignoring completely cabal projects of those packages (which contain information needed for the cabal solver)? This would mean that the packages will always be broken with current tooling. Some solution on our side is to provide ala stackage snapshots for cardano packages. This would include some list of packages with their respective commits and a cabal.project file with all the corrections. I can provide one such snapshot with some recent versions of popular packages once I have it.

brainrake commented 1 year ago

Thank you @zmrocze for your comments. Hopefully we can turn them into actionable issues.

brainrake commented 1 year ago
  1. arguments are passed to project so cabalProject' https://input-output-hk.github.io/haskell.nix/reference/library.html#cabalproject
zmrocze commented 1 year ago
  1. Also the template doesn't seem to work? 
    
> cabal build all
Warning:
/home/zmrocze/mlabs/mlabs-tooling.nix/templates/haskell/cabal.project:
Unrecognized field 'hs-source-dirs' on line 3
/home/zmrocze/mlabs/mlabs-tooling.nix/templates/haskell/cabal.project:
Unrecognized field 'name' on line 2
/home/zmrocze/mlabs/mlabs-tooling.nix/templates/haskell/cabal.project:
Unrecognized field 'version' on line 1
Warning: No remote package servers have been specified. Usually you would have
one specified in the config file.
Resolving dependencies...
Build profile: -w ghc-9.2.5 -O1
In order, the following will be built (use -v for more details):
- mydepdep-0.0.1 (lib:mydepdep) (first run)
- mydep-0.0.1 (lib:mydep) (first run)
- myapp-0.0.1 (exe:myapp) (first run)
Error: cabal: Failed to build mydepdep-0.0.1 (which is required by
myapp-0.0.1). The failure occurred during the configure step. The exception
was:
dieVerbatim: user error (Error: cabal: Using 'build-type: Custom' but there is
no Setup.hs or Setup.lhs
script.
)
brainrake commented 1 year ago
  1. flake-parts is used incorrectly here, the whole thing should be a flake-parts module instead of a function that calls mkFlake
bladyjoker commented 1 year ago

This is what I have now (with Using index-state 2022-12-13T00:00:00Z)

$ cat cabal.project
packages: ./.

write-ghc-environment-files: never

test-show-details: streaming

$ cat flake.nix
{
  description = "Validators";
  inputs = {
    haskell-nix.url = "github:input-output-hk/haskell.nix";
    cardano-haskell-packages.url = "github:input-output-hk/cardano-haskell-packages?ref=repo";
    cardano-haskell-packages.flake = false;
    nixpkgs.follows = "haskell-nix/nixpkgs-unstable";
    flake-parts.url = "github:hercules-ci/flake-parts";
    mlabs-tooling.url = "github:mlabs-haskell/mlabs-tooling.nix";
    mlabs-tooling.inputs.cardano-haskell-packages.follows = "cardano-haskell-packages";
    plutarch.url = "github:Plutonomicon/plutarch-plutus";
  };

  outputs = inputs@{ self, nixpkgs, haskell-nix, flake-parts, mlabs-tooling, plutarch, cardano-haskell-packages }:
    flake-parts.lib.mkFlake { inherit inputs; } {
      imports = [
        (mlabs-tooling.lib.mkHaskellFlakeModule1 {
          project = {
            name = "unbox-validators";
            src = ./.;
            compiler-nix-name = "ghc925";
            extraHackage = [
              "${plutarch}"
              "${plutarch}/plutarch-extra"
              "${plutarch}/plutarch-test"
            ];
            shell.withHoogle = true;
          };
        })
      ];
      systems = [ "x86_64-linux" ];
    };
}

Adding a plutus-script-utils dependency to my Cabal config goes into

[__1] trying: plutus-script-utils-1.2.0.0 (dependency of unbox-validators)
[__2] next goal: tagged (dependency of plutus-script-utils)
[__2] rejecting: tagged-0.8.6.1 (conflict: plutus-script-utils =>
tagged^>=0.8.7)
[__2] skipping: tagged-0.8.6, tagged-0.8.5, tagged-0.8.4, tagged-0.8.3,
tagged-0.8.2, tagged-0.8.1, tagged-0.8.0.1, tagged-0.8, tagged-0.7.3,
tagged-0.7.2, tagged-0.7.1, tagged-0.7, tagged-0.6.1, tagged-0.6, tagged-0.5,
tagged-0.4.5, tagged-0.4.4, tagged-0.4.3, tagged-0.4.2.1, tagged-0.4.2,
tagged-0.4.1, tagged-0.4, tagged-0.3, tagged-0.2.3.1, tagged-0.2.3,
tagged-0.2.2.3, tagged-0.2.2.2, tagged-0.2.2.1, tagged-0.2.2, tagged-0.2.1,
tagged-0.2, tagged-0.1.1, tagged-0.1.0, tagged-0.0 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '^>=0.8.7' from 'plutus-script-utils')
[__2] fail (backjumping, conflict set: plutus-script-utils, tagged)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: plutus-script-utils, tagged,