`nix`包管理器如何集成到经典的linux文件系统和`$PATH`中？

Question

背景

我们的团队目前正在努力应对开发环境。

我们开发C++/Python应用程序，需要各种各样的工具：
```
gcc, clang, cmake, conan
```
不同的python模块（甚至不同版本的解释器）等。到目前为止，每个开发人员都拥有一台装有Ubuntu的计算机，他们负责设置他们自己的环境。有一些丢失指南（即
```
gcc-12.0.0
```
、
```
clang-14.0.1
```
、
```
conan-1.59.0
```
等），但已经不止一次发生了一些人安装了
```
gcc-11
```
而不是
```
12
```
等的情况。构建过程引起了问题。
使情况进一步复杂化的是，构建服务器是 RedHat 或 CentOS，团队的某些特定部分使用 macOS 等。我们的软件在所有这些平台上编译得很好，但要达到这一点可能需要相当多的工作。

因此，我们基本上正在寻找一种拥有可重复开发环境的方法，仍然为每个开发人员留下足够的灵活性（即我们的构建系统基于

conan

和

cmake

，因此任何现代 IDE 都可以用于构建、调试，并运行项目）。

现在这不是一个新问题，但不幸的是 Stack Overflow 上的信息并不容易找到，甚至可能已经过时（例如这里）。

从互联网上阅读，似乎该问题的一种可能的解决方案称为

nix

。我不明白的是

nix

在操作系统和包管理器上下文中的作用。假设我面前有一台 Ubuntu 计算机。它具有文件系统上的所有标准位置（即

、

/bin

、

/home

等）。我现在可以：

现在想必我可以稍后使用这些已安装的软件包来构建我想要构建的软件，但是具体如何构建呢？如果它们不在

$PATH

中，那么我该如何使用它们？如果我将它们添加到

$PATH

，那么拥有它们有什么意义以及如何保证它们不会与

$PATH

内部已安装的内容发生冲突？我可以将此设置与我选择的任何 IDE 一起使用吗？

如果

nix

是解决我上面描述的问题的错误工具，我非常乐意考虑其他工具。

docker

似乎是一种选择，但这有其自身的缺点......

Answer 1

Nix 对于此类事情来说是一个很棒的工具。但不要考虑“配置”（该术语通常指 NixOS，您没有使用也不需要使用）。您应该做的是编写一个名为

shell.nix

的文件，其中包含 Nix 语言中的表达式，该表达式调用 mkShell 来定义您需要的所有依赖项。然后你在该目录中运行

nix-shell

，Nix 将自动构建/安装你需要的所有依赖项，然后在你的 PATH 上启动一个特殊的 shell，其中包含这些依赖项，位于系统默认内容的前面。然后您就可以在该 shell 中进行开发工作。