<p>pip 19.0无法安装从CWD导入要安装的软件包的软件包</p>

pyinstaller如何导入自身进行安装似乎与这有关。

向PyInstaller人员提出问题可能是个好主意。

我们当前使用的是18.1，升级到19.0也会对我们造成此问题。 PyInstaller存储库上存在一个相关问题，这是因为pip''不在sys.path中。

https://github.com/pyinstaller/pyinstaller/issues/2730

我认为这是一个非常普通的工作流程。 您将__version__ = "1.2.3"放入foo/__init__.py ，然后将import foo放入setup.py这样就不必在两个地方指定版本。 图书馆的任何用户都可以根据PEP 396检查版本。

# foo/__init__.py
__version__ = "1.2.3"

# setup.py
from setuptools import setup

import foo

setup(..., version=foo.__version__)

此外，仅当您有pyproject.toml文件（和setup.py ）时，才会发生这种情况。 删除它，安装工作正常。 因此，那里的行为似乎有些差异。 也许传统方式修改sys.path / PYTHONPATH吗？

嗯，我想我知道发生了什么事。 由于使用pyproject.toml文件，您基本上是在告诉pip您要使用PEP 517/518。

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel"]

上面告诉pip它需要setuptools和wheel来构建PyInstaller。 但是在PyInstaller的情况下，它也在setup.py得到了它：

# setup.py
from PyInstaller import __version__

从PEP 517的角度来看，除了setuptools和wheel ，这意味着它需要自己来构建。 这当然有点奇怪。

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel", "PyInstaller"]

正如@cjerdonek在https://github.com/pypa/pip/issues/6175#issuecomment -456769285中所述，有人可以检查--no-use-pep517是否为他们解决了这个问题？

我怀疑此问题的原因是内部隔离或PEP 517代码不能确保软件包目录的根目录位于sys.path上，因为pandas在setup.py旁边有一个versioneer.py。 我记得在某个时候会出现这种情况，但我不记得我当时在讨论什么。 这可能是setuptools构建后端而不是pip的问题，或者可能是pip隔离机制的问题。

[...]有人可以检查--no-use-pep517是否为他们解决了这个问题？

PyInstaller可以使用--no-use-pep517 。

好的，那肯定是新的PEP 517代码存在的一个问题，我很确定问题只是包含项目根目录的目录尚未添加到sys.path 。 也许@pfmoore对pip的责任或setuptools有更好的了解。

如果它有帮助，则另一个示例（通过apache-airflow是pip install pendulum==1.4.4失败，但是pip install --no-use-pep517 pendulum==1.4.4可以工作。

我们得到的堆栈跟踪类似：

Collecting pendulum==1.4.4
  Using cached https://files.pythonhosted.org/packages/85/a5/9fc15751f9725923b170ad37d6c61031fc9e941bafd5288ca6ee51233284/pendulum-1.4.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command /Users/ash/.virtualenvs/clean-airflow/bin/python3.7 /Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/tmprosed3kj:
  Traceback (most recent call last):
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 207, in <module>
      main()
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requirements=['wheel'])
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 101, in _get_build_requires
      _run_setup()
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 47, in <module>
      from build import *
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/build.py", line 7, in <module>
      from pip._vendor import pytoml
  ModuleNotFoundError: No module named 'pip'

另外，以下安装也不适用于pip v 19.0，但如果使用--no-use-pep5517则可以：
pendulum == 1.5.0（AttributeError：模块'enum'没有属性'IntFlag'）
pendulum == 1.5.1（AttributeError：模块'enum'没有属性'IntFlag'）
摆锤== 2.0.0（AttributeError：模块'enum'没有属性'IntFlag'）
摆锤== 2.0.1（AttributeError：模块'enum'没有属性'IntFlag'）
pendulum == 2.0.2（AttributeError：模块'enum'没有属性'IntFlag'）

而2.0.3和2.0.4安装正常。

从19.0开始，cartopy（至少是最新版本）也无法安装，无法导入setup.py旁边的versioneer.py。

这也是我处理的某些项目的问题。 我们使用pyproject.toml定义我们的python黑色参数，并在setup.py中执行类似的from project.version import __version__ 。

至少我觉得能够在pyproject.toml中定义任何项目隔离都不够。 使任何想安装该项目的人使用--no-buid-isolation或--no-use-pep517对我来说似乎是不合理的

失败似乎在get_requires_for_build_wheel ，并且setuptools后端运行setup.py进行某种自省，以确定构建要求（具体代码在此处）。 该代码对我来说似乎很奇怪，我不明白为什么需要它。 我最初的直觉是这是setuptools后端中的错误，应该由他们解决。

PEP 517没有声明前端应该在将构建目录添加到sys.path的环境中运行钩子，并且存在潜在的问题，如果我们这样做，则可能会破坏隔离（如果构建目录包含的副本例如一些必需但未指定的软件包）。 因此，我的偏好是不将构建目录添加到sys.path 。 但是，这样做可以为这种回归提供快速解决方案，这样做可能是有利的。 不过，我认为项目不应该依赖于此。

概要：

1. 这应该报告给setuptools作为后端问题进行审查。 我会考虑在setuptools后端中修复它（可能只是通过将构建目录添加到sys.path ）作为理想的解决方案。
2. 如果setuptools不这样做，则pip可以将构建目录添加到sys.path ，但是我不认为PEP 517将其视为前端的责任。
3. 要求sys.path钩子可以看到构建目录，至少需要对PEP进行说明。

我不认为在开发PEP 517时会考虑这种情况。 也许是因为它是特定于setuptools的（或者更确切地说，是特定于在构建过程中运行任意Python代码的后端的）。

我认为人们通常将当前目录中的内容导入到setup.py ，并且通常将setup.py放在$PWD 。

我认为将这一责任推给setuptools是合理的，因为这可能是唯一真正需要它的项目。

是的，再考虑一下，我确定这是setuptools后端的责任。 在PEP 517之前，pip作为脚本运行了setup.py ，因此标准Python规则将脚本目录放到sys.path 。 在PEP 517下， setup.py调用被对后端挂钩的调​​用所取代，因此这些挂钩需要保留语义。 因为setuptools从钩子在进程中运行setup.py ，所以它需要管理sys.path本身。 希望对他们来说不是一个大解决方案。 @jeanlaroche （或其他遇到此问题的人）是否可以在setuptools跟踪器上提出问题，请回头参考此线程？

[...]有人可以检查--no-use-pep517是否为他们解决了这个问题？

我可以确认--no-use-pep517允许pip install pandas成功。

我还可以确认使用--no-use-pep517可以处理我所有损坏的包裹

我也成功

pip install pyinstaller --no-use-pep517
Collecting pyinstaller
  Using cached https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz
Requirement already satisfied: setuptools in c:\python37\lib\site-packages (from pyinstaller) (39.0.1)
Collecting pefile>=2017.8.1 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/ed/cc/157f20038a80b6a9988abc06c11a4959be8305a0d33b6d21a134127092d4/pefile-2018.8.8.tar.gz (62kB)
    100% |████████████████████████████████| 71kB 1.0MB/s
Collecting macholib>=1.8 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/41/f1/6d23e1c79d68e41eb592338d90a33af813f98f2b04458aaf0b86908da2d8/macholib-1.11-py2.py3-none-any.whl
Collecting altgraph (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/0a/cc/646187eac4b797069e2e6b736f14cdef85dbe405c9bfc7803ef36e4f62ef/altgraph-0.16.1-py2.py3-none-any.whl
Collecting pywin32-ctypes (from pyinstaller)
  Using cached https://files.pythonhosted.org/packages/9e/4b/3ab2720f1fa4b4bc924ef1932b842edf10007e4547ea8157b0b9fc78599a/pywin32_ctypes-0.2.0-py2.py3-none-any.whl
Collecting future (from pefile>=2017.8.1->pyinstaller)
  Downloading https://files.pythonhosted.org/packages/90/52/e20466b85000a181e1e144fd8305caf2cf475e2f9674e797b222f8105f5f/future-0.17.1.tar.gz (829kB)
    100% |████████████████████████████████| 829kB 1.6MB/s
Installing collected packages: future, pefile, altgraph, macholib, pywin32-ctypes, pyinstaller
  Running setup.py install for future ... done
  Running setup.py install for pefile ... done
  Running setup.py install for pyinstaller ... done
Successfully installed altgraph-0.16.1 future-0.17.1 macholib-1.11 pefile-2018.8.8 pyinstaller-3.4 pywin32-ctypes-0.2.0

我不认为这是pip / setuptools中的错误，从我对PEP 517的“构建环境”部分的阅读中看来，除了可以使用pyproject.toml中声明的依赖项之外，似乎不应该假设任何有关环境的信息。

另外从setup.py导入正在安装的软件包不是一个不好的做法吗？ 有一种更好的方法可以将软件包版本保持在一个地方，例如，如本PyPA

在pypa / setuptools＃1642中的讨论中， @ uranusjr和停止依赖.在sys.path的事实，这是一个机会python脚本，并开始将人们带入更明确的语义中。

这里的主要问题是pyproject.toml存在使人们同时选择PEP 518和PEP 517，因此即使您未指定构建后端，您也会突然获得新的语义。

此时对pip的决定是否不可逆？ 也许我们可以让pyproject.toml允许您加入PEP 518，但是除非您实际指定构建后端，否则不会触发PEP 517？

老实说，这是一个艰难的处境，但是我认为pip对此发出警告要比setuptools容易。 如果我们现在选择加入PEP 517，并说pyproject.toml将在20.0或21.0之后开始触发PEP 517，我们可以创建迁移指南并开始在pip发出警告build-backend缺少pyproject.toml ，请注意，在21.0版之后，构建隔离将默认使用setuptools.build_meta ，请参阅迁移指南，位于...”

同样不是从setup.py导入正在安装的软件包不是一个好习惯吗？ 有一种更好的方法可以将软件包版本保持在一个地方，例如，如本PyPA

公平地讲，该指南定义了从setup.py导入要安装的软件包作为策略6，因此它在某种程度上肯定是很常见的。 在这一点上，如果我们放弃这种策略，则该页面应进行更新以不再包含它。

由于pyproject.toml的存在而触发PEP 517的决定是一个故意的选择（讨论可能是关于PEP 517实施问题或PR，但我现在没有时间找到它）。 显然，可以根据我们在此处看到的内容进行更改，但是在没有适当考虑我们做出决定的原因的情况下，我们不应该这样做。

Pip本身（IMO不应该）不认为setup.py是否正确，认为项目目录位于sys.path ，所以我有点不愿意简单地更改pip因为setuptools希望在使用后端时推送不同的默认值。 虽然我同意导入正在setup.py中构建的项目有很多困难，但是到目前为止，这并不是触发警告的东西，因此我假设后端应保留该语义。 换句话说，即使pip确实按照您的建议发出警告，用户为什么也会阅读“构建隔离将默认使用setuptools.build_meta ”，这意味着“您将无法从setup.py导入项目”

就个人而言，我同意当前依赖pyproject.toml文件的方法。 IMO的问题源于使用pyproject.toml而非包装的人。 因此，正确的出路是推动非打包工具提供另一种配置方式，以便人们可以选择是否使用pyproject.toml。

Pip本身（IMO应该不会）不应该考虑setup.py是否认为项目目录位于sys.path上，因此我有点不愿意更改pip的原因仅仅是因为setuptools想要推送一个使用后端时使用不同的默认值。

的确，只是pip假设调用setuptools.build_meta挂钩是并且应该完全等同于调用setup.py 。 我们已经看到了并非如此的情况，我想我们是否（ setuptools ）希望setuptools.build_meta的合同是“这等于调用python setup.py ”，或者相反，我们希望它是“这是直接调用setup.py锁定和隔离版本”。

当然， setuptools可以说“这不是函数的约定，因此我们不会修复它”，而pip可以说“我们的决定是它默认为PEP 517”。我们都可以说该错误在另一个项目中，但是协调可能是一个好主意。

换句话说，即使pip确实按照您的建议发出警告，用户为何也会读到“构建隔离将默认使用setuptools.build_meta”作为暗示“您将无法从setup.py导入项目”？ 这两个事实似乎与我无关。

它们可能相关也可能不相关，但语义可能还会有其他更改。 这样的警告的意思是：“请明确说明您希望如何进行此构建，因为很快我们将选择您加入可能会破坏您的构建的项目。” 项目可以提前将构建后端添加到其pyproject.toml ，并主动修复可能发生的任何破损。

我们还可以在setuptools创建一个“虚拟” PEP 517后端，例如setuptools.build_meta_legacy ，将chdir s放入根目录，然后调用setuptools.build_meta ，人们只有在旧习惯开始发生之前就需要采用旧习惯。

就个人而言，我同意当前依赖pyproject.toml文件的方法。 IMO的问题源于使用pyproject.toml而非包装的人。

我认为我们需要将PEP 517和PEP 518分开。PEP518明确列出了PEP的“默认值”，而PEP 517没有指定有关默认后端的任何内容。

我记得我对整体“ pyproject.toml的存在不愿意让您选择进行构建隔离”感到不满意，但在实践中看到它后，我也不喜欢指定我的独立构建的依赖项也会选择的想法我进入setuptools.build_meta 。

也许解决方案是拆分差异，并让后端默认为未记录的setuptools.build_meta_legacy （它确实尝试维护setup.py的语义）。 这样，我们至少将拥有一种方法来判断用户是否对使用新语义做出了肯定的选择，或者只是只是不考虑而已。

带有警告消息的build_meta_legacy听起来对我来说是个合理的解决方案。 最好使警告非常突出（例如，在安装过程中并鼓励用户将其作为错误提交给维护人员），并提供明确说明，说明如何进行迁移。

我还要注意一点，即pip的意图（这是“公司” pip ；-）-我的意思是pip开发人员对此进行了一些讨论，并达成了一个普遍共识，即听起来像是一个合理的想法，但这还不是一个坚定的计划。并且它依赖于实际编写代码的人才能实现）是我们相对较快地切换到通过PEP 517传递所有项目，并将我们的旧代码路径完全通过setup.py丢弃。 仅在pip 21.0中使用setuptools后端（以使用上面建议的发行版）可将其推迟至少2年。

而PEP 517未指定默认后端的任何内容

真正。 但是在某些时候，pip会放弃setuptools的特殊情况支持。 毕竟，PEP 517的整个要点（至少对我们而言）是使前端与后端脱钩，并使所有后端处于平等的地位。 因此，每当我们这样做时，我们都必须在没有后端的情况下出错，或者选择一个默认值（出于遗留原因，我们将默认使用setuptools）。 这里的辩论是我们何时这样做，而不是如果这样做。

Pip当前具有2个用于安装的代码路径-PEP 517路径和旧版setup.py路径。 这是维护问题和潜在错误的来源。 如果存在pyproject.toml ，我们选择将PEP 517设置为默认值，以确保使用PEP 517路径（不太可能项目会急于添加build-backend = setuptools.buid_meta ，因此如果没有当前行为，则可能是对pip的PEP 517代码和setuptools的后端进行的测试将在较长时间内保持接近零的状态）。 可以采用--no-use-pep517形式的退出功能来恰好迎合setuptools后端不合适的情况（假定为罕见）。

我认为没有人期望setuptools希望在setup.py和后端之间具有语义差异，因此可能需要--no-use-pep517来解决语义差异，因此应该甚至从未考虑过默认值。

我们还可能在setuptools等setuptools中创建一个“虚拟” PEP 517后端，该chdirs进入根目录并调用setuptools.build_meta，这样，人们只有在需要之前就开始使用旧行为，然后才能开始使用它。

那可能是一个合理的解决方案。 但这必须至少部分地进行记录-至少，pip会记录这是我们假定的默认值。 我想，setuptools是否选择不记录后端是他们的选择。

我不确定任何进一步的理论讨论是否有用。 当然，我认为我没有其他补充。 我建议，如果有人希望将其推进，最好的方法是创建一个切换默认设置的PR，然后讨论是否要接受它。

对于希望为您的用户解决此问题的软件包维护者：我已经发布了一种实现sys.path修复程序的填充程序。

https://pypi.org/project/setuptools-localimport/

希望这可以作为一个权宜之计，所以我们可以思考如何在不急于解决的情况下向前发展，或者不必要地减慢了pip 19.0的使用速度（pip 19.0的优点远远超过PEP 517）。

我已经发布了一个实现sys.path修复程序的垫片。

棒极了！ 不管最终修复如何，这都是PEP 517挂钩系统灵活性的一个很好的例子：-)

我通过将我的pip版本降级到19.x以下来修复它，然后尝试安装并成功运行

还有第三个用例：提供自己的构建后端的软件包如何？ 例如：setuptools本身仅列出wheel作为构建要求：

[build-system]
requires = ["wheel"]
build-backend = "setuptools.build_meta"

如果用于处理PEP 517的pip代码未将源目录添加到sys.path那么这当然会失败。

从PEP 517：

导入模块路径时，我们不会在包含源树的目录中查找，除非该目录始终位于sys.path上（例如，因为它是在PYTHONPATH中指定的）。 尽管在某些情况下Python会自动将工作目录添加到sys.path中，但是解析后端的代码不应受到此影响。

（对我而言）很清楚地表明，解决build-backend时，项目不应期望能够看到自己的项目目录-因此setuptools需要将自身添加到requires IMO中。 是的，我知道这样做是循环的。 但是，构建自身的构建后端无论如何本质上都是循环的-当然，这不是正常情况。

在我看来，同一部分似乎也证实了构建工具不应期望项目目录位于构建环境的sys.path 。

--no-binary :all:如何使用？

@pfmoore情况的一种变体是，软件包提供了自定义的构建系统。 未安装构建系统（不是bdist的一部分），但sdist提供了构建系统，可能是为了自定义某些构建过程。 这是一个有效的用例，还是维护者必须将定制构建系统作为单独的软件包发布？

编辑：类似的东西

project/
    custom_build.py
    src/
        my_package/
            __init__.py
            ...
    pyproject.toml  

[build-system]
requires = []
build-backend = "custom_build"

# Maybe the custom backend specifies metadata like this…
[tool.custom_build.metadata]
name = "my-package"
dependencies = []
packages = ["my_package"]

也许解决方案是添加一个新的可选配置，以指示在构建过程中在哪里可以找到模块？

[build-system]
requires = []
build-backend = "custom_build"
build-backend-findpath = ["build_systems"]   # Put custom_build.py above in a subdirectory.

配置默认为[] （空列表），这意味着没有添加路径（即与当前行为相同），但是项目可以添加路径以在本地找到构建系统。

如果build-system被完全省略，则该部分默认为：

requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"
build-backend-findpath = [""]

pip可以显示警告/信息，告诉用户迁移（可能带有指向文档页面的链接）。

该解决方案的另一个好处是，一切都可以在pip中完成（实际上是供应的pep517模块）。 无需更改设置工具或现有的已中断项目。

情况的变种是，软件包提供了定制的构建系统。

老实说我不知道​​。 我没有想过自己的情况。 我不知道PEP的作者是否考虑过-我不记得在开发PEP时对此事的任何讨论。

实际上，经过检查，PEP 517确实明确地说过（在build-backend ）“导入模块路径时，我们不会在包含源树的目录中查找，除非该目录仍然位于sys.path上。 ”，这向我暗示，明确建议不要使用树内后端。 我不确定是否有人可以使用足够弯曲的代码来解决此问题，但我不确定（但我怀疑不是）。

当我们开发PEP 517时，预期的用例是后端将作为PyPI（或自定义索引）上的轮子运输，并将其下载并安装到构建环境中。 后端的构建方式显然超出了范围-我个人认为它们将不使用PEP 517机制，而将使用较低级别的命令（例如setup.py bdist_wheel或flit build ）。 递归地使用PEP 517后端来构建自身似乎是复杂性上的一步。 它被认为是pip中PEP 518实施的一部分（如果后端以sdist的形式运送，并使用其自身进行构建，则可能会产生分叉炸弹利用，这是我们必须防止的，甚至我们无法支持不作为轮子分发的后端），但仅限于从PyPI下载后端的情况下。

tl; 博士我所能提供的是我当时对讨论的回忆-您最好在档案中搜索实际背景。

我不知道PEP的作者是否考虑过-我不记得在开发PEP时对此事的任何讨论。

我刚刚开始查看档案，看来这个问题确实在流程结束时（或至少在流程末尾）已进行了详细讨论。 我不是哪个网站最适合查看档案，但这是讨论开始再次讨论此问题的地方（2017年7月28日）：
https://mail.python.org/pipermail/distutils-sig/2017-July/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

例如，这封特定的电子邮件以-

考虑到我们已经对PEP 517遇到了很多麻烦，让PEP 517强制要求该目录不在sys.path上并为python-path进行一些后续PEP可能更有意义。

如果我遇到最终判决，我将通知您，但我鼓励其他人自己阅读。

真好！ 感谢您发现:-)

因此，我浏览了许多电子邮件，我认为您至少可以跳到8月29日，在那儿，Nick似乎暗示对于离开sys.path的源目录_out_有共识：
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
（人们逐渐相信纳撒尼尔的论点。）

但是，在上面链接的同一封电子邮件中，Nick确实表示以下内容：）

1. 如果忽略它确实是一个问题，那么在实施setup.py后端的过程中，我们可能会尽快找到答案

这是电子邮件中的完整段落：

所以我认为，我们可以认为这一项有利于解决“前台应用必须确保当前目录是不是在sys.path中导入指定的后端之前”，因为开始有将意味着我们可以最大限度利用学习新东西的机会，为初始的一部分推出临时接受的API。

我还不知道以后是否会有更改此摘要的电子邮件，但是此后没有很多关于该主题的电子邮件。

感谢您为我们@cjerdonek拖曳档案。 陈述我目前对该问题的理解：

1. 许多现实世界中的setup.py文件当前在运行时都假定当前目录位于sys.path ，这会产生奇怪的自举问题，因为项目将自己视为安装时依赖项
2. PEP 517明确表示，构建前端不应隐式将当前目录添加到sys.path （它没有说明任何后端）
3. pip 19.0认为pyproject.toml无build-system部为等同于一个build-system部分，它指定setuptools后端
4. setuptools PEP 517后端当前也不将当前目录添加到sys.path中（因为远离上面的点1被认为是理想的未来目标）
5. 现有项目有两个临时解决方法，同时改进了默认行为：将pip为小于19.0，并显式设置--no-use-pep517选项。 但是，只有在第一次发现升级pip会破坏他们的构建之后，人们才发现这些。

从功能的角度来看，我认为我们要介绍的关键更改是在“ pyproject.toml没有build-system部分”的情况下，包含setup.py的目录应该结束再次在sys.path 。 有两种主要的处理方法：

1. 获取pip来做。 不幸的是，这种行为使行为依赖于前端，因此，除非所有前端都实现相同的解决方法，否则可能会看到现有项目无法安装。
2. 通过检查pyproject.toml中的build-system部分，然后将setup.py目录注入sys.path ，来获取setuptools PEP 517后端如果节和路径条目均缺失。 在这种情况下，仍然需要一个新的pip ，因为它必须指定可以正确处理“无build-system部分”情况的最小版本的setuptools。

为了使事情尽快为最终用户所用，而又不把自己涂在任何不幸的设计角落，我实际上提出了一个三步解决方案：

1. 现在执行新的pip发布（19.0.1？），为“无build-system条目”情况添加额外的sys.path条目。 在这一点上，兼容性问题应在很大程度上消除最终用户的注意力。
2. 如果前端尚未这样做，请执行一个新的setuptools版本来处理sys.path添加。
3. 在以后的pip版本中，更改“ no build-system entry”大小写以删除特殊大小写，而是将更严格的最低版本设置为setuptools 。

该建议基于以下事实：我认为setuptools PEP 517后端是处理setup.py向后兼容性问题的“正确”位置，但我也认为需要调整pip在短期内，直接更改可能会变得简单得多，并且在进行更体系结构更佳的修复时，这种更改将包含问题。

我已经在pypa / setuptools＃1652中创建了build_meta_legacy后端。 如果pip切换为使用setuptools.build_meta_legacy作为默认后端，我真的会更喜欢，但是我认为创建内置的“旧式填充程序”后端大约是我所愿意的在setuptools 。 我不想在主要的setuptools PEP 517后端无限期地支持完整的“ python setup.py install仿真”。

我有点困惑为什么setuptools不想在TBH本地模拟运行脚本。 似乎要求python setup.py bdist_wheel正常工作时让最终用户感到困惑，但是pip wheel不能（假设他们已将其设置为非旧版构建后端）感到困惑。

有什么根据？

有什么根据？

我的长期计划是弃用setup.py所有直接调用，以支持PEP 517前端或等效的东西（对于其他命令）的间接调用。 如果我们要转移到“所有隔离的环境”的世界，出于相同的原因，我不想被迫保持setuptools命令调用的语义与调用python setup.py兼容517特别指出，前端不应该这样做-它有可能破坏构建隔离并通常造成不良情况。

我认为很少需要这样做，除非作为反模式的一部分。 任何有正当需要的人都可以在他们的安装脚本中轻松地操作sys.path 。

只是要注意，我认为PEP 517从来没有一个设计目标能够通过挂钩实现所有构建工具的访问。 例如，flit有其自己的命令集flit build等，并且我不打算弃用这些命令。 因此，您可能会发现一些极端情况，其中PEP 517的意图是需要使用特定于工具的命令。 一个明显的例子是构建后端本身（如上所述），但是还存在其他情况（目前尚未标准化，尽管将来的PEP可能会增加挂钩），例如可编辑的安装和就地构建（重用先前构建的人工制品）。

达成所有工具都可以支持“ build sdist”和“ build wheel”的协议非常困难，以至于我不期望很快会进一步扩展标准操作列表。

只是要注意，我认为PEP 517从来没有一个设计目标能够通过挂钩实现所有构建工具的访问。

这不是我建议的，有点离题了。 我的观点是，问题，必要PEP 518也存在一般多为所有setup.py命令，这些都是最好的移动人援引远解决setup.py可言。 以相同的方式执行此操作，不需要任何标准， flit不需要PEP即可添加子命令。

喔好吧。 很抱歉对于这个误会。

@ncoghlan建议的过渡对我来说似乎很好。 如果没有人对此有任何疑问，让我们继续吧。

感谢您挖掘@cjerdonek档案！

鉴于已经有一个PR可以在setuptools中解决此问题（通过引入旧版后端）。 有什么理由不跳过上面的步骤1？ 我们正在将setuptools安装到一个隔离的构建环境中，因此取决于最新版本应该不是问题。

有什么理由不跳过上面的步骤1？

不。 我们可以直接修改当前的最低要求版本。

我的过渡计划是基于这样的假设，即人们将需要更多时间来制定setuptools方面的长期过渡机制-而@pganssle专用的过渡后端在该方面看起来很有希望，我不确定在审查更改时将现状保留在原处是有意义的。

就是说，我对pip的PEP 517实现的工作原理不熟悉，所以我认为在前端解决该问题很简单可能是不正确的。

因为后端是在子进程中运行的（实际上，使用供应商提供的pep517项目，它增加了间接的附加级别），所以我对如何设置sys.path完全不了解。后端挂钩。 至少我们需要涉及PYTHONPATH ，这意味着担心用户已经设置了PYTHONPATH以及隔离代码如何使用它。

基本上，我怀疑将sys.path设置

我认为获得固定的setuptools后端是最快的方法。

我的长期计划是弃用setup.py的所有直接调用，以支持PEP 517前端或等效的东西（对于其他命令）的间接调用。

@pganssle哎呀。 程序性setup.py必须死亡。 它不应该出于任何原因而存在。 因为这种“灵活性”是痛苦和崩溃的无穷源头。 迁移setup.py是不可能的，因此就没有Python打包的所有问题。

我将setup.py替换package.json然后为其添加Python部分，而不是另一种包描述格式。

至少然后我可以使用==1.x版本说明符。

@techtonik请走开。 在我参与的任何项目中，您的非建设性贡献均不受欢迎。

在＃6210上进行的工作使我从上面回答了我自己的问题，即在pip级别解决该问题有多困难：挑战是关于是否应将源目录插入为sys.path[0]需要从读取pyproject.toml的代码传输到PEP 517钩子调用程序，然后从那里传输到实际的进程内包装脚本。

这些是可以实现的，无需进行重大的体系结构更改（在第一部分的构建后端名称上使用pip._implicit.前缀，在第二部分使用PEP517_SYS_PATH_0 env var），但这意味着临时修改供应商的pep517代码直到正确修复setuptools为止。

我的过渡计划是基于这样的假设，即人们将需要更多时间来解决setuptools方面的长期过渡机制-尽管@pganssle专用的过渡后端在该方面看起来很有希望，但我不确定这是否有意义在审核更改时保持现状不变。

是的，我同意这一点。 我只是在distutils帖子中建议过这一点，有两件事很重要：

1. 尽快为用户提供修复
2. 正确过渡。

我个人认为正确的做法是删除“ pyproject.toml的存​​在使您选择加入PEP 517”逻辑，直到我们具备转换逻辑为止。 考虑到setuptools的更改会对其面向公众的API产生影响，而在pip它只是延迟了原来是向后不兼容的更改，因此我认为在检查setuptools前进方式时，在pip进行快速修复。

两种方法都可以在我的本地计算机上运行，​​我针对最初有问题的PyInstaller==3.4要求测试了＃6210和＃6212。

• ＃6210根据需要工作： https :
• ＃6212的行为不符合预期： https :

我不知道＃6212失败是不是测试设置问题，或者说setuptools预发行版中实际上还有其他问题，我只知道在我们对该解决方案充满信心之前还需要做进一步的集成工作，而我现在对＃6210充满信心-唯一的问题是它是一个可怕的兼容性黑客，我们不希望pip永远存在。

看起来--no-cache是＃6212上失败的assert 。 相反，使用--cache-dir进行测试可以成功完成本地测试： https :

（我将在离线状态下睡眠和工作约18个小时，因此与此同时，＃6210或＃6212中的任何一个都应该让人们自由奔跑）

我已经更新标题以更好地反映情况。 感谢@ncoghlan的PR！

审核说明：我也继续将非生产性注释（以及对它们的回复）隐藏为“主题外”，并将在以后针对这些内容的任何注释中使用。 如果有人想讨论主持人问题，请提出新问题或通过电子邮件ping我； 这个线程不是提出任何适度问题的正确位置。

我也继续并固定了此位置，以避免人们重复创建并清楚地表明我们对此有所了解。

即使我们使pep517选择加入，这也是一个尚未宣布的行为更改，因此即使已选择in_，它们也会破坏库_（例如，请参阅PyInstaller ）。 如果某个库声明选择加入pep517构建，并且_import_在本地导入它希望在sys.path上找到的内容，则pip不会做任何假设（因为该库是显式的），但是该库是还是突然坏了。

在那种情况下，除了在setuptools中包含cwd之外，我真的看不到其他选择，因为这已经坏了。 除非提议是要告诉人们返回并修复他们在pep517和pip 19之间插入的发行版，否则，如果任何用户严格固定了这些版本，它们可能会突然停止安装，我真的觉得我们应该考虑一下影响这些决定取决于用户体验。 基于此讨论和当前建议，除非明确禁用pep517构建，否则将无法使用默认值安装新版本的pip + setuptools来安装其中的某些库。

如果您只是想使用python提供的工具来安装软件包，那么这会产生很大的影响，但是实际上它不能随机地安装东西。 我说这是为了暂时将技术重点转移到最终用户身上，他们可能会对工具，生态系统，库或语言本身感到沮丧，因为突然之间（而且是的，只有在具体情况），现在他们无法安装可以安装的东西。 我确实认为我们应该在已实施的任何解决方案中缩小这一差距。

我们目前使用故障堆栈来处理pipenv中的失败安装，并且我将在可用时添加--no-use-pep517来处理由于这些更改而导致的故障。 我不确定这对一般用户来说是直观的，因为它甚至可能无法立即弄清问题的根源。 我说这只是为了指出我们有一种解决方法，但是尝试缩小这一差距以帮助用户稍微了解一下这一点很重要

（编辑：还要感谢pganssle，cjerdonek，pfmoore，pradyunsg，ncoghlan，以及为此付出了很多时间和精力的其他所有人）

我们开发PEP 517时的预期用例是，后端将作为PyPI（或自定义索引）上的轮子运输，并下载并安装到构建环境中。 后端的构建方式显然超出了范围-我个人的推测是，它们将不使用PEP 517机制，而是使用较低级别的命令（例如，setup.py bdist_wheel或flit构建）。 递归地使用PEP 517后端来构建自身似乎是复杂性上的一步。 它被认为是pip中PEP 518实施的一部分（如果后端以sdist的形式运送，并使用其自身进行构建，则可能会产生分叉炸弹利用，这是我们必须防止的，甚至我们无法支持不作为轮子分发的后端），但仅限于从PyPI下载后端的情况下。

只是回过头来看-新的setuptools.build_meta_legacy默认值解决了对PEP 517进行除PEP 517后端setuptools本身是一个问题。 如果我们不能解决问题，那么正如@ benoit-pierre在pypa / setuptools＃1644中指出的那样，人们将不可能对依赖setuptools任何项目使用pip install --no-binary :all: setuptools （或大概是任何PEP 517后端提供程序）。

我们应该在这个线程中讨论它，还是创建一个新的线程来讨论它？

我们应该在这个线程中讨论它，还是创建一个新的线程来讨论它？

我将其拆分。 我的直接感觉是，问题在于--no-binary :all:在这里有重大的意想不到的后果（实际上类似于在仅分发轮子而不是sdists的项目中使用该标志的影响），我想为了避免离题（例如），使用--no-binary :all:进一步分散了该线程的注意力。

我不认为使用--no-binary :all:构建构建后端来解决此问题比这更关键。 如果用户已经指定了--no-binary :all: ，那么他们可以相对轻松地添加--no-use-pep517 。

新的PR＃6229：

1. 实现@pganssle建议的临时解决方法，使pyproject.toml的build-system节成为自动加入PEP 517的初始要求（推迟“任何pyproject.toml文件” opt-进入更高版本）
2. 添加3个专用测试用例，涉及从setup.py导入相邻软件包

我将关闭其他两个PR，以支持该PR，因为这是应该使最终用户再次正常工作的最小修复程序，并且不需要像＃6210那样的可怕骇客或像＃6212这样的新setuptools版本

那setuptools.build_meta_legacy会留在哪里呢？ 现在的建议是否要求需要“导入相邻包”功能的项目在pyproject.toml明确指定？ 如果是这样，我强烈建议您需要在某处进行文档记录，并且不建议使用不引入该规范的相邻软件包，并将在pip 19.X中将其删除（我们需要同意X是什么），我们不能这样做程序性弃用（我不认为），但这就是更清楚地记录下来的原因，因此，我们不会（再一次）被指责在没有充分通知的情况下删除功能。

编辑：但是，否则，感谢新的PR和摘要。

编辑2：我看到您关闭了setuptools.build_meta_legacy提案。 我不确定我是否喜欢那，因为它使我们失去了现在说出我们的长期计划的机会，因此延长了任何弃用期限，如上所述。

@pfmoore否，这意味着与删除＃6163变通办法相关的新问题（可能通过更新为提供setuptools.build_meta_legacy的setuptools setuptools.build_meta_legacy ）来解决。

编辑：目前，我刚刚重新打开了＃6212，但改名为它，目的很清楚，我认为在修复当前失败的安装命令之前，我们不应该等待整个build_meta_legacy讨论得到解决。

我的建议实际上是选择加入PEP 517是指定build-system.build-backend根本不存在build-system ，并且从现在到19.1版本之间，将添加setuptools build_meta_legacy和pip会将其用作默认后端。

我同意在19.1中，如果pip找不到setuptools.build_meta_legacy ，则应该回到旧的代码路径。 这将使我们在选择最大人数的同时，进行最小的重大更改。

我的建议实际上是PEP 517的选择加入是指定build-system.build-backend

...可以通过在后备情况下简单地设置use_pep517 = False来处理（而不是将其设置为has_pyproject ，这是我们现在要做的。

在19.1中，可能如果pip找不到setuptools.build_meta_legacy，它应该退回到旧的代码路径

我认为这不值得做。 我们将指定一个足够新的setuptools版本，以确保可以获取旧版后端，并且无需考虑setuptools在将来的版本中删除该后端的可能性（或者，如果这样做，我们可以只是责怪他们造成的问题;-)）

注意：默认值use_pep517 = False是＃6229的起始名称，但它导致PEP 518测试失败。

1. “ build-system.requires已设置”情况必须使用构建隔离，以便它可以安装请求的依赖项而不会影响父环境。 在给定当前代码结构的情况下，最简单的方法是在这种情况下设置use_pep517 = True ，所以我做到了，然后让测试用例再次通过。
2. 缺少的[build-system]表表示pyproject.toml仅用于将设置存储在[tools]表中，因此必须导致use_pep517 = False是有效的解决方法对于最初报告的问题，因此我将此测试用例标记为预期的失败。
3. 剩下“空[build-system]表”的情况，我认为可以在任一方向上合理地解决。 但是，由于我认为这种特殊情况在实践中不会经常出现（为什么有人会麻烦地添加build-system表而不设置requires或build-backend ？），我选择以某种方式解决该问题，即通过先前定义的PEP 518测试用例，而不是添加第二个预期的失败标记。

要在另一个方向上解析3，我们需要更改行：

use_pep517 = build_system is not None

改为：

use_pep517 = build_system is not None and build_system.get('requires', None)

这样，只有非空的要求才选择加入PEP 517构建隔离（这也意味着添加第4个测试用例，因为空和非空的build-system.requires字段现在的行为会有所不同）。

抱歉，在这里做出了不请自来的贡献，但是我不禁注意到，这一切都是避免在sys.path上使用cwd的一种非常精致的方法，最终会破坏以前可以正常工作的东西，这感觉很破坏从用户体验的角度来看。

大量的用户和软件包受此影响。 至少其中一些定义了[build-system]节，并且也依赖于旧的行为，因此对于那些固定了这些版本的人来说，它们仍然会失效。

@techalchemy是的， pip的原始假设是，从sys.path角度来看， setuptools.build_meta工作方式与直接调用setup.py方式相同，并且该假设证明不正确。 一旦包含在https://github.com/pypa/setuptools/pull/1652中定义的setuptools.build_meta_legacy后端的setuptools版本可用，那么＃6212就可以完成了，那将是漫长的期限解析。 但是，目前尚无此类版本的ETA，因此我们需要继续探索pip仅解决方案，以使未明确显示“ PEP 517本机”包的源目录恢复为sys.path ”。

在＃6229中，我实现了@pganssle的建议，即简单地推迟采用“默认情况下，PEP 517”，但是由于pip 19中的另一处更改，这似乎引起了比解决的问题更多的问题： build-system.requires现在与build-system.build-backend ，因此--no-use-pep517也会禁用PEP 518（这会导致测试套件失败，并且如果构建会导致实际安装失败）依赖项未预先安装）。

在＃6210，我不是本地修补pep517支持注入sys.path[0]成子，有效地做同样的事情， setuptools.build_meta_legacy预计在未来做setutpools发布。 这似乎表现出我们想要的方式- build-system.requires仍在处理中，执行setup.py ，源目录为sys.path[0] 。 这也与我在https://discuss.python.org/t/pep-517-backend-bootstrapping/789/29?u=ncoghlan中提出的建议和@takluyver在https://github.com/中起草的建议非常相似--no-binary :all:兼容的方式处理后端自引导

很抱歉成为AWOL RM。 发生了意料之外的事情。

我显然更喜欢setuptools侧的修复程序，但是＃6210对我来说也很酷-作为短期修复程序。

我同意@techalchemy和@pradyunsg-我认为setuptools侧修复是此处的正确方法。 虽然我赞赏尝试在pip中找到快速修复的工作，但现在不应该花更多的时间使用_build_meta_legacy来加速新版本的setuptools吗？ 我一直没看什么在setuptools的，所以我完全清楚我不为什么有与setuptools的释放快速解决问题（在setuptools的发布周期比画中画的方式更快）。

短期pip侧修复可以，但是我想澄清一下什么时候可以期望setuptools修复。

大家好！

我也有同样的问题：

**Collecting pyinstaller==3.4
  Using cached https://files.pythonhosted.org/packages/
a0cc/PyInstaller-3.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command "c:\program files (x86)\
gram files (x86)\microsoft visual studio\shared\python3
requires_for_build_wheel C:\Users\ASUS\AppData\Local\Te
  Traceback (most recent call last):
    File "c:\program files (x86)\microsoft visual studi
process.py", line 207, in <module>
      main()
    File "c:\program files (x86)\microsoft visual studi
process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwarg
    File "c:\program files (x86)\microsoft visual studi
process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requi
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 101, in _get_build_requires
      _run_setup()
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 20, in <module>
      from PyInstaller import __version__ as version, H
  ModuleNotFoundError: No module named 'PyInstaller'**

有人知道问题是否解决了吗？ 还是暂时解决呢？

谢谢大家！

@ jce94 ，现在使用pip <19。

@altendky，谢谢您的信息！

使用pipenv ，无法通过建议的解决方法解决此问题。 冻结pip至18.1的Pipfile似乎没有任何效果pipenv保持迫使最新版本的点子。 我可以手动将pip设置为18.1，但是当我重新创建pipenv虚拟环境时，无论如何，Pipenv都会升级到最新的pip。

@altendky遗憾的是，当时对于pipenv（以及我认为的诗歌）用户而言，无法使用预定义版本的pip。 两者都使用最新版本。 所以我想现在很多人都被管道中断了

更奇怪的是，它并没有持续发生。 我已经重新执行了一个Appveyor作业，第一个通过了，第二个失败了，尽管它们是完全相同的

如果有人想知道时间表，我希望我们能够在本周末或下周初准备好修复程序，并在此之后不久发布pip的后续错误修复程序。

新版的setuptools版本40.8.0现在可与build_meta:__legacy__后端一起使用。

谢谢！ 这是我们应该指向PyInstaller使用的东西吗？ 他们是
对此更改感到非常不满意...我可以提供的任何文档或PEP
他们支持变化吗？

在2019年2月5日星期二10:24保罗·甘斯尔< [email protected]上写道：

现在，随版本提供的新版本的setuptools版本40.8.0
build_meta：__ legacy__后端。

—
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/pypa/pip/issues/6163#issuecomment-460747909或静音
线程
https://github.com/notifications/unsubscribe-auth/ADtXZjnOfu56IYR6VEKK4yowMg3XdcFEks5vKcxBgaJpZM4aNvmP
。

@AlmogCohen不，这不是您应该直接使用的东西，它只供PEP 517前端使用。 下一步是让pip开始使用build_meta:__legacy__作为其默认后端。 从最终用户的角度来看，这是不可行的。

新版本的任何ETA都将集成此修复程序？

几个小时后。 :)

请参阅固定的问题。

pip 19.0.2已发布，并已对此进行修复。

即使使用--no-use-pep517 ，我也无法使用最新版本的pip安装pyinstaller --no-use-pep517

pip install pyinstaller --no-cache-dir --no-use-pep517
Collecting pyinstaller
  Downloading https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz (3.5MB)
     |████████████████████████████████| 3.5MB 273kB/s
  Installing build dependencies ... done
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\setup.py", line 20, in <module>
        from PyInstaller import __version__ as version, HOMEPATH, PLATFORM
    ModuleNotFoundError: No module named 'PyInstaller'
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\

该线程已被自动锁定，因为它关闭后没有任何近期活动。 请为相关错误打开新一期。