nix-config: b1eb3de7b96f6de60616790ebcd76f71b0954c59

     1: From: Chris Warburton
     2: Date: Wed, 11 Apr 2018 14:52:48 +0100
     3: State: resolved
     4: Subject: Make it simple to use fixed, latest and <path> deps
     5: Message-Id: <c1e4ee1a8ba1b000-0-artemis@nixos>
     6: resolution: fixed
     7: 
     8: It's nice to give projects a release.nix file so they can be built and
     9: tested on Hydra. It's also nice to run those builds against different
    10: versions of the project's dependencies.
    11: 
    12: Sometimes we have a "pinned" version of some dependency, so we
    13: definitely want to build against that (since it's the recommended one to
    14: use).
    15: 
    16: Sometimes our dependency is taken from a git repo, so we should try
    17: building against the latest commit (so we can see if any breakages have
    18: been introduced).
    19: 
    20: Sometimes our dependency is given via Hydra, e.g. <foo>, so we should
    21: try building against that if given (since that lets us track builds
    22: against versions more easily).
    23: 
    24: To make this easier, we should provide a function which takes a repo,
    25: revision/sha256 combo and an optional path, and returns those 2 or 3
    26: things.
    27: 
    28: For example:
    29: 
    30: { url, rev ? null, sha256 ? null, path ? null }:
    31: 
    32: with rec {
    33:   pinned = if rev == null || sha256 == null
    34:               then {}
    35:               else {
    36:                 pinned = latestGit {
    37:                   inherit url;
    38:                   stable = { inherit rev sha256; };
    39:                 };
    40:               };
    41: 
    42:   latest = latestGit {
    43:     inherit url;
    44:     stable = { unsafeSkip = true; };
    45:   };
    46: 
    47:   fromPath = if path == null
    48:                 then {}
    49:                 else with tryEval path;
    50:                      if success
    51:                         then { fromPath = path; }
    52:                         else {};
    53: };
    54: { inherit latest; } // pinned // fromPath
    55: 
    56: We should maybe also add an assert that we're stable, since this feature
    57: seems like it would only make sense from a stable checkout (it's
    58: providing the unstable ones!) and also we want to ensure that  latestGit
    59: behaves as we expect for pinned versions (rather than always getting the
    60: unstable one).
    61: 
    62: This way, a release.nix file can import a pinned nix-config and use this
    63: function to cover all the bases w.r.t. "top level inputs" (e.g. those
    64: which we'd pass in via Hydra). In particular we could use this to handle
    65: dependencies on nix-config itself, e.g.
    66: 
    67: with {
    68:   pinnedCfg = {
    69:     url    = http://chriswarbo.net/git/nix-config.git;
    70:     rev    = "foo";
    71:     sha256 = "bar";
    72:   };
    73: 
    74:   configuredPkgs = import ((import <nixpkgs> {}).fetchgit pinnedCfg) {};
    75: 
    76:   versions = depVersions (pinnedCfg // { path = <nix-config>; });
    77: };
    78: configuredPkgs.lib.mapAttrs (_: cfg: import ./. { inherit cfg; })
    79:                             versions
    80: 
    81: This way we get a 'latest', a 'pinned' and a 'fromPath' build, with
    82: nix-config taken from those sources.
    83: 
    84: To prevent a combinatorial explosion it might be better to allow all
    85: dependencies to be handled at once, e.g. taking arguments like:
    86: 
    87: {
    88:   cfg = { url = ...; rev = "..."; sha256 = "..."; path = <...>; };
    89:   foo = { url = ...; rev = "..."; sha256 = "..."; path = <...>; };
    90:   bar = { url = ...; rev = "..."; sha256 = "..."; path = <...>; };
    91:   ...
    92: }
    93: 
    94: And returning a set like:
    95: 
    96: {
    97:   pinned   = { cfg = ...; foo = ...; bar = ...; ... };
    98:   latest   = { cfg = ...; foo = ...; bar = ...; ... };
    99:   fromPath = { cfg = ...; foo = ...; bar = ...; ... };
   100: }