<p>pip install --editable和名称空间包的pip install冲突</p>

同样的问题在这里:(

我已经发布了代码来测试此错误： http :

问题的根源在于setuptools包括两种使名称空间包起作用的方法： __init__.py方法（已记录，可供人类使用），以及...-nspkg.pth文件方法，即仅与--single-version-externally-managed （点子使用）一起使用。 两种方法互不兼容。

经过与mitsuhiko和其他人在IRC上的讨论之后，看来pip的最佳（部分）解决方案是让“ pip install -e”为每个开发安装的程序包添加标准setuptools ... nspkg.pth文件的修改版。 。 （必要的修改是使用development egg-link路径而不是sitedir，并完全跳过对init .py的检查，因为开发安装的名称空间包将具有init .py。） 这意味着pip至少将与其自身兼容（pip安装的和pip可编辑安装的名称空间包将一起工作）。 Pip安装的和setuptools / distribute安装的名称空间软件包将不兼容。

我最近也被这个咬了。 由它引起的另一个问题是，由于未为命名空间软件包安装__init__.py （假设您仅在该命名空间中安装了一个软件包，并且安装了--single-version-externally管理），因此中断鼻子的模块搜索。 也许这是不对的，但是我仍然认为，如果目录中没有包含__init__.py的目录不是Python包，那仍然是合理的。

我认为pip应该以某种方式完全杀死nspkg.pth并安装__init__.py 。 只要包本身的设计正确（即__init__.py为空，extend_path / declare_namespace除外），就不成问题。 --single-version-externally-managed在设计时就考虑了系统打包程序，但最初他们不会使用pip。 因此，我想知道是否有某种方法可以完全禁用此行为，而又不会太令人讨厌。

+1表示从'--single-version-externally-managed'退出：该选项根本不适合pip的用例。 如果pip至少不能像easy_install那样出色地进行安装，那么它的目的是什么？

完全不会从--single-version-externally-managed转换掉； 固定安装是一个功能。 为了避免这些问题，我认为只有在使用名称空间包的情况下才放弃使用它。 我不喜欢它，但是鉴于内置在setuptools / distribute中的两种名称空间包支持之间固有的不兼容性，因此似乎没有什么好选择。

说--single-version-externally-managed “不打算用于pip的用例”介于错误和红色鲱鱼之间。 该标志旨在允许使用由easy_install以外的其他工具管理的平面单版本安装。 这正是pip的用途； setuptools作者最初（并且错误地）认为仅系统打包程序会对这种功能感兴趣的事实是无关紧要的。

此处的破损是setuptools用于带有该标志的名称空间软件包的技术中的一个固有错误，该错误与最初由其预期的受众（系统打包人员）使用该标志时存在的错误相同（我首先看到了“ setup.py开发”安装的软件包和系统软件包安装的名称空间软件包）。

我也遇到了这个错误。 我猜这是那些无法解决的错误之一。 那好吧。

我将接受一个补丁程序，以避免在涉及名称空间包时使用--single-version-externally-managed ，我认为它将解决此问题。 我目前尚无编写该补丁程序的计划。

为什么不选择我们可以传递给pip install不使用--single-version-externally-managed ？ 我通过注释./pip/req.py:568 ，现在所有软件包都安装在egg dir中，就像easy_install一样。 如果我同时使用了pip和easy_install，那么我有时会想这样做，这样我的site-packages不会与某些固定安装的软件包混合使用，而有些则不会。

我没有看到--egg选项退出--single-version-externally-managed 。

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

如果我朝着正确的方向前进，有人可以发表评论吗？ 这是我第一次入侵pip代码，因此这是基于我几分钟的了解，只是为了让pip install --egg somepackages将所有内容都安装到单个egg目录中。

如果我朝着正确的方向前进，有人可以发表评论吗？

对我来说看起来不错，只需要测试。 测试大多是高水平的
使用ScriptTest进行集成测试，应该易于编写基于
现有的例子。 在这种情况下，您只需要测试安装
一个示例软件包会在其中生成一个.egg文件，而不是平面安装
网站包装。 您应该从本地文件系统安装软件包，
而不是网络： tests/packages/FSPkg可能会正常工作。 新增中
可以测试tests/test_basic.py 。

谢谢！

拉取请求-https: //github.com/pypa/pip/pull/541

我也正在考虑可以在pip.conf中设置此标志。 您对此有何看法？

我也正在考虑可以在pip.conf中设置此标志。 您对此有何看法？

让我们讨论拉取请求。

合并拉取请求＃541，它提供了一种解决方法。 谢谢@ k4ml！

注意：为解决此问题而添加的--egg选项可能会被删除，没有提供其他解决方法。 参见＃1749中的讨论

这是一个实际重现此问题的脚本

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

我不是--egg解决方案的忠实拥护者，但此方法不需要那么麻烦。

没有解决方法，在开发时，我不能使用--editable一次，而只能进行编辑和测试。 每次保存代码时，我都必须运行pip install -I --no-deps . ，它确实很旧并且很脆弱（阅读：有时我会忘记）。

整个问题表现方式的部分问题是它保持沉默。 即使安装了模块并且pip告诉您它已经存在，您也无法导入。

如果尝试将可编辑的软件包作为名称空间的一部分安装（如果该名称空间中已经安装了不可编辑的软件包），这将是一个积极的步骤。 或者，如果尝试安装属于名称空间的不可编辑的程序包（已安装该名称空间中的可编辑程序包），则提出投诉。

另一个选择是，如果我们实际上要使名称空间包始终可编辑，并且可以正常工作，则可能是，如果将名称空间包安装为可编辑，则pip可以重组该名称空间中的所有其他包，使其与所需的包一起可编辑。

我在setuptools https://bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-version中提交了2个解决此问题的建议

推杆

导入pkg_resources; pkg_resources.fixup_namespace_packages（''）

在站点软件包中的.pth文件中，似乎足以使pip install -e安装的东西正常工作。

这也会影响两个具有相同顶级名称空间且均以可编辑方式安装的软件包。 第二个软件包安装被破坏。

我们对所有应用程序都使用全局名称空间，因此这个问题有点难（+ setuptools不支持wheel的问题，由于我们的Windows部署平台上缺少编译器，所以这是必要的）。 同样，所有推荐的解决方案在我们使用Python 3.4的安装中似乎都失败了。

意识到pip install -e确实为应该可编辑的项目运行setup.py develop ，我迷上了setuptools过程并编写了一个* .pth文件，该文件在python进程中“引入”了命名空间包开始。 当使用setuptools 18和pip 7.1.0时，这为我们解决了问题。

可以在此处找到示例setup.py文件，其中显示了如何实现此目的：
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

我希望这对其他人也有帮助。

我今天也遇到了这个问题，这使我无法从构建切换到virtualenv + pip。

我创建了一个小演示来演示问题。 要对其进行测试，请解压缩.tar.gz并在其中运行{{run-me}}脚本。 测试修订时可能很有用。

我也遇到了这个问题。

在尝试理解的过程中，我遇到了@carljm在https://github.com/pypa/pip/issues/3#issuecomment -1659959中提出的解决方案，即_have“ pip install -e”添加了标准的修改版本每个开发安装的package_的setuptools ... nspkg.pth文件。

我手动尝试了这种方法，似乎效果很好。 看起来它可以同时解决＃3160中描述的缺少名称空间包的浅源树的问题。

因此，我想知道该方法是否仍然有效，是否有任何尝试来实现它，以及是否会考虑为此打补丁？

所以...在不久的将来，这个希望没有希望吗？

pkg_resources.get_distribution()某些副作用使导入起作用。 当python shell失败时，加载入口点的代码可以正常工作时，我们发现了这一点。

这也可以解释为什么ipython shell导入软件包没有问题。

令我惊讶的是，此错误在5年后仍然没有任何明确的解决方法仍然存在。

如果您的工作是将框架粘合在一起成为一个统一的框架，则pip会使您的工作变得很糟。 老实说，由于这个错误，我不知道如何继续进行我的工作。

在主要由志愿者完成的项目中，这很难解决，
随时在setuptools中添加必要的支持，以便pip可以正确执行此操作

Brandon Github [email protected]写道：

令我惊讶的是，此错误在5年后仍然没有任何明确的解决方法仍然存在。

是的，很可惜。

如果您的工作是将框架粘合在一起成为一个统一的框架，
点子让你的工作糟透了。 老实说，我不知道如何继续
由于这个错误，我的工作。

我最近应用了上面提到的fixup_namespace_packages（''）hack，
它似乎起作用：我在venv的网站程序包中创建了z.pth
仅包含import pkg_resources; pkg_resources.fixup_namespace_packages('')

值得一试，恕我直言。

只是又一个碰撞！

我只提到每个骨髓软件包都使用命名空间（某些软件包最多容纳四个或五个），并且在帮助新用户设置开发工具时，这个特殊问题对我的存在有点困扰。 。 我用这个害羞的只有60个包装。 entry_points注释也很有趣，因为几乎每个构成名称空间的包也贡献entry_points 。

根据我的经验， pip方法仅在_every_软件包已安装且可从磁盘进行编辑且可以在命名空间上协作时才有效。 如果一个安装包无法通过点子进行安装，则整个纱线球开始散开，给新用户带来一些非常非常钝的症状。 （例如间歇性导入的模块；对导入父名称空间并验证namespace.__path___的常规检查，已经迅速确定了测试中的罪魁祸首软件包。）正确混合了pip安装的软件包和纯setup.py develop 'd但是，源代码（避免出现点）会起作用。

我们似乎也能够陷入一种奇怪的情况，即可以三种不同的方式安装单个命名空间提供程序包，有时可以同时安装。 （重复调用pip uninstall每次都发现更多文件，这很不幸，这很有趣。）使用pip install -e时的依赖安装似乎也不一致。 在大多数情况下，我们最终会得到正确解压缩的名称空间（已安装），pth-link文件（已安装可编辑），并且在某种情况下，尽管zip_safe ，我们仍设法以某种方式安装了压缩的.egg zip_safe是该依赖包上的False ，在Pypi上没有提供.egg分发。

虚拟环境第四次受到破坏以从头开始时，对命名空间问题的沮丧达到了顶峰。 ;）

不是解决方案，但我只是提出了一些注意事项。 在“可编辑”程序包，命名空间程序包和普通程序包之间混合使用时，我对buildout + mr.developer更加满意。

虽然提到的修正程序hack @ lelit似乎适用于某些软件包，但它也破坏了我们的某些软件包/构建。

在尝试了pip安装和可编辑模式之后，我想到了与

在实施了PEP420的较新版本的python上，这仍然是问题吗？ （阅读：切换到更新版本的python是否有帮助？）

现在，使用PEP420样式可以有效地帮助我几次使用可编辑模式。

不幸的是，它带有自己的故障：例如，setuptools的find_packages不支持它，因此我的较新软件包包含以下hack：

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

似乎没有人实现为每个可编辑包添加-nspkg.pth的实现。

查看Setuptools 31 ，它增加了对该功能的支持，并且与Python 3.5+上的PEP-420软件包共存。

对于任何好奇的人，这里有一个详尽的清单，列出了命名空间包如何在pip install ， pip install -e ， python setup.py install和python setup.py develop ：

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr：您可以使用pip install -e和python setup.py develop ，只要已使用pip安装了命名空间中的所有其他软件包。

我要解决这个问题。 看来setuptools 31已为我们的复制脚本修复了此问题，除此之外，这里没有pip可以做的任何事情。

@jonparrott
在https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md使用什么版本的pip和setuptools获得结果？

@dstufft虽然我赞赏它应该是固定的，但我想重新运行@jonparrott的兼容性表作为证明。 我希望有将近7年历史并且具有如此广泛的故障场景的票证是最好的，也是最坏的计划。 考虑到此问题的广泛历史，信心不足，并且自己重新运行Nox套件，失败将表明缺乏实际的解决方案。

在@jonparrott的示例中，失败的案例可以归结为“直接使用python setup.py install （不包括预期在Python 2上发生的PEP 420故障）。即使在不涉及pip的情况下，这也失败了。 （例如python setup.py install + python setup.py develop ）。

该票用于pip install .和pip install -e或python setup.py develop 。

@jonparrott已经发布的图表证明了此票证已解决，这里所有剩余的问题都是python setup.py install而不是pip的问题。

我只是重新运行了测试，并且一切与最初运行时相同。 我同意@dstufft的评估

@ piotr-dobrogost测试使用了两者的最新版本。 在撰写本文时，pip 9.0.1和setuptools 34.3.2。