如何共享可传递类型提示的存根？

如何解决如何共享可传递类型提示的存根？

我当前使用的是没有类型提示的Python库（x）。我选择为我在项目中使用的x方法添加存根文件，如下所示：

MyProject_1/
  stubs/
    x/ 
      __init__.pyi  # Contains type hints for any attributes of `x`.

  package_1/
    package_1_main.py  # Imports `x`.
    __init__.py   
    py.typed  # Indicates package 1 type hints are specified inline.

  setup.py  # Specifies `x` as a dependency under `install_requires` and `py.typed` under `package_data`.

然后在MyProject_1目录中，运行MYPYPATH=stubs mypy .。

如果package_1_main.py导入了x，则mypy成功键入了基于x的{​​{1}}导入提示。一切都很好。

现在，我已经制作了另一个依赖于stubs/x的项目MyProject_2，因为MyProject_1下的My_Project_2成功地使用了package_1_main.py中指定的内联类型提示。 py.typed。

问题是package_1在MyProject_2上没有接听。由于stubs/x是x到MyProject_2的传递依存关系，因此我可以在MyProject_1中使用x。但是，这没有在MyProject_2下指定的类型提示。

我可以想象有3种方法可以使用这些存根（从而访问stubs/x的类型提示）：

1. 在x中运行stubs时，将MyProject_1下的MYPYPATH目录添加到mypy .中。缺点是，它取决于如何通过MyProject_2安装MyProject_1，并且必须将pip作为stubs中分布式软件包数据的一部分。

2. 将setup.py下的stubs目录复制到MyProject_1，手动保持它们同步。缺点是维护方面的开销。

3. 创建一个名为MyProject_2的第三个项目，该项目专用于保留MyProject_Stubs依赖的任何项目的存根文件，无论是传递还是直接。缺点是专门用于存根的项目。

我还有其他方法可以考虑吗？而对于稍为固执的部分：这些方法中哪一种似乎具有最大的净优势？

解决方法

AFAIK不能暂时共享存根。

相反，您必须专注于寻找使存根可用于两个项目/使其成为两个项目的依赖的方法。

大约有六种不同的方法可以实现，我将以递增的顺序列出这些方法。

1. 将存根存储在本地计算机上的某个位置，并让您的两个项目都通过MYPYPATH环境变量或配置文件选项对其进行引用。

   这是相对简单的操作，但是缺点是您的项目只能在本地计算机上运行。如果您计划让其他人使用此项目，则他们需要获取您的存根并设置他们的MYPYPATH。

2. 将存根复制到第二个项目。如您所说，这里的主要缺点是您现在需要手动保持存根同步。

3. 为您的存根创建一个单独的git repo，并将其作为git submodule添加到您的两个项目中。

   这解决了选项2所具有的代码重复问题。唯一真正的缺点是，每次更新存根回购时，您都需要记住在两个项目中都碰到子模块引脚。

4. 将项目的类型提示贡献给typeshed Python类型提示的存储库，然后等待下一个mypy版本发布，或者使用--custom-typeshed-dir flag / config选项运行mypy。>

   请注意，Typeshed接受partial stubs，并希望在将来的某个时间切换到更多iterative and rapid release cadence。

   如果您想广泛地开源您的工作，但不一定希望在存根之后再承担维护存根的负担，那么此选项将是最好的选择。

   主要缺点是您将无法立即解除封锁。

5. 使用X-stubs文件创建一个py.typed包。这类似于您的选项3，不同之处在于您的新项目明确地仅用于项目X的存根并且是开源的。

   然后，您可以像任何pip包一样将X-stubs包添加到pip依赖项中，甚至可能最终考虑更广泛地开放源代码并分发它们。

   这与选项3基本相同，不同之处在于包的名称不同且不特定于您的项目。

6. 向项目X提交拉取请求，添加一个py.typed文件以及一些类型提示，并说服它们着陆。

   这说起来容易做起来难，当然-当然，并非所有项目都愿意接受类型提示，因为这可能导致它们增加维护负担。

如果您只想解锁自己，我会选择1-3。如果您还想尝试开放源代码工作并帮助改善Python输入生态系统，则其他选项更合适。

我会避免您的选项1 －设置它的工作量似乎与选项3和5大致相同，同时还需要在项目2中进行更多工作才能使用。