经过 ”安装包“我的意思是评估 Nix 构建表达式（使用nix-env、nix-shell -p等）从源代码构建，而不是使用代替。
起初发布在 Stackoverflow 上但 [Charles Duffy 指出][3] 如果它是关于命令行工具或配置的，那么在这里更合适。仍然把它留在那里，因为我假设通过使用 Nix 语言本身可以强制包始终从源代码编译，我只是还不知道如何做。 （或者如果实际上不可能，有人会指出，那么这个问题就属于这里。）
答案1
要么设置substitute选项在falsenix.conf（默认为true）或--option substitute false在调用 Nix 命令时使用。
nix-env --options substitute false -i hello
nix-shell --options substitute false -p hello
可能不是您要找的机器人
正如罗伯特·亨辛 (评论,聊天), 亨利·门克 (评论）和弗拉基米尔·丘纳特（评论）指出，这可能不是你真正追求的东西。
详细说明：我一直自信地使用最基本的 Nix 功能，但到了需要维护和部署用 C 编写的大型应用程序的自定义分支的地步，这在一开始就非常令人生畏。
试图用最简单的方法解决问题拿来我的叉子并用新的源代码重新构建它，所以我将其归结为这个问题。虽然，我怀疑对我来说正确的方向是Nixpkgs/创建和调试包在里面NixOS 维基。
仅重新构建包本身
弗拉基米尔·丘纳特 评论那 ”禁用替代品会让您重建本地缺少的所有内容，尽管我怀疑提出此类问题的人通常只想重建指定的包本身。”
（这可能是通过以下方式实现的nix-build或者“只是”覆盖原始包，但可能是错误的。 NixOS wiki 文章中提到了后者（甚至可能进行了演示？）开发环境与nix-shell但还没能彻底读懂。）
测试再现性
如果人们想确保后续构建是确定性的，那么他们可能会提出同样的问题。作为亨利·门克评论，应该用于nix-build --check此目的。
这个--check选项很容易被错过；它没有记录在man nix-build或nix-build在里面尼克斯手册，但因为nix-store --realize（如man nix-build解释一下）：
nix-build本质上是一个包装器nix-instantiate（将高级 Nix 表达式转换为低级存储派生）和nix-store --realise（构建存储派生）[因此]此处未列出的所有选项都传递给nix-store --realise，除了--arg和--attr/-A之外到nix-instantiate。
请参阅中的详细示例尼克斯手册在18.1.抽查构建确定性和紧随其后的下一部分。
配置选项的相关部分substitute如下这nix.conf部分来自尼克斯手册:
姓名
nix.conf— Nix 配置文件描述
Nix 从两个配置文件中读取设置：
系统范围的配置文件
sysconfdir/nix/nix.conf（即/etc/nix/nix.conf在大多数系统上），或者$NIX_CONF_DIR/nix.conf是否NIX_CONF_DIR已设置。用户配置文件
$XDG_CONFIG_HOME/nix/nix.conf，或者~/.config/nix/nix.conf如果XDG_CONFIG_HOME没有设置。
--option您可以使用标志覆盖命令行上的设置，例如--option keep-outputs false。目前可以使用以下设置：
[..]
代替
如果设置为 true（默认），Nix 将使用二进制替代品（如果可用）。可以禁用此选项以强制从源构建。
（原名use-binary-caches。）
笔记
如果命令多次发出，设置substitute为false（with--options或 in ）将不会重新编译包。nix.conf也就是说，hello上面的命令第一次会从源代码编译，然后如果再次发出命令，它将访问已经存在的存储路径。
这就是它变得模糊的地方：很明显，不会发生重新编译，因为除非包的 Nix 构建表达式不改变，否则存储输出哈希也不会改变，使得下一个编译输出等于前一个编译输出，因此行动将是多余的。
因此，如果有人要对一个包进行一些轻微的黑客攻击，并且只想在本地尝试一下（例如，使用nix-shell），那么就必须使用-I nixpkgs=a/local/nixpkgs/dir来获取这些更改 - 并最终进行重新编译？或者应该使用吗nix-build？
另请参阅问题如何nix-build重新建好商店路径？