Conda 安装自建 Python 包时出现 site-packages 和 CLI 脚本路径错位（如落至 /site-packages/ 而非标准 /lib/python3.x/site-packages/），根本原因是 meta.yaml 中缺失 python 运行时依赖声明，导致 Conda 无法识别其为 Python 包，从而跳过 Python 专用路径布局逻辑。
conda 安装自建 python 包时出现 `site-packages` 和 cli 脚本路径错位（如落至 `
在使用 conda build 构建纯 Python 包（如 ssstack）后，若通过 conda create -n env_name -c <local_channel> package_name</local_channel> 一次性创建并安装环境，常会遇到模块和 CLI 工具“消失”——实际是被错误地安装到了环境根目录下：
- ❌ 错误路径：
<env_root>/site-packages/ssstack/</env_root>（应位于lib/python3.12/site-packages/） - ❌ 错误脚本路径：
<env_root>/python-scripts/ssstack</env_root>（应位于bin/ssstack或Scripts/ssstack.exe）
而令人困惑的是：先创建空 Python 环境，再 conda activate && conda install 却一切正常。这种差异并非偶然，而是 Conda 在环境初始化阶段对包类型识别机制的关键体现。
? 根本原因：Conda 需显式声明 python 作为 run 依赖
Conda 并不会仅凭 build.script 中调用 pip install . 就自动推断该包是 Python 包。它依赖 requirements.run 中是否存在 python（或带版本约束的 python >=3.8）来触发 Python-specific installation layout logic —— 包括：
- 自动将
site-packages映射到<env_root>/lib/pythonX.Y/site-packages/</env_root>（Linux/macOS）或<env_root>/Lib/site-packages/</env_root>（Windows）； - 正确处理
entry_points，将 CLI 脚本符号链接/复制至<env_root>/bin/</env_root>（POSIX）或<env_root>/Scripts/</env_root>（Windows）； - 在构建产物文件名中注入
_py312等标识（如ssstack-0.4.0-py312_1.tar.bz2），这是关键诊断线索：若生成的包名不含_py*，即表明 Conda 未启用 Python 模式。
你的原始 meta.yaml 中 requirements.run 缺失 python，导致 Conda 将其视为“通用包”（generic package），采用扁平化安装策略，故所有内容直接解压到环境根目录。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
✅ 正确修复：补全 run 依赖并验证构建产物
只需在 meta.yaml 的 requirements.run 下方添加 python（推荐带版本约束，与 host.python 一致）：
requirements:
host:
- pip
- python >=3.8
- setuptools
run:
- python >=3.8 # ← 关键修复：必须声明！
- conda
- conda-lock
- packaging
- pydantic
- pyyaml
- requests
- tabulate
- tqdm
- typer? 提示：
noarch: python已表明这是纯 Python 包，但run中的python依赖仍是强制性元信息，不可省略。
修改后重新构建并安装：
conda build . --output-folder ./conda-bld conda create -n ssstack_test -c ./conda-bld ssstack conda activate ssstack_test python -c "import ssstack; print(ssstack.__file__)" # 应输出 lib/python3.12/site-packages/ssstack/__init__.py which ssstack # Linux/macOS：应显示 bin/ssstack；Windows：Scripts\ssstack.exe
⚠️ 注意事项与最佳实践
-
不要依赖
host.python推断run.python：host是构建期依赖，run是运行期依赖，二者语义独立。即使host中已声明python，run仍需显式写出。 -
避免
noarch: python+run: []空列表：这会导致 Conda 降级为noarch: generic行为，彻底绕过 Python 路径规则。 -
验证构建产物命名：成功后，
conda-build输出的包文件名应含_py312（或对应 Python 版本）后缀。若仍为ssstack-0.4.0-1.tar.bz2，说明修复未生效，请检查meta.yaml是否被正确加载（可加--debug参数排查）。 - 兼容性说明：该行为在 conda ≥ 23.7+ 中更严格（旧版可能容忍缺失），因此升级 conda 后旧配方易突然失效——这正是你观察到“以前能用，现在不行”的原因。
✨ 总结
Conda 的包类型识别高度依赖 meta.yaml 的显式声明。一个看似冗余的 - python 行，实则是开启 Python 环境路径语义的“密钥”。与其调试安装后路径，不如在构建源头确保元信息完备：所有 Python 包的 requirements.run 必须包含 python（建议带版本）。这一原则同样适用于 conda-forge 提交、CI/CD 流水线及团队协作中的可复现构建。
