解决具有两个 Nix Flake 设置的“路径 <...> 无效”问题

**文章摘要** 在使用 Nix Flake 构建包含主应用程序和插件的设置时，可能会遇到“路径无效”错误。这是因为插件中生成的文件包含 Nix 存储路径，违反了供应商派生的依赖限制。要解决此问题，需要将插件源代码复制到一个中间派生中，这样 replace 路径就可以是相对的，从而避免引用其他 Nix 存储路径。

我有两个 nix flakes：一个包含一个应用程序，另一个包含该应用程序的插件。当我使用插件构建应用程序时，出现错误

error: path '/nix/store/3b7djb5pr87zbscggsr7vnkriw3yp21x-mainapp-go-modules' is not valid

我不知道这个错误意味着什么以及如何修复它，但我可以在 macos 和 linux 上重现它。问题路径是第一步buildgomodule生成的vendor目录。

重现错误的最小设置需要一堆文件，因此我提供了一个带注释的 bash 脚本，您可以在空文件夹中执行该脚本来重新创建我的设置：

#!/bin/bash

# i have two flakes: the main application and a plugin.
# the mainapp needs to be inside the plugin directory
# so that nix doesn't complain about the path:mainapp
# reference being outside the parent's root.
mkdir -p plugin/mainapp

# each is a go module with minimal setup
tee plugin/mainapp/go.mod </dev/null
module example.com/mainapp

go 1.16
eof
tee plugin/go.mod </dev/null
module example.com/plugin

go 1.16
eof

# each contain minimal go code
tee plugin/mainapp/main.go </dev/null
package main

import "fmt"

func main() {
    fmt.println("hello, world!")
}
eof
tee plugin/main.go </dev/null
package plugin

import log

func init() {
    fmt.println("initializing plugin")
}
eof

# the mainapp is a flake that provides a function for building
# the app, as well as a default package that is the app
# without any plugins.
tee plugin/mainapp/flake.nix <<'eof' >/dev/null
{
  description = "main application";
  inputs = {
    nixpkgs.url = github:nixos/nixpkgs/nixos-21.11;
    flake-utils.url = github:numtide/flake-utils;
  };
  outputs = {self, nixpkgs, flake-utils}:
  let
    # buildapp builds the application from a list of plugins.
    # plugins cause the vendorsha256 to change, hence it is
    # given as additional parameter.
    buildapp = { pkgs, vendorsha256, plugins ? [] }:
      let
        # this is appended to the mainapp's go.mod so that it
        # knows about the plugin and where to find it.
        requireplugin = plugin: ''
          require ${plugin.goplugin.gomodname} v0.0.0
          replace ${plugin.goplugin.gomodname} => ${plugin.outpath}/src
        '';
        # since buildgomodule consumes the source two times –
        # first for vendoring, and then for building –
        # we do the necessary modifications to the sources in an
        # own derivation and then hand that to buildgomodule.
        sources = pkgs.stdenvnocc.mkderivation {
          name = "mainapp-with-plugins-source";
          src = self;
          phases = [ "unpackphase" "buildphase" "installphase" ];
          # write a plugins.go file that references the plugin's package via
          #   _ = ""
          plugins_go = ''
            package main
              
            // code generated by nix. do not edit.
          
            import (
                ${builtins.foldl' (a: b: a + "\n\t_ = \"${b.goplugin.gomodname}\"") "" plugins}
            )
          '';
          go_mod_append = builtins.foldl' (a: b: a + "${requireplugin b}\n") "" plugins;
          buildphase = ''
            printenv plugins_go >plugins.go
            printenv go_mod_append >>go.mod
          '';
          installphase = ''
            mkdir -p $out
            cp -r -t $out *
          '';
        };
      in pkgs.buildgomodule {
        name = "mainapp";
        src = builtins.trace "sources at ${sources}" sources;
        inherit vendorsha256;
        nativebuildinputs = plugins;
      };
  in (flake-utils.lib.eachdefaultsystem (system:
    let
      pkgs = nixpkgs.legacypackages.${system};
    in rec {
      defaultpackage = buildapp {
        inherit pkgs;
        # this may be different depending on your nixpkgs; if it is, just change it.
        vendorsha256 = "sha256-pqpattms9vmo3ziqufn66az8gsmb4ivyhttcfn6sumo=";
      };
    }
  )) // {
    lib = {
      inherit buildapp;
      # helper that parses a go.mod file for the module's name
      pluginmetadata = gomodfile: {
        gomodname = with builtins; head
          (match "module ([^[:space:]]+).*" (readfile gomodfile));
      };
    };
  };
}
eof

# the plugin is a flake depending on the mainapp that outputs a plugin package,
# and also a package that is the mainapp compiled with this plugin.
tee plugin/flake.nix <<'eof' >/dev/null
{
  description = "mainapp plugin";
  inputs = {
    nixpkgs.url = github:nixos/nixpkgs/nixos-21.11;
    flake-utils.url = github:numtide/flake-utils;
    nix-filter.url = github:numtide/nix-filter;
    mainapp.url = path:mainapp;
    mainapp.inputs = {
      nixpkgs.follows = "nixpkgs";
      flake-utils.follows = "flake-utils";
    };
  };
  outputs = {self, nixpkgs, flake-utils, nix-filter, mainapp}:
  flake-utils.lib.eachdefaultsystem (system:
    let
      pkgs = nixpkgs.legacypackages.${system};
    in rec {
      packages = rec {
        plugin = pkgs.stdenvnocc.mkderivation {
          pname = "mainapp-plugin";
          version = "0.1.0";
          src = nix-filter.lib.filter {
            root = ./.;
            exclude = [ ./mainapp ./flake.nix ./flake.lock ];  
          };
          # needed for mainapp to recognize this as plugin
          passthru.goplugin = mainapp.lib.pluginmetadata ./go.mod;
          phases = [ "unpackphase" "installphase" ];
          installphase = ''
            mkdir -p $out/src
            cp -r -t $out/src *
          '';
        };
        app = mainapp.lib.buildapp {
          inherit pkgs;
          # this may be different depending on your nixpkgs; if it is, just change it.
          vendorsha256 = "sha256-a6hfgfs1bu9ekxwi+dxh5qy2kbcdpzgp7wx6byai4hw=";
          plugins = [ plugin ];
        };
      };
      defaultpackage = packages.app;
    }
  );
}
eof

您需要安装具有 flake 支持的 nix 才能重现该错误。 在该脚本创建的plugin文件夹中，执行

$ nix build
trace: sources at /nix/store/d5arinbiaspyjjc4ypk4h5dsjx22pcsf-mainapp-with-plugins-source
error: path '/nix/store/3b7djb5pr87zbscggsr7vnkriw3yp21x-mainapp-go-modules' is not valid

（如果散列不匹配，只需使用正确的散列更新薄片即可；我不太确定在存储库之外传播薄片时的散列是否可重现。）

源目录（由跟踪显示）确实存在并且看起来没问题。错误消息中给出的路径也存在，并且包含具有预期内容的 modules.txt。

在文件夹 mainapp 中，nix build 确实运行成功，这会在没有插件的情况下构建应用程序。那么我对使路径无效的插件做了什么？

正确答案

原因是，在这种情况下，作为供应商的一部分生成的文件 modules.txt 将在 replace 指令中包含 nix 存储路径。 vendor 目录是固定输出派生，因此不得依赖于任何其他派生。 modules.txt 中的引用违反了这一点。

这只能通过将插件的源代码复制到 sources 派生中来修复 - 这样，replace 路径可以是相对的，因此不会引用其他 nix 存储路径。

本篇关于《解决具有两个 Nix Flake 设置的“路径 <...> 无效”问题》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！