带有后备实施的包装Python绑定的最佳实践（PEP 518）

Question

让我们考虑以下示例。 有一个静态的C ++库libfoo，分布成CMake子项目。 现在，有一个称为pyfoo的python实现，该实现应为libfoo提供python绑定（使用pybind11）， 但是，如果无法构建libfoo 在目标平台上。

这样一个项目的存储库看起来就是这样：

 +--+ libFoo
 |  +--- CMakeLists.txt (export a static library target foo::foo)
 |  +--- src/..., inc/... (c++ sources for libFoo)
 |
 +--+ pyFoo
    +--- pyproject.toml
    +--- ... (other metadata/package files, tests, etc)
    +--+ foo (main package dir)
       +--+ _native
       |  +--- CMakeLists.txt (imports libFoo/CMakeLists.txt as a subproject, configures, adds pybind11 module)
       |  +--- foo_bindings.cpp (literally pybind11 bindings using imported foo::foo)
       |
       +--- _fallback/... (pure Python implementation of libFoo for compatibility)
       +--- __init__.py (essentially "try: from ._native.foo_bindings import *; except ImportError: from ._fallback import *")

现在，这种结构对我来说是一个开发环境（pyfoo/foo/_native cmake cmake cmake cmake commake complate complate complate foo_bindings to >忍者安装）， 为了创建分布和车轮，这似乎不是处理构建本机（C ++）部分的正确方法。

我对其他软件包如何处理此类情况进行了一些研究，但是我只能找到以下方案：

• 软件包只是一个lib +绑定（没有纯Python实施），因此设置需要本机构建；
• 该软件包将使用CTYPES/CFFI导入外部库（例如Libssl.So），如果导入失败，则将其倒入Python实现，因此从构建系统的角度来看，它是一个纯粹的Python软件包。

我在这里要实现的目标是拥有一个可以在尽可能多的方案中使用的软件包，包括用户可能无法编译C ++源的情况（例如没有MSVC的Windows）和车轮无法用于其平台。

我将如何指定使用尽可能多的现代工具/解决方案（考虑使用PEP 518而不是将所有内容放入设置中）， 在保持界面简单清洁的同时？

pip安装pyfoo的所需决策树是：

• 如果当前平台有轮子，请使用它，
• 如果没有轮子，请尝试构建foo._native.bindings.bindings从源（使用CMAKE），包括libfoo的直接依赖性。
  • 如果构建成功，一切都还好吧，请在最终设置中使用foo._native.bindings
  • 如果构建失败，请不要断开设置，而是安装除foo._native package以外的所有内容。

奖励问题：如果foo._fallback具有附加的软件包依赖项（超出foo/foo.___native requience quients ，在pyproject.toml中列出它们是一个好习惯吗？如果默认实现是foo._native中的默认实现？

一般指针会没事的。我已经介绍了有关此事的几篇文章，但它们似乎是不完整或基本的。 例如[https://packaging.python.org/en/latest/guides/packaging-binary-extensions/]甚至给出以下示例：

示例：导入DateTime时，python返回DateTime.py模块，如果C实现（_DateTeTimeModule.c）可用。

但是随后无法解决体内的这种情况。