我在 conda 环境中自行构建了 PyTorch（见 用特定的 CUDA 版本构建 PyTorch 并打包 Conda 环境），所以导出为配置文件、再重新安装的方式行不通。考虑到 Conda 环境本质上是一个文件夹，我尝试将其完整导出。

直接导出整个文件夹

导出

首先先把环境 clone 一遍，这样就可以直接打包：

conda create -n torch241_build_copy --copy --clone torch241_build

但是因为服务器磁盘非常慢，想到之后还要再打包一次，所以放弃了。改成直接用 tar 进行打包，并且在遇到链接的时候解引用：

tar --zstd -cv --dereference --exclude='*.pyc' -f torch241_build.tar.zst /opt/miniforge3/envs/torch241_build
# 更建议用：
# cd /opt/miniforge3/envs/
# tar --zstd -cv --dereference --exclude='*.pyc' -f /tmp/torch241_build.tar.zst torch241_build

• --hard-dereference 不需要加，只用 --dereference 就可以。
  • https://unix.stackexchange.com/questions/43037/dereferencing-hard-links 回答了 tar 的硬链接记录功能：如果 tar 发现了文件有硬链接，会将这个信息记录在 .tar 文件中，解压的时候应该会重新链接起来。
• 之前没有注意加 --exclude='*.pyc' 这个排除规则，导致打包有很多时间都浪费在了 .pyc 上面。
  • 加了这个规则之后生成 .tar.zst 文件的速度变快了。是因为 .pyc 不好压缩，拖累了 zstd 速度吗？

导入

创建一个同名环境，然后强制删除它（不用 conda 删除）：

mamba create -n torch241_build
rm -rf /opt/miniforge3/envs/torch241_build/

然后创建一个临时文件夹并进入，将之前打包的东西解压到这里来，看看打包的层次结果是什么样的，然后将 torch241_build 这一个文件夹移动到 /opt/miniforge3/envs/ 下。

mv torch241_build/ /opt/miniforge3/envs/

如果创建的新环境名 A 和打包的文件夹名 B 不同，重命名文件夹为 A 即可。一开始创建的环境名就是最终要使用的环境名。

以上打包方式在后来发现的问题

1. 类似于 warning libmamba Extracted package cache '/opt/miniforge3/pkgs/libzlib-1.2.13-h4ab18f5_6' has invalid url 的警告。可能需要用 mamba clean -i 清理一下旧的 cache。
2. 上面打包方式包含了 opt/miniforge3/envs/ 这个前缀，其实最好是进入 envs 之后只对 torch241_build 打包，避免把 opt、miniforges3、env 这些目录也放进去。
3. opencv 报错：ImportError: libGL.so.1: cannot open shared object file: No such file or directory。尝试 pip install opencv-python-headless 没解决，尝试 mamba -c menpo opencv 也没解决。最后是把它们都卸载了，安装 numpy==2.0.2 然后安装 opencv-python-headless 才解决的。挺奇怪的。
4. 导出到一个绝对路径不同的环境会出现问题，环境中有些配置文件硬编码了路径。我之前是两台服务器间转移数据，使用的环境是基于同一个镜像创建的容器，所以没有问题。
5. Jupyter Notebook 报错：

ImportError: /opt/miniforge3/envs/torch241_build/lib/python3.12/lib-dynload/_sqlite3.cpython-312-x86_64-linux-gnu.so: undefined symbol: sqlite3_deserialize. 
View Jupyter <a href='command:jupyter.viewOutput'>log</a> for further details."