python - conda 包的平台独立构建

Question

我正在尝试构建一个包含单个 Python 包的 conda 包，该包在导入时读取静态文件。虽然包本身工作正常，但包的位置最终取决于用于构建包的平台，因此最终不可能在与构建包不同的平台上导入包。

由于根本不存在任何平台依赖性，并且 conda 允许通过 noarch 跨平台包，因此似乎应该可以在单个平台上构建包，而不是每个平台不止一次。

这是一个最小的示例:

/setup.py:

from setuptools import setup, find_packages


setup(
    name='mypackage',
    description='My platform independent package',
    packages=find_packages(),
    data_files=[('mypackage', ['mypackage/myfile.txt'])]
)

/conda_recipe/meta.yaml:

{% set data = load_setup_py_data() %}

build:
  noarch: python

package:
  name: mypackage

source:
  path: ..

requirements:
  build:
    - python
    - setuptools

about:
  summary: {{ data.get('description') }}

/mypackage/myfile.txt:

foo

/mypackage/__init__.py:

import os

# Print contents of myfile.txt when the package is imported
with open(os.path.join(os.path.dirname(__file__), 'myfile.txt')) as f:
    print(f.read())

通过删除 meta.yaml 的 noarch: python 部分，我可以构建可在其构建平台上运行的包。但是，如果我在 Windows 上使用 conda build 构建 noarch 包，并在任一平台上使用 conda install 它，则 Python 模块和数据文件结束在 {conda-env}/Lib/site-packages 中，而如果我在 Linux 上构建它，并在任一平台上 conda install 它，它们最终会在 >{conda-env}/lib/python3.7/site-packages(注意小写的l)。

这是一个问题，因为确定包含路径的环境变量在两个平台上不同。结果是，在 Windows 上构建的包在 Windows 上运行良好，在 Linux 上构建的包在 Linux 上运行良好，但在一个平台上构建的包将无法在另一平台上运行；特别是，Linux 上的 Miniconda 默认情况下在 sys.path 中包含后一个路径，因此它将无法找到在 Windows 上构建、在 Linux 上安装的软件包。

也就是说，我不能简单地在一个平台上构建包，将其转储到我的 channel 上的 noarch 中，然后就高兴了，即使包内容本身是独立于平台的。当然，静态数据文件不是这里的罪魁祸首，但无论如何我都将其包含在我的问题中，只是因为确保它们最终位于正确的位置本身就很重要。

在 Windows 和 WSL 上使用最新版本的 Miniconda 时会出现此问题。

所以我的问题变成:

If I want to build a conda package containing nothing but a simple file, and an __init__.py reading this file when I import the package, can I get away with building the package on a single platform?

Answer 1

在 Windows 和 Linux 上更新 conda-build 和 Python 后，我无法再重现我的问题；安装后，这些软件包仍将位于不同的目录中:lib/python3.8/site-packages在 Linux 上和 lib/site-packages在 Windows 上；相当奇怪的是l现在在 Windows 上为小写，由于 Windows 就是 Windows，因此这并不重要。

不幸的是，这对原始问题的了解很少，但至少这应该足以开始。

特别是，以下步骤适用于我最初问题中包含的最小示例，使用 WSL 测试在 Windows 上构建的包:

1. 创建一个新环境，mypackage-build ，激活它，然后运行conda install python conda-build .
2. 在 Windows 上，使用 conda build conda_recipe 构建软件包.
3. 在不指定任何其他内容的情况下，构建的包最终会出现在 C:\Users\username\AppData\Local\Continuum\miniconda3\envs\mypackage-build\conda-bld 中在我的机器上。
4. 停用构建环境，创建一个名为 mypackage-test 的新环境，激活它，安装Python，并使用 conda install -c C:\Users\username\AppData\Local\Continuum\miniconda3\envs\mypackage-build\conda-bld mypackage 安装上面构建的包.
5. 运行where python确保python.exe正在从 mypackage-test 中获取环境，运行Python，调用import mypackage ，并注意该包确实已导入。
6. 在 WSL 上，创建一个名为 mypackage-test-wsl 的新环境，激活它，安装Python，然后运行conda install -c /mnt/c/Users/username/AppData/Local/Continuum/miniconda3/envs/mypackage-build/conda-bld mypackage (如果驱动器安装方式不同，则进行相应修改)。
7. 运行 Python，import mypackage ，并注意一切正常(这是我最初遇到问题的地方)。
8. 镜像该过程，在 WSL 上构建软件包，将其安装在 Windows 上，然后注意一切正常。

我在测试上述内容时确实遇到了一个问题，所以为了完整性，让我在这里记下这一点:第一次创建 mypackage-test 时，我是从 mypackage-build 这样做的。环境。因此，即使软件包将安装在 mypackage-test 中，来自父环境的 Python 运行时将优先(我认为这很奇怪，但没关系)，这将导致上面的“步骤 5”失败；

>where python
C:\Users\username\AppData\Local\Continuum\miniconda3\envs\mypackage-build\python.exe
C:\Users\username\AppData\Local\Continuum\miniconda3\envs\mypackage-build\envs\mypackage-test\python.exe
C:\Users\username\AppData\Local\Continuum\miniconda3\python.exe