tweag / opam-nix

Turn opam-based OCaml projects into Nix derivations
MIT License
109 stars 32 forks source link

pin-depends fails to parse tags #12

Open ralsei opened 2 years ago

ralsei commented 2 years ago

Describe the bug When dealing with a pin-depend URL with a tag, such as git+https://github.com/foo/bar#0.1.0, opam-nix parses the tag as a SHA1:

error: hash '0.1.0' has wrong length for hash type 'sha1'

To Reproduce Here's my flake.nix:

{
  description = "Experimental implementation of Cartesian cubical type theory";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-22.05";
    flake-utils.url = "github:numtide/flake-utils";

    opam-repository = {
      url = "github:ocaml/opam-repository";
      flake = false;
    };

    opam-nix = {
      url = "github:tweag/opam-nix";
      inputs.nixpkgs.follows = "nixpkgs";
      inputs.flake-utils.follows = "flake-utils";
      inputs.opam-repository.follows = "opam-repository";
    };
  };

  outputs = { self
            , flake-utils
            , opam-nix
            , nixpkgs
            , opam-repository
            }@inputs:
    flake-utils.lib.eachDefaultSystem (system: {
      legacyPackages = let
        on = opam-nix.lib.${system};
      in on.buildDuneProject { } "cooltt" ./. {
        ocaml-base-compiler = null;
      };

      defaultPackage = self.legacyPackages.${system}."cooltt";
    });
}

and cooltt.opam:

opam-version: "2.0"
name: "cooltt"
version: "0.0"
maintainer: "Jonathan Sterling <jmsterli@cs.cmu.edu>"
authors: ["The RedPRL Development Team"]
homepage: "https://github.com/RedPRL/cooltt"
bug-reports: "https://github.com/RedPRL/cooltt/issues"
dev-repo: "git+https://github.com/RedPRL/cooltt.git"
synopsis: "Experimental implementation of Cartesian cubical type theory"
license: "Apache-2.0"
depends: [
  "dune" {>= "2.0"}
  "ocaml" {>= "4.10.0"}
  "ppx_deriving" {>= "4.4.1"}
  "bantorra"
  "bwd" {>= "1.2"}
  "cmdliner" {>= "1.1"}
  "containers" {>= "3.4"}
  "ezjsonm" {>= "1.2.0"}
  "menhir" {>= "20180703"}
  "uuseg" {>= "12.0.0"}
  "uutf" {>= "1.0.2"}
  "yuujinchou" {>= "2.0.0" & < "3"}
  "odoc" {with-doc}
  "kado"
]
pin-depends: [
  [ "kado.~dev" "git+https://github.com/RedPRL/kado" ]
  [ "bantorra.0.1.0" "git+https://github.com/RedPRL/bantorra#0.1.0" ]
]
build: [
  ["dune" "build" "-p" name "-j" jobs]
  ["dune" "build" "-p" name "-j" jobs "@runtest"] {with-test}
  ["dune" "build" "-p" name "-j" jobs "@doc"] {with-doc}
]

Expected behavior It should pull from the tag.

Environment

balsoft commented 2 years ago

Thanks! As a workaround, you can just put the SHA1 in there for now. I will look into the issue.

balsoft commented 2 years ago

Should be fixed now, please confirm :)

ralsei commented 2 years ago

This fails with:

[2 built, 0.0 MiB DL] fetching Git repository 'https://github.com/RedPRL/bantorrfatal: couldn't find remote ref refs/heads/0.1.0
error: program 'git' failed with exit code 128

because 0.1.0 isn't a branch, it's a tag.

balsoft commented 2 years ago

Oooff, right, that's annoying.

balsoft commented 2 years ago

I'm not sure I know of a good solution. We need to somehow make fetchGit { ref = "0.1.0"; <...> } fetch the 0.1.0 tag. Of course it is possible to hardcode ref = "refs/tags/0.1.0" but that is not great. It's also possible to do some tryEval hackery and try both ref = "refs/heads/0.1.0" and ref = "refs/tags/0.1.0" but that's quite horrible honestly.

ralsei commented 2 years ago

If you want to label this as wontfix that's fine, since it seems like a limitation of fetchGit to be fair

balsoft commented 2 years ago

I'll just try to fix the fetchGit annoyance ;)

balsoft commented 2 years ago

This (maybe) does it, although I'm not sure. https://github.com/NixOS/nix/pull/6766

At least it seems to resolve this specific problem.

balsoft commented 2 years ago

Also note that I recommend against using tags (or branches) anyways, since they make the evaluation impure and therefore much less reproducible. Just including the commit hashes is a simple enough change, but it can save a lot of headaches for other people or even future you when trying to build the project in five years. Specifying a commit sha1 hash will allow you to build without --impure, and it's not such a big deal to update it once in a while IMHO.