我正在尝试构建一个conda包，其中包含一个Python包，该包在导入时会读取静态文件。尽管程序包本身可以正常工作，但程序包的位置最终取决于用于构建程序包的平台，因此最终无法在与用于构建程序包的平台不同的平台上导入程序包。
由于根本没有任何依赖平台的情况，并且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())
通过删除的noarch: python部分meta.yaml，我可以构建在其构建平台上工作的软件包。但是，如果我在Windows上noarch使用该软件包构建conda build，并且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，因此它将无法找到在Linux上安装的Windows上构建的软件包。
也就是说noarch，即使包内容本身与平台无关，我也不能简单地在一个平台上构建包，将其转储到我的频道中并感到高兴。当然，静态数据文件不是这里的罪魁祸首，但是无论如何我都将其包含在我的问题中，仅仅是因为确保将其最终放置在正确的位置本身并不是一件容易的事。
在Windows和WSL上使用最新版本的Miniconda时，会发生此问题。
所以我的问题变成：
如果我要构建一个仅包含一个简单文件的conda软件包，并且
__init__.py在导入该软件包时读取该文件，那么我能否摆脱在单个平台上构建该软件包的麻烦？
在Windows和Linux上更新conda-build和Python之后，我不再能够重现我的问题。安装后，这些软件包仍将位于不同的目录中：lib/python3.8/site-packages在Linux和lib/site-packagesWindows上；奇怪的l是Windows上现在是小写，由于Windows是Windows，所以最终没关系。
不幸的是，这对原始问题的了解很少，但是至少这应该足以开始。
特别地，以下步骤适用于我的原始问题中包含的最小示例，即使用WSL测试基于Windows的程序包：
mypackage-build激活它并运行conda install python conda-build。conda build conda_recipe。C:\Users\username\AppData\Local\Continuum\miniconda3\envs\mypackage-build\conda-bld我的计算机上。mypackage-test，将其激活，安装Python，并使用来安装上面构建的软件包conda install -c C:\Users\username\AppData\Local\Continuum\miniconda3\envs\mypackage-build\conda-bld mypackage。where python以确保python.exe从mypackage-test环境中拾取该文件，运行Python，调用import mypackage，并注意该软件包确实已导入。mypackage-test-wsl，将其激活，安装Python，然后运行conda install -c /mnt/c/Users/username/AppData/Local/Continuum/miniconda3/envs/mypackage-build/conda-bld mypackage（如果驱动器安装不同，则进行相应修改）。import mypackage，并注意一切正常（这是我最初遇到问题的地方）。在测试上述内容时，我确实碰到了一个陷阱，因此为了完整起见，请在此进行说明：第一次创建时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
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句